SOA and Components

Seems like finally they got it. Read the following statement that is taken from
IBM Developer Works. The page describes an initiative by IBM, BEA and the usual other suspects to build what they call a Service Component Architecture (SCA):

SCA encourages an SOA organization of business application code based on components that implement business logic, which offer their capabilities through service-oriented interfaces and which consume functions offered by other components through service-oriented interfaces, called service references. SCA divides up the steps in building a service-oriented application into two major parts:

The implementation of components which provide services and consume other services

The assembly of sets of components to build business applications, through the wiring of service references to services.

SCA emphasizes the decoupling of service implementation and of service assembly from the details of infrastructure capabilities and from the details of the access methods used to invoke services. SCA components operate at a business level and use a minimum of middleware APIs.

This initiative writes down a couple of important concepts. SOA and CBD are basically the same thing; it depends on the viewpoint whether you put a service or a component into the "middle of the universe". Component implementations should be independent of the middleware technology. Specifically, that means that you can run the same components in the context of different middlewares (e.g. J2EE for production, Spring for testing). And finally, communication in SOAs is not restricted to web services.

Why do I make this a Blog post? Mainly because I have been talking about this view of the (SOA) world for a long time and I am really happy that this seems to catch on in the "industry" now. For example, if you look at my talk about Component Based Development that I gave at the 2005 edition of ICALEPCS you can see this approach all through the slides.

If you combine the SCA approach with MDSD this can get you quite far, as outlined in the presentation I linked to above. I have defined a set of typical metamodels that you can use as a starting point for this kind of architecture.

You start by defining component types and their dependencies as well as data types (not shown). After drawing that diagram and generating the necessary skeleton component implementations, you can start implementing them.



Then you go on by defining collaborations of component instances; they play together to achieve some goal. No mapping to a specific technology, yet, just logical component instances playing together.



Finally, you can go on by deploying these collaborations to certain technical platforms. Based on these three models (plus some technology-specific information that you should incorporate by model-weaving), you can generate all the necessary code to put the component implementations into the infrastructure defined in the deployment model.



In order to allow for multiple compositions of the same component types, and also of several different (technology-)deployments, you must make sure that the dependencies are directed correctly:



So. I think SCA points in the right direction. Combine it with MDSD, and you are on a really good way. We have been using this approach in various projects, and a big international mobile phone company (my current customer) buils their SOA architecture around these concepts.

A final word: Microsoft's WCF (aka Indigo) looks very much the same ... one could get the impression they copied from there (rather than from my slides :-))  permalink