Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Setting out for Service Component Architecture
Posted by Jean-Jacques Dubray on Oct 18, 2007
There has been some debate, here and there recently about what is SCA v1.0 about? Henning Blohm is a Java EE Software Architect at SAP and co-chair of the SCA-J committee. In this article he gives us his answer.
it is easy to get lost in the SCA universe...[and there] is little experience with using SCA in the community.
The article contains a list of projects involving SCA as well as a series of references. He develops the argument that SCA is about:
... integration with existing technologies...A deep integration of SCA assembly with a given environment reduces nasty model frictions introduced by abstractions that try to generically wrap any sort of runtimes into one common "higher" runtime model.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
IBM's SCA deserves a mention
by
Justin Wood
Posted
Re: IBM's SCA deserves a mention
by
Johan Eltes
Posted
Re: IBM's SCA deserves a mention
by
Alvaro Gareppe
Posted
Re: IBM's SCA deserves a mention
by
Johan Eltes
Posted
To annotate or not to annotate....
by
Mike Edwards
Posted
Re: IBM's SCA deserves a mention
by
Henning Blohm
Posted
SCA & SDO
by
Alvaro Gareppe
Posted
Re: SCA & SDO
by
PJ Murray
Posted
Re: SCA & SDO
by
Henning Blohm
Posted
C++ & Java in SCA
by
Patrick Leonard
Posted
Re: C++ & Java in SCA
by
Henning Blohm
Posted
Re: C++ & Java in SCA
by
Patrick Leonard
Posted
-
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.
In addition to providing a data object, SDO also provides a common data access API - currently in Java and C++, but with additional languages coming. -
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.cfmPatrick,
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.
12 comments
Watch Thread Reply