views:

86

answers:

1

For a government contract we will be proposing to build a traffic monitoring architecture. We will have the following components:

  • Video camera's set up around the area of interest. The cameras will be aware of their location and orientation and viewing parameters.
  • A GIS map server which can be queried for streets, building, etc.
  • An algorithm the takes in raw video and street location information and outputs car locations.
  • Another algorithm takes in car locations and very low level street information and provides information about which cars are driving anomalously.
  • Another database takes in information about car locations and anomaly reports over time and can be queried for this later.
  • A proxy (or perhaps more accurately, a facade) is set up over the archive database and the real-time algorithms in order to provide a unified interface to the information.
  • A client attaches to the proxy and to the street server and paints various representations of the traffic situation on the screen.

I'm just now learning what an SOA is. Is this an ideal candidate of a Service Oriented Architecture SOA? I had heard that SOA services should be stateless (or is that only RESTful services?) I had also heard that it was inadvisable to pipe one service to the next to the next because it increases hidden complexity, and that there was something you should do to make this situation better (an "orchestration"?). The services above do appear to be modular and reusable. For instance, there will be plenty of cameras, various types of vehicle detection and anomaly algorithms, distributed databases, and plenty of clients. I will need to have the capability to handle events: for instance, if I may want to register to a service and be notified whenever a big truck moves past this point.

If this isn't ideally implemented by a SOA, then where else should I be looking. If this is ideal for a SOA, then where should I start when designing this? (And I'm starting basically from having read Wikipedia's SOA page.) Are there any good case studies to look at here?

+5  A: 

Yes, SOA is ideal in this case (complex, distributed system with a wide mix of technologies) but from the sound of it you need to do a whole lot more research to get your head around the concept. It is not a tough concept by any stretch, it's actually simple, but there is no one prescribed way to do it. I suggest going over SOA case studies for similarly-sized projects, successes and failures.

You mention a facade for one of your subsystems. Extend that same concept to the rest of your components. E.g. each service is a facade to a complex subsystem.

Also, I recommend implementing a couple of different web services in your choice of technologies and abstracting arbitrary different subsystems (a database should be one of the coponents.) Then write a client that makes use of them. Doing so will give you a lot of practical experience and insight into the concept.

Last thought: The one area where an SOA architecture might stumble is if you have to move video data between several different services. The stateless, transactional nature of SOAs might introduce performance issues when moving very large amounts of data or when performing bulk transactions on very large data sets. You either need to keep video localized or implement a back-end subsystem (cheat) to avoid potentially nasty bottlenecks.

Paul Sasik
Very good advice! Thanks. One comment though, there are several services within my framework which cannot be stateless (or otherwise I misunderstand what stateless means in this case). For instance, the vehicle location service will be a client to the video service and will keep track of the location of the cars (a state of sorts) by continuous looking at new frames of video. Perhaps the important thing is that each service must not *keep* the state of its clients. I think I can get away from that here.
John Berryman
What if I want to make the service keep track of listeners and notify them whenever new information is available. This wouldn't represent the service keeping state of its clients, but it would mean that the service was keep pointers to its clients. Does this hurt anything?
John Berryman
The clients and service have a tighter coupling. A client could be offline and you have to decide what the service should do in such a situation, abort, ignore, retry or notify some other system?
Kwebble