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
