In his latest ComputerWeekly post, Cliff Saran attempts the unthinkable: to walk readers through the practicalities of SOA in a simple, straightforward way; no strings or vendor agendas attached. Can he do it?
The first rule of safe SOA is to "ignore the hype," he advises. Great advice. And he does a pretty good job of getting us around the hype, and even the feelings of inadequacy one may have because everyone else already has a huge, functioning, multinodal, galactic SOA.
He even hints -- no, says outright -- that you don't even need Web services to build your SOA. This is possible, but not necessarily practical -- but that will be the topic of a later post. "There is no need to use the latest and greatest protocols to support an SOA," Saran said.
SOA has been a dream in one for or another since the dawn of computing. (Okay, the 1980s.) First there was TCP/IP, then CORBA and DCOM, then enterprise application integration (EAI). All approaches had their drawbacks, and plenty of baggage and complexity.
Then came Java and Web services, which had far less baggage and complexity. "With a common SOAP-based interface, one application could invoke services in another application by sending specially formatted XML messages using the SOAP mechanism," Saran writes. "A directory of available services can be made available through a look-up table called UDDI (Universal Description, Discovery and Integration), an XML-based registry that allows organizations to find web services that can be reused in software projects."
Now, we have the logical extension of Web services, which is tying it all together into a service-oriented architecture. Teresa Jones, senior research analyst at Butler Group, views "SOA as management for Web services, providing the necessary support for service level agreements, authorization and contractual tie-in."
Saran adds that "along with the management aspects, an SOA has to ensure that Web services are used in a controlled manner. Otherwise, users could end up with applications creating an anarchic slew of point-to-point connections to Web services, resulting in spaghetti integration."
An example of SOA in action is Great Ormond Street Hospital, which has a number of "relatively simple" SOA-related projects underway, such as "driving a data entry form to contract to a back-end system, as in a request system to book annual leave." Another SOA-based project is the hospital's CRM system, which is used to manage donations.
The hospital's head of IT, Marc Saldanha, advises anyone looking to develop an SOA to "start simple and build up - we have fairly simple projects because we want to build an understanding of SOA."
Ah, simplicity is bliss in a hype-filled world. Can we learn to Keep It Simple, SOA?