Setting out for Service Component Architecture

IBM's Websphere Integration Developer product is a really strong SCA implementation.

Very illustrative article! SCA specification brings to SOA a common invocation model, allowing all kind of invocation methods. A very important addition in this concern is SDO. SDO works with SCA as a common data model. SDO specification gives to SOA the functionality to handle business objects as the data outside the components.

I have been developing with WebSphere Integration Developer (IBM software that implements SCA & SDO specifications) and WebSphere Process Server since last year and the implementation provided by this tools (especially WID, as an IDE) is very powerfull and allows an independent implementation of the service components and the assembly of the components.

Little summary… SCA gives SOA a technologic independent implementation, and specially detach the components from each other.

Henning, this is a nice overview, very helpful.

I wanted to respond to your comment about C++ / Java integration. Rogue Wave's HydraSCA actually does host both Java and C++ components in the same runtime and they can communicate in-memory (without web services) for higher performance, or of course with web services if you prefer. It's JNI under the covers, but the developer just sees SCA components.

IBM did found the acronym and pioneered the architecture approach. The should have credit for that. And for initiating OSOA. But it isn't an implementation of OSOA SCA. As an example, Integration Developer / WebSphere Process Server does not support dependency injection, which is a critical feature to keep SCA none-intrusive to service component business logic.

If I not getting all wrong with "support of dependency injection" you mean accessing other service using @reference annotation instead of using a lookup function...

Of course that is important that every implementation of SCA implements every aspect of the specification... and I agree with Johan that it should be like that.

On the other hand... the target of the dependency injection is to keep track of “what services are used by a component”, mostly for tracking the impact of changes...Ii think that all of that is possible with the assembly diagrams provided by WID. With this diagram I know, if I made a change, what components would be affected and what components will have to be, i.e., retested

But, again, is true that every implementation on SCA should follow exactly the specification... this will be important if in the future "they" want to make the specification become standard

Do you really need annotations when a .componentType file is provided for the implementation class? Annotations will require an import statement that will require SCA libraries on your classpath, although you may reuse the class in a none-sca set-up (e.g. in a pure Spring environment).

Very illustrative article! SCA specification brings to SOA a common invocation model, allowing all kind of invocation methods. A very important addition in this concern is SDO. SDO works with SCA as a common data model. SDO specification gives to SOA the functionality to handle business objects as the data outside the components.

Justin, sorry for not mentioning IBM's product. I should have. SCA evolved quite a bit and many integration aspects have been added, so that I was focused on what's going on right now.


Thanks, Henning


Ps.: Sorry for that late reply as well. I didn't check for a few days and didn't get any notice (or didn't notice) that there are comments

Patrick,

that sounds very interesting. Can you provide a pointer to more background information?

Thanks,
Henning

Right. SDO is an important utility in SCA. However, SCA does not depend on SDO as DTO implementation. During our implementation work we found that SDO is very useful however.

Thanks,
Henning

sure, it's in our product called HydraSCA. this is fairly high level, I can get you more technical info if you like:

www.roguewave.com/hydra/hydrasca.cfm

Patrick,

that sounds very interesting. Can you provide a pointer to more background information?

Thanks,
Henning

Ah, whether to annotate or whether to include metadata in separate files is a long debate. There are definitely some developers who prefer to keep everything relevant to a code module inside the code module. Annotations provide a standard means to do this in Java. Agreed, use of the annotations does tie the code to the annotation libraries - but as you say, the code does not require the annotations to be read in order to work.

In SCA it is also possible to keep the metadata outside the code modules, using things like componentType files.

Equally important, the assembler of an SCA application can override some aspects of the metadata, should that be necessary when composing the application.

So, I think SCA provides a useful level of flexibility in the creation of components and in their assembly into a larger application.

As for the question of injection - it is a style of programming which aims to eliminate the use of technical APIs - all that the component developer gets to worry about are business interfaces - the ones that are offered by the component and the ones that are used by the component. Of course, SCA gets to have it both ways - there ARE APIs which allow the programmer to go fetch reference proxies, if that style of programming better suits the requirements.

Yours, Mike.