Steve Jones has used the World Cup to come up with an interesting analogy as to why football is the perfect example of a Service Orientated Architecture. Apart from the fact that he missed the obvious conclusion that SOA is EXACTLY like the English team – promises so much and always fail to deliver – I thought it was interesting to see that he was starting to talk about the importance of agents operating within the system.

One of the key characteristics of an SOA (not that I actually know what that horrible term actually means….) for me, is that it should be goal orientated : what business problem are we actually trying to solve today?

Once you have actually decided what the underlying issue is then you can start to look at how you might solve that problem. You will generally have a set of actors (services? components?) that are available to help you to do some work. The classic (IT) approach is to define a process that is responsible for orchestrating some of those actors to achieve that end goal. The process instance is responsible for invoking and managing the interactions of all these actors. Irrespective of whether you are directly invoking the underlying actor (through some kind of RPC – web services?) or using a more abstract messaging approach (and thus invoking by proxy) there is a very high degree of coupling in this system. The use of an asynchronous messaging layer might help to alleviate some of the ill effects of temporal coupling, but the coupling remains through the fact that the orchestrating process needs to have a great deal of knowledge about the semantics and capabilities of the actors it is invoking. Change is difficult in this command and control approach because of the implicit interaction knowledge that is embedded within the process.

What happens if you invert that thinking and rather than assuming that the actors in your architecture are dumb, stupid and have to be told what to do; let them become fully fledged participants in the solution? Allow them to go looking for work and to carry out the tasks they know how to move forward. This “inverted” Agent based approach results in a much richer, more flexible and powerful architecture. There is no requirement for a process to explicitly orchestrate the interactions between services. The knowledge of what a service does and how and when it should be invoked is removed from the system. It is highly collaborative and it is unlikely that any single actor knows how to achieve the goals of the system – indeed it is actually undesirable to have that much knowledge in a single place. By making actors more specialised they are easier to write and test. The actors can be added and removed at will. As new problems arise – new actors with new specialisations can be added to the system without impacting anything that has gone on before. If existing actors can help on this new problem then they will do so – which leads to a great deal of actor (read service) reuse. Scaling and operational management might also become much easier – actors will not choose more work than they can comfortably manage. If you have outstanding work at the end of the day – simply add more workers to the system. Compare this to the “classic” approach where the runtime system must be aware of how much work an individual actor is carrying out and must know what to do if that actor starts to become overloaded. Does it matter where an agent actor actually runs? Probably not.

So how do you go about building a system like this?

A good place to start looking at how to build a system like this is to actually look at the place where SOA is supposed to be the “next” (yawn) Silver Bullet – inside a business. Very few businesses actually run using the classic “command and control” approach (indeed the best example of that mind set is Soviet Russia – what a great role model!). Business are far more likely to run using a collaborative approach. Problems are generally solved by one or more teams taking a problem (say pitching for an order) and dealing with those aspects they are able to manage. The sales guy might take the request for business and log the details of the order, the credit guy will check that the customer is good for the deal, the shipping guy might search for the best delivery quote, the warehouse guy will check it is in stock and the finance people will try to finance the deal. If there is a problem, say there is a credit issue, then another actor (say a senior manager) can be drawn into the discussion and make an executive decision based on how importsnt the client is. Once everyone is happy then the sales guy can take the final solution and pitch for the business. Nowhere in this description have I described HOW the actors are invoked – all I have described is what they do. No actor has to know about any other actors – yet they are still able to solve the problem. This means that it is the “problem” itself that is flowing through the system and the actors that can deal with it somehow “see” it.

Modern companies might use an Order Management System but the classic computer science approach is to use a Blackboard. Linda (created by David Gelertner at Yale in the 1980’s) is one approach that maps very well to this kind of problem space. There are a variety of Linda like systems out there in the real world. Jini JavaSpaces is one such implementation that I have personally used very effectively to build highly dynamic, collaborative systems with.

In a JavaSpace approach the “problem”can be modelled using fully fledged objects that flow through the system. Actors are able to write instances of those objects into the system, read them or remove them completely. They are able to modify instances of the object and return it to the space or even create new objects/problems that other actors can then help to solve. The space ensures that access to objects are concurrently safe – only one actor can remove an object (although many can read it simultanously) – and the use of transactions means that objects are not lost if an actor dies whilst working on its part of the problem. Actors monitor the space for objects that match their specified criteria – maybe it is of a certain class, or a field (or set of fields) are set to a certain value. Once they see an object that matches their criteria they can operate it. In the course of operating on the object they may well set its state such that another actor becomes interested in it and is now able to do some work – thus moving the problem on a little further. Eventually the problem will be solved and the goal scored – unlike the England team.

(Aside: many of these object flows through the space start to look like events – see Gregor Hohpe Programming with a Call Stack – Event Driven Architectures for an interesting alternative discussion)