To dismiss SOA as "a web thing", "an integration issue" or an "XML remoting solution" is, I think, missing the whole point of what service orientation is all about.
The question I have is: Why shouldn't services be internal as well as external?
Yesterday I had a brief exchange with Jeremy Miller on the subject of how far you should take SOA. My personal view is that SOA should be engrained in every business problem you tackle, inside and out, whereas Jeremy's view was more than SOA is really an interface onto your system, much like the presentation layer, and should not interfere with the way your business layer is developed.
Material to the argument, he pointed to an article by Udi Dahan called 'Common SOA Pitfalls' - which basically says that it's wrong to categorize your services beyond labeling them as a 'business service'. I disagree. How are you going to develop a rich set of services if you're not allowed to categorize or layer them?
Lets get back to basics. By most definitions a service:
1. Is a function, with parameters and a return value.
2. Can be invoked independently of the rest of the system and platform. Black-boxed and should strive to be autonomous. You shouldn't need to instantiate other objects, inherit from objects, support specific interfaces, be a part of some elaborate hierarchy or use a specific language in order to use that service. You simply need to have the data that it needs, and be able to put it into a suitable format.
3. Should be highly accessible. Top level services should be accessible by well known protocols such as SOAP. If a service is independent of object models, interfaces, and platforms - why not make it as accessible as possible?
4. Should be built to be re-usable.
Is there anything in that list that stops you from using services internally, inside your systems as well as between your systems?
There are high level business functions and low level business functions that may only be relevant to one particular aspect of your business layer. But that doesn't make the low level services any less of a service, and it doesn't mean you have to develop business objects for the low level services. It just means that you need to structure your services into layers.
To structure a service layer means employing techniques such as encapsulation and grouping, techniques common but not exclusive to OO - so that you can easily find the services that are relevant to what you want to achieve. Services can build upon other services (known as composite services), and this technique can be used to build service layers. This doesn't mean you need to use SOAP to communicate between the services… SOA is not about a protocol, it's not even about XML per se, it's a programming methodology. Even if you're using static functions and abstract classes as your port types, you can still be reaping the benefits of SOA. This allows SOA to permeate your entire solution and not just your communication strategy. By adopting a service oriented design throughout your system you also have far more flexibility in deciding which of your services should be exposed to the next layer, through SOAP perhaps.
I'll discuss more options for implementing internal services in some future posts.
The bottom line: The key to SOA is that you build a rich set of services that can be re-used throughout your enterprise and applications. The key is not to expose the smallest number of services possible through a top level interface onto your business objects, just so you can tell your friends you've done SOA. That's faking it.