Services Thinking: My 2 cents

["RPC via SOAP"] Meaning that soap is about the WORST middle tier technology you can use. It's about one of the best INTEGRATION technologies however.

Basically SOAP is good for inter-application communication. It's a complete abortion to use it for intra-application communication (plus actually fails the entire SOA-Tenants test, but more on that later).

Let's take a trip to the good old days where people would have an "application server". Many technologies were used but let's say it was some form of distributed object technology like RMI or Remoting or even COM+ or EJB. Beyond even the problems usually inherent in such architectures frankly, distributing your application is usually the last thing one should resort to. As Martin Fowler put it cheeky-like, "First Law of Distributed Object Design: Don't distribute your objects!". Distributing internal parts of application across servers requires a large justification beyond, "we just do" or "it makes it better".

But you might be thinking now, "Ah ha! I've got you James. What about my database? It needs to live on another system therefore my application MUST be distributed!" [Insert maniacal laughter and twirling of mustaches]. I'll retort that a database ISN'T actually part of your application. It's part of another application (or better put "an instance of another application configured in a particular way with particular information stored in it"). It might only happen to be accessed by your process but don't delude yourself into thinking they are the same application (this is why application logic is always put in the application code and not the db!). Unless they share your application space then they are not part of the same application (in-memory database engines for example being the exemption to rule usually but they're rare).

Anyways, once services became all the rage people started treating them like just another remote object technology, even if they weren't aware they were thinking as such. Everywhere you went everyone's wiring their front end to a "service". A "service" here and a "service" there. And suddenly everyone got to put on their happy faces and say "look at my application! It uses services! It must be good!". A "service" that happens to be only be used by their application to move objects out of the database into the UI. That's usually a sign that it's not a service. That's an API.

Now there's very likely a legitimate reason to use services for parts of solutions (note SOLUTION not APPLICATION there). Usually it's because there's a sharp well defined architectural lines in the solution that indicate there's several application domains constituting the total solution working in concert but independently to meet the requirements. If not then it is likely people are thinking like distributed objects (or "RPC via SOAP" as I used) and are not actually building services.

A quick refresher->
Service Oriented Architectures are built upon four tenets:

• 1. Service boundaries are explicit
• 2. Services are autonomous
• 3. Services share contracts not code
• 4. Services are compatible based on policy

How do I know if a service might actually just be an application API?

• My application actually has no behavior. Just an anemic domain model that just calls services.(tenant 1)
• My domain model looks suspiciously like the service model.
• My services are only meant to be called by one application (or are built in response to one application domain requirement) (tenant 4)
• My services move "objects" (formatted as XML albeit) and not semantic messages. (tenant 3)
• My services all are designed like an RPC call. They do follow the actor patter. (tenant 2)
• My services don't model a business process. (tenant 2 again)