Governments provide services, right? So why not provide them via a Services Oriented Architecture (SOA)?
Does that question actually make sense? Governments provide services like trash collection, street repairs, public safety, etc. These kind of physical services are not going to be handled by any advanced computer network, or at least none that we can imagine today.
But wait a minute. Governments also provide informational services. Is this car title valid? Does this driver’s license belong to the person in front of me?
And not just inquiries. In principle, residents could pay their taxes, renew their business license, or indeed perform over the internet just about any interaction with any level of government that does not require their physical presence.
And not just residents. Businesses, sibling agencies, and other levels of government from national to local could conduct whatever business they need over the internet. Anyone who interacts with a service in this manner is said to “consume” that service.
So, when we talk about providing government services or intergovernmental data exchanges via the internet, is that an SOA? Well it could be, but not necessarily. Many government computer systems provide public informational or transactional services today, but not many of them may be provided as part of an SOA. A browser does not indicate that an application is services oriented.
SOA Defined
When we talk about a Services Oriented Architecture, we are actually talking about several things:
- The actual business service being provided which is visible to the consumer of the service on his or her computer; this is also sometimes referred to as a “composite service” or a “coarse-grained service.” This means that, in addition to the program logic within the service definition, the composite service may consume other, finer grained, supporting services.
- Supporting services provided by computer systems which are not normally visible to the final consumer, but which form part of the composite service; although finer grained than the composite service, these supporting services may themselves be composed of their own program logic, still finer grained composite services, and atomic services.
- Atomic services provided by computer systems which are at the finest level of granularity, and do not consume any other services. These services consist solely of their own program logic, though they may use databases, message transports and other components of the computer system.
- The method by which services encode data for the consumer of the service, and to pass to and from other services. This is almost always be in some form of XML.
- The method by which services actually pass that encoded data to and from the consumer and to and from supporting services.
- The dictionary which defines the precise meaning of each data element passed between services. Creating and maintaining this dictionary is one of the most difficult aspects of building an SOA, because very often people don’t realize that they mean slightly different things when they use a word.
- The repository of all of the definitions of the services, so that anyone who wish to consume a service can discover what services are available, what data has to be passed to the service, and what data will be returned.
So, if we have all of these things, then we have deployed our services in a Services Oriented Architecture. This is a new way of thinking about how to organize computer systems. For the first time, there is a universal way for all computers to talk to each other. That is, an SOA provides universal accessibility to any and all services, so that anyone who adheres to the rules of an SOA can provide or consume services to or from any other SOA. This has never been true before between dissimilar types of computers, or at least without great difficult and expense.
This is also true regardless of the type of computer system employed. It can be a multi-million dollar mainframe, or a large Unix server, or an Intel server running Windows or Linux, or it could be your own personal workstation, laptop or cell phone. Or it could, in principle, be your car or your refrigerator, though in practice that’s still a ways off.
What may not be obvious is that once we have built up a library of atomic and supporting services, new applications become much easier and quicker (and cheaper) to snap together. For over 30 years, we have sought the Holy Grail of re-usability. In SOA, we can finally deliver on that elusive promise.
So What About Legacy Systems?
Of course, so long as we are talking about new computer systems, it is reasonably easy to understand that they could be built with a services architecture. But what about the existing computers? We have millions of dollars invested in the software that runs them. We can’t afford to just throw it all away and rebuild everything. Even if we had the money, it would take many, many years to do so and – particularly – it would take even more years to get it done correctly.
Well, the good news is that most legacy systems were constructed with an architecture based on sending and receiving messages. That’s the hard part. If the application already understands the exchanging of messages that goes along with providing and consuming services, then it is pretty easy to modify the application to understand the XML that will be exchanged, and to use one of the universal data exchange protocols such as HTTP, the basic method of data exchange over the internet.
Or, if you don’t want to modify the application, there is a new generation of tools to retrofit mainframe or server based applications easily and simply. If you have workstation based application systems that interact with a single user and without a browser, then you do have a problem. But these can be opened up reasonably easily, just not as easily as the mainframe or server applications.
Where Does BPM Fit Into an SOA?
Of course, when we build a new application from scratch on a BPM platform, it is pretty easy to consume any existing services. In fact, one point of view says to develop new applications solely as atomic services, and then use BPM to glue those fine grained services together into composite services that offer real business value.
The slightly tricky problem is to define a BPM workflow in such a way that it can be a supporting or atomic service as well as a composite service. However, with a little thought at the beginning of the project, BPM based transactions can provide as well as consume services via an SOA.
Summary
If we start to think of a computer system as a collection of services, some composite, some, supporting, and still others atomic, then we have come a long way from thinking about programs, subroutines, TP monitors, databases, and the whole menagerie of strange critters that live inside each computer system. If we implement or retrofit our programs on this services model and deploy the SOA supporting infrastructure, then we can gain a dramatic increase in business process (and therefore personnel) productivity.
