Muhammad,
this is indeed very interesting.
I'll need to take a look at some of the references that you have provided
before I can comment further, but judging from your experiences (and others)
that looks like the incompatibilities between SCA and JBI have more to do
with politics than anything else.
So where is the roadblock coming from? Probably slightly off topic...
But getting sun and the rest of the Java voice to play nice together...
On 5/27/08, Mohammed Eljai [EMAIL PROTECTED] wrote:
Hello,
Jeff Anderson wrote:
This is all incredible feedback.
Thanks everyone for responding and commenting on a blog...
Peter, Mike
what would be a reasonable first step in trying to work towards a
JBI/SCA solution?
Realizing that some work i.e. papers have already been written on how
such a solution could work.
If anybody out there interested in seeing how Tuscany and open ESB
could possibly integrate together?
I know I would be...
I'm currently involved in the SCOrWare project [0], which aims at providing
a runtime and tooling for SCA (mostly in Eclipse STP).
In this project, we have been working on the integration of an SCA runtime
into the JBI ESB PEtALS [1].
Consequently, we now have a rather good experience about the links between
SCA and JBI. Since this is completely in relation with this thread,
I thought that you may be interested for some details.
The integration job we are performing consists in integrating a SCA runtime
(based on the Fractal model component) as a service engine into PEtALS.
It targets to make SCA composites benefit from the features provided by a
JBI platform. More precisely:
* Since SCA composites are executed in an SCA service engine, these
composites are exposed as any other service into PEtALS. As a result, a
composite can benefit from the features provided by PEtALS.
** PEtALS already provides several binding components (WS, JMS,
EJB...), which can be used by composites for the bindings. Besides, the JBI
standard provides mechanisms to easily extend these bindings and
support new protocols.
** SCA policies can use runtime policies provided by PEtALS, e.g.
reliability, security.
** SCA composites can also benefit from other service engines (like
XSLT transformations or BPEL execution).
** We can use the PEtALS administration console to monitor the
services and the remote references of the composites.
From this point of view, our SCA runtime fully benefits from the JBI
infrastructure to be a complete and extensible SCA runtime.
But coupling these technologies also brings more flexibility when you
target an SOA approach (in the general sense). Thus,
* SCA composite can reference any service deployed in the bus. Loosely
coupling is here inforced.
* In this case, these calls will automatically use features provided by
the ESB like routing or message queueing.
* Eventualy, if you plan to expose composite services with another
binding, you won't have to modify your SCA application. You will just have
to expose these services through the required binding component
(which is an basic operation in an ESB). This can be seen as partial dynamic
reconfiguration.
We recently made a presentation about SCA support into PEtALS, during the
last meeting of the OW2 Consortium. Please, see [2].
Fell free to ask questions or give your comments. I hope this helps in this
discussion.
Regards,
Mohammed EL JAI.
[0] http://www.scorware.org/
[1] http://petals.objectweb.org/
[2]
http://petals.objectweb.org/docs/OW2_meeting_SCAwithPEtALS_05_15_2008.pdf
--
Jeff Anderson
http://agileconsulting.blogspot.com/
