Logical Services

In web service composition (service piping, orchestration, etc.) you have the ability to make one service front-end multiple services. In BPEL, every orchestration is exposed as a web service despite the fact that it potentially encapsulates *many* web service calls.

I've blogged in the past about how the granularity of the service shouldn't matter. Granularity should be adjusted on the fly (when possible). I've blogged about *cheats* - that is, in-process calls that never actually used the network services (TCP & HTTP) - or even web service calls that were too lazy to use XML Schema - they realized that they were running in the same JVM or CLR and just used shared memory. These concepts are related to my vision of SODA (a concept popularized by Darryl Plummer at Gartner) or Service Oriented Development of Applications. The fact is that SODA doesn't work unless you cheat. You must have both static and dynamic optimizations of service-to-service calls.

When you do this you begin to realize that the piece of code that you called your 'service' was aggregated with another piece of code also called a 'service'. After a while, you realize that all of your services were really just logical things that could have their boundaries redrawn.

Web services are logical - hell, software is logical. The interfaces, the boundaries, the messages between them - all logical. Thus, the ability to recombine them in new ways is not only possible and practical, but perhaps inevitable. Future SODA tools will have the ability to *compile* multiple services together into single service.

Now, what does *compile* mean? Hmm... interesting question. Well, it could mean actually compiling. Or it could mean orchestrating. Or perhaps, just redelivering the service to a runtime container that knew how to *cheat*. Any way you look at it, the art of SODA will be about the ability to combine services in a variety ways. It should protect the black-boxed nature of the service while still giving the developer all of the functionality and performance of a compiled application.

SODA is the evolution of programming; when should an object be a component? When should a component be a service? If you answered these questions based on interface granularity then you don't understand SODA.