Service Component Architecture? I am a HUGE fan!

The OASIS work on Service Component Architecture really fills an important niche in the pragmatic side of SOA. It is probably the most concrete and pragmatic work for companies to use when taking real steps towards SOA nirvana. SCA is composed of a set of specifications that are very closely aligned with and build on the OASIS Reference Model for SOA.

Imagine this scenario. Your CTO/CIO comes back from some conference and blurts out, "We have to do SOA. All the cool companies are doing SOA!" As an architect/developer the question looms: "What does this really mean?. Sure you can use the abstract Reference Model as a basis for an intelligent conversation on SOA but organizations really need something more concrete to take steps in the real world.

SCA is your answer. The work, originally from the Open SOA Alliance, is now under the auspices of OASIS. SCA is a set of related specifications which describe a model for building applications and systems using a SOA. It is based on business functions being provided as a series of services, which are assembled together to create solutions that serve a particular business need. SCA describes how services are based on a set of related business functions on two levels, one abstract of the actual binding. This is highly advantageous in order to preserve the lexicon of service definitions independent of the specific bindings used.

SCA extends and complements prior approaches to implementing services. Extensions include a programming model for building applications and systems based on open standards such as Web services as well as specific programming languages. The models should be highly effective for business stakeholders and technical stakeholder to align and describe services at various levels of abstraction including their purpose, interfaces and capabilities.

It's important to note that SCA is actually expressed as a group of related specifications, ranging in levels of abstraction from mid-level models to concrete bindings to several specific programming languages (Java and C++ were first).

Adobe has recently joined this effort within OASIS. The work is very relevant to our service oriented platform (LiveCycle Enterprise Suite or LC ES) architecture. In fact, many of the core tenets of SCA assembly have been inherent in LiveCycle ES's design for a while. We use many concepts similar to the service descriptions within the registry-repository component of LiveCycle ES. This allows people to use tools like the LiveCycle Designer and Workbench to assemble services into functional processes and aggregate applications.

I am looking forward to participating in this great work done by IBM, BEA, Oracle, Fujitsu, Hitachi, Red Hat, SAP, TIBCO and many others.