Until now, SOAs have never been precisely defined. In response, most software vendors will tell you what SOAs are not they are not conventional monolithic applications that bundle lots of different functionality together.
Or they will give you a response that sounds a lot like a former US Supreme court justice’s description of pornography although they can’t define it, they know it when they see it.
The new Oasis committee, formed six weeks ago but just announced publicly, seeks to develop a reference model that lists the elements of an SOA, and specifies how those elements relate to each other.
Chaired by Adobe Systems’ senior standards strategist Duane Nickull, the reference model is targeted at developers as a guideline for implementing SOAs, and for vendors as a way to ensure that their products are SOA-compliant.
Many of us felt that SOA should be definable as an architecture, said Nickull.
For instance, services are often confused with objects or components because they are all modules of code that have standard interfaces that the modules declare, or publicly announce. During the committee’s first six weeks, lots of stabs have been made at answering that question.
One early thought is that objects or components are modules that operate within closed environments where all the interfaces and conditions for interaction are known, whereas SOAs involve modules that interact across different environments through discovery mechanisms rather than preset ground rules. SOAs only require that the service description and service request speak common semantics.
We have embraced discovery, availability, and presence as the three core aspects of an SOA, Nickull said, adding that discovery does not have to involve a registry or repository. For instance, services could be announced through a broadcast or multicast model in place of a registry.
According to Nickull, the committee has already drawn 90 members and observers and is still growing. They plan to issue a reference model by the end of the year and have the option to form a subcommittee that could develop a more specific reference architecture.
