The term component is one of those words in the software industry that stirs the thought of "old wine in a new bottle." It's used to convey a wide array of features ranging from reusability to interoperability, most programming languages and platforms make use of it. Java, .NET , CORBA and PHP have components among their offerings, but now a new context is emerging in which to apply these same principles, its name: Service Component Architecture (SCA).
Like any initiative, there is always some entity that owns and gives the proper direction to such a project, and in the particular case of SCA, this entity is formed by a group of industry heavyweights: BEA, IBM, IONA, Oracle, SAP, Siebel Systems and Sybase. This list by itself should be an indicator that SCA has garnered the attention of more than a few mainstream vendors and thus will be on the radar as a possible approach to service-orientated solutions. But what is it about SCA that sets it apart from other service-orientated mechanisms?
At a high-level, SCA is yet another manner in which to build the services that will eventually form the cornerstone of a service-oriented architecture (SOA). However, the manner of building services as components is what makes it different from the rest of the SOA crowd. At a technical level, SCA's process for building applications consists of three major parts: Implementation, assembly and runtime.
The implementation consists of a language-specific approach in which to build SCA components, that in turn will be used to fulfill the service needs of an application. Such components can be written in either Java, PHP, C++, COBOL or use a mix of other languages like SQL or XQuery. The point here is that through a specific SCA implementation you will be able to package business logic written in any of the aforementioned languages and make it interoperate with any other SCA compliant component.
The added benefit of using this component approach compared to constructing services by other means is that ancillary concerns, such as security and transactions or issues like system bindings related to messaging or CORBA systems, are performed at a uniform level. That is to say, issues that are vital to many enterprise service settings are dealt with seamlessly across any SCA component, independently of the language used to build such components.
The assembly part of SCA is concerned with defining the interactions that should take place between SCA components, or as is commonly known, orchestrating the series of services calls -- constructed through SCA components -- that need to be executed to fulfill an elaborate business process. Finally, since no software component resides in a vacuum, SCA also makes use of its own runtime environment to manage SCA components, dubbed SCA runtime.
By this initial analysis, it should be no surprise that SCA has many resemblances to other technologies. The first similarity comes to the Java/J2EE platform which takes the same route of components and the separation of implementation from assembly. However, contrary to J2EE, which is rooted in the Java language, SCA has the option of executing components implemented in disparate programming languages.
Continuing with this line of comparison, even though a J2EE run-time -- application server -- has provisions for Web services enabled components and a series of bindings like JCA for ERPs or JMS for messaging systems, the J2EE platform is still not designed with the services mindset from the ground up like SCA, although, in effect, this can be considered the "new bottle" for the "old wine". Finally, one can only speculate the degree of influence J2EE had over SCA, being that vendors like BEA, IBM and Oracle which are among SCA backers are also deeply immersed in the Java/J2EE product line.
More importantly however is how SCA compares to all the "new bottles" in the SOA landscape, namely the enterprise service bus (ESB) and Java Business Integration (JBI), which are being promoted as necessary middleware to enable an SOA. The biggest chasm here lies in two fronts: at a technical and vendor level.
At a technical level, SCA differs from an ESB and JBI -- the latter of which is a standardized Java ESB specification -- because both try to solve different problems. While an ESB is charged with bridging the disparities that may surge within existing systems through a bus-like architecture, transforming and adapting requests via services, SCA's role is to offer this same service flexibility, but through a newly-minted application architecture. In this sense, SCA is more keen on being used as a fresh approach to building applications in the context of an SOA than a mediating middleware like an ESB to bring existing applications to participate in an SOA.
At a vendor level, while it may be a question of product line vision or simple coincidence, many SCA supporters who are also involved in the Java space have opted not to participate in the JBI/ESB approach, which puts into question not only the need for JBI/ESB, but more importantly the role SCA will play in the evolving battle for what approach is better suited to form the basis of an SOA.
With this we conclude our look at SCA, stay tuned for the next column when we will take a closer look at SCA and its closely related building block Service Data Objects(SDO), as we work hands on with one of the first SCA/SDO implementations named : Apache Tuscany . In the process, learn how this component technology pans out in the evolving scene of service-oriented architectures.
About the author
Daniel Rubio is an independent technology consultant specializing in enterprise and Web-based software, He blogs regularly on these and other software areas at http://www.webforefront.com/
