How have you structured your network oriented apps

问题:

I'm starting the design of a new app that is primarily network oriented, and I'm looking for some advice from people who have come up with a good architectural design, or OOP class model.

Please describe the basic architecture and/or class structure. Did you abstract out the communication bits? What class entities did you come up with?

The app will have both listener and client classes. It's similar to a feed aggregator, but uses persistent connections rather HTTP. In other words, I connect to a socket and have a persistent connection in which data flows both ways. Then I also have clients that connect to me persistently and i send some (or all) of the data to them.

Also, I can't use WCF or anything that's in .NET 3.0 or 3.5 (though I can use C# 3 because i'm developing on VS2008). I have to be compatible with Windows 2000.

回答1:

I am on the tail end of a client-server app that I started writing a few weeks ago. I used WCF for the .Net cient & server.

But the server also had to connect to a device on the network that only understood ASCII over TCP/IP.

Did you abstract out the communication bits?

Yes. I guess. I mean, I am not sure I understand your question 100%. For my TCP connection to the 3rd party device I hid the details of the TCP connection and communication behind a class I wrote. The device in question converts ASCII commands to IR signals to control things like satellite dishes and DVD players. I abstracted the TCP communication into a class so all my server had to do is make a call like:

_irService.SendCommand(someAsciiCommand);

What class entities did you come up with?

They were based on my domain. Yours should be based on whatever your domain is. I am not sure I understand that question beyond that. Your domain is going to dictate your objects.

In my domain I was dealing with a server application that was in charge of scheduling and playing multicast broadcasts over UDP utilizing VLC. These multicast broadcasts had to be configurable in every aspect.

When I analyzed the domain I came up with a model that consisted of Broadcasts, Channels, Devices and BroadcastProcesses (a class that was in charge of starting a vlc.exe process and maintaining its lifecycle).

The domain had little impact on the networking technology. I ended up with a few duplex "services" in WCF that allowed me to manipulate the domain. But the networking choices were not dictated by the domain. I wanted a TCP connection with binary serialization of my objects, and I wanted a two-way communication with the server so my clients could get real-time updates via callbacks. Those options were available to me regardless of what my domain looked like.

回答2:

"Network application" is an unclear category covering quite a broad spectrum of possible requirements and designs. By definition, you will have to deal with concurrency and latencies. Robustness is always a challenge: it is all too easy to design a system whose availability is the lowest common denominator of all its hardware and software components. You will have to upgrade the O/S and components of your application: can you live with taking down all of the solution, or do you need some hot/cold standby or even failover capability? Networks fail in exotic ways (at least to us poor pure software guys): you are dependent on so many things you never consider (routers, switches, DNS servers, the temper of that bearded network engineer down the hallway!), and should design the interactions with a pessimistic frame of mind.

One warning: don't be too object-oriented when designing distributed applications. Objects have their place in managing software complexity, but the moment you start pushing them on the wire, a huge number of performance and version dependency problems raise their ugly heads. Service oriented architecture is a buzzword, but is useful as a design principle, to a point. The mainframe guys have known this for ages...

Two general book recommendations:

• Designing Concurrent, Distributed, and Real-Time Applications with UML is a few years old, but brings home the challenges you may be facing (especially if you really have hard or soft real-time dependencies somewhere). A bit theoretical, but serves to instil a certain amount of respect for the complexities!
• Enterprise Integration Patterns is a systematic look at the different design options you can use to integrate new and legacy components.