John Wood

SOA and Taking Services Further

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.

Programmer's Perspective: What is Workflow?

We all have implemented business functionality in our software at one time or another. Business functionality covers any kind of programming that means translating knowledge that's specific to a business to the screen.

However when we do this, we are translating that business functionality into something that's very difficult for anyone but a programmer to see and maintain. We're quite literally "encoding" the process, and once it's encoded it often gets locked away forever.

The problem here is that those specializing in the business, the business specialists, can no longer see that business process. And that's a liability, and frankly a shame seeing as they're the experts in the business!

Workflow is the name given to a type of business process modelling that is easily accessible to those specializing in the business. It allows the model not only to be encoded into something the computer can understand, but it also allows the process to be ratified by those who understand the business better than they understand the computer.

So typically the primary feature of a workflow system is the workflow designer, which - to enhance the readability - is presented as a graphical flow-chart that can be edited interactively. No IDE here, just drag and drop flow charts that is as simple as creating a shopping list.

What also differentiates workflow from classic business algorithms is that workflow often represents processes that can run over a significantly long time, involving multiple user (human) interactions over a period that can sometimes be weeks.

While you could program these in C#, for example, you'd have to deal with a plurality of different situations including transactions, recovery, monitoring, resource maintenance, security, timeouts, and exception processing. Workflow engines handle all of this for you - all you have to do is specify the flow of the information and tell it what to do in case of an exception, without having to worry about detecting the exception or timeout itself.

For programmers, workflow may seem overly simplified and restrictive. But the advantages of being able to get the business specialists involved in the development process is a huge advantage to companies where there is usually a huge gap between development skills and business knowledge.