Laying the groundwork for 'process oriented architecture'
At last, some folks have been diligently working on a common definition of "SOA" most of us can live with. But because the definition has to withstand the test of time, there are some interesting omissions.
I recently had the opportunity to chat with Joe Chiusano, associate at Booz Allen Hamilton and a member of OASIS' SOA Reference Model Technical Committee. The SOA-RM is in public review stage, and Chuisano and his colleagues hope to release it as a spec before the year is out.
To date, there has not been a solid definition of what constitutes a "service-oriented architecture." There has been raging debate, in fact, on what exactly an SOA should be. What is an SOA Reference Model you ask? According to Chiusano, the mission of his group is "to create a common vocabulary for SOA, or common semantics, within an open standards consortium, being OASIS."
Why is a Reference Model needed? "One of the primary problems that we're solving is the lack of such a standard vocabulary and definition and description of SOA," Chiusano explains. "And when I say definition, it goes beyond just the simple one or two sentences of what SOA is -- the fundamental part. It also encompasses all of the things that we have in the specification, our current committee draft, which are the fundamental concepts that comprise SOA, and the relations between them." The committee is also in the midst of developing a reference architecture that puts the model in more concrete terms for implementations.
To date, there has not been a solid definition of what constitutes a "service-oriented architecture." There has been raging debate, in fact, on what exactly an SOA should be, and how much of it is Web services, and how much of it is other types of services.
Chiusano and the SOA-RM committee hope to finally settle this question, but not lock in technologies or methodologies that will be outdated 10 years from now. In fact, he notes, though Web services are to be considered an integral part of SOA going forward, “we make it very clear that first and foremost, we're talking about SOA apart from Web services," he says. "But we do recognize that Web services are an implementation choice, and frankly, the most common one you'll see today."
The SOA-RM is being designed to "stand the stand the test of time," he adds. "If you're too concrete, you can't stand the test of time. Twenty years from now, we'll be looking at the spec, and we'll be asking ourselves, 'is it outdated?' and the answer will be 'absolutely not.' We've been very careful."The SOA Reference Model outlines concepts such as "service," "service description," "visibility," "real-world effect," and "contract and policy." A real-world effect, for example, may be the result from interacting with a service. For instance, Chiusano explains, "if we had a service consumer that wanted to reserve a seat on a plane, and the airline was the service provider. When all is said and done, and everything goes well in the transaction, the real-world affect would be that a seat is indeed reserved on a plane."
The SOA Reference Model may be employed in mergers between organizations. "One way they could use this reference model is to find commonalities across various SOA implementations, for perhaps services that provide the similar or the same real-world effects," Chiusano says. "They may consider consolidating these into an authoritative service."
However, the committee had to omit other aspects some may consider part and parcel to every normal functioning SOA. To build a spec for the ages, the SOA-RM committee had to bypass features such as loose coupling, fine grainedness, and coarse grainedness. "We do not address those because they are too specific to a given implementation," Chiusano explains. "What may be loose coupling for one may not be to another. If we had a hard and fast rule, and recommendation, I think we would have pigeonholed too much."
The committee also had long debates over processes, which are another key part of SOA, Chiusano reports. "Do processes belong? How much does orchestration belong? That's another case where we don't have orchestration or choreography as concepts. We do talk in terms of processes, in the reference model itself, as part of the behavior model and process model."
Chiusano also speculates that the future may even see a rise in interest in process oriented architecture, or POA, which is handled in this reference model. For now, though, "we needed to tackle the fundamentals and the foundation and the basics first, and tighten those up and get them stable, so that we can have other things based on them," he adds. "I can see the strong possibility of a POA technical committee in OASIS in the future, and hopefully a reference model for POA. We'll have the mapping between them in terms of how processes can be created through services."