In the first part of this series, we talked about the confusion in the SOA space and the difficulty in understanding the various standards activities. Specifically, we looked at the OASIS Reference architecture for SOA which presents an abstract model of SOA concepts. We also looked at the OMG UML Profile and Metamodel for Services Standard that is currently being developed to provide Domain Specific Modeling for SOA. To finish off, let’s look into the Open SOA Collaboration and their standardization activities.
Open SOA Collaboration – SCA and SDO
In August 2006, nine new companies joined the original 8 sponsors of SCA to form the Open SOA Collaboration. Their website, www.osoa.org defines the collaboration this way: “The Open SOA Collaboration (OSOA) represents an informal alliance of industry leaders that share a common interest: defining a language-neutral programming model that meets the needs of enterprise developers who are developing software that exploits Service Oriented Architecture characteristics and benefits.”
When I first read about SCA I wondered if it wasn’t a solution looking for a problem. I wondered why a language neutral approach to service assembly was necessary. Remember that SCA is not about orchestrating smaller services into composite services. For that we have BPEL. And certainly, programmers are not going to be mixing Java, perl, php, etc. within the same executable service. But my friends at SAP (a contributor to OSOA) explain it this way. Most programming environments, regardless of language, face a similar problem with regards to constructing services. So, why not have a standard way to do it that can be shared across different languages. When you consider a multi-purpose, multi-language development framework like Eclipse, this really does make sense. The same SCA plug-in could be used for many different languages.
To quote OSOA again, “SCA provides a model for implementing IT services that are defined in terms of a business function and make middleware functions more accessible to the application developer. SCA also provides a model for the assembly of business solutions from collections of individual services, with control over aspects of the solution such as access methods and security. Service Data Objects (SDO) complements SCA by providing a common way to access many different kinds of data.”
In other words, SCA describes a model for the technical implementation of service oriented applications, including exposing data through services. SCA emphasizes decoupling the service implementation and service assembly from the details of infrastructure and access methods. It builds on existing standards such as Web services and Java specifically for implementing service-oriented applications.
What does it all mean?
So why do we need all this and what does it mean? Well, SOA is hard. Services are hard to design build. J2EE didn’t solve the problem. Web Services didn’t solve it. (Hum, sounds like a presentation I’ve given…). Will SCA solve it? You be the judge. But what technology vendors continue to do is to raise the level of abstraction that developers need to deal with, and to separate concerns between what services do (the interface) from how they are implemented. All this is well and good, but it only addresses a part of the problem.
You still need an architecture that defines how services support the enterprise business and information models and how they fit together to support enterprise goals and business strategies. Such an architecture requires a consistent set of core concepts that spans the different architectural disciplines and abstractions. This is just what the OASIS Reference Model does. In addition, you need a way to design and model services at a logical level, with traceability back to business requirements. In other words, you need to extend the principles of separation of concern and abstraction beyond SCA and up to the next level. This is what the OMG Profile is intended to do. Finally, we can expect SCA to help make the implementation of these well defined services more flexible and extensible.
So just like we need different levels of abstraction in architecture, we also need different levels in our standards, covering concepts, design and implementation. We shouldn’t think about the standards as competing, but rather as being complementary. In fact, the OMG specifically calls out compatibility with OASIS and SCA as a goal for UPMS. Of course, the true test of the standards will be adoption and how well they are supported by tools. But, since there are relatively few tools that support them yet, it’s easy to take a wait and see attitude. Just, don’t forget the architecture, you can get started on that now.
