ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | eclipse-stp List | April 2006 Index

<--  Date Index  --> <--  Thread Index  -->

TR : STP Architecture Draft


Dear all,

Here is a draft of STP architecture ... Up to you for any comment

BR
Alain




-----Message d'origine-----
De : Oisin Hurley [mailto:ohurley@xxxxxxxx] 
Envoyé : mercredi 29 mars 2006 20:49
À : Karl Reti; Carl Trieloff; Alain Boulze; Oisin Hurley
Objet : STP Architecture Draft


Time for an architecture. This should reduce the various whining and  
gnashing
of teeth and help curb IBM's information campaign that this is an SCA  
only
project. This is a multi-runtime capable, multi-model-controller capable
project that has as its core an extensible assembly model based upon the
SCA code contributed by IBM. If you want to add your runtime to the mix,
then you need to provide packaging/deployment logistics (should they not
already be there) and you may have to provide some interpretation of the
model to suit your extensions to it. Your runtime does not have to be an
SCA runtime. The important point is that your runtime does not have to
be 'SCA compliant' in any way, but having it 'SCA compatible' i.e.
supporting concepts that are broadly similar in scope to the concepts in
the SCA contributed code would be a useful thing. This is an easy  
statement
because most models are similar for SOA, except for the odd curlicue and
specialization. One thing that you may have already noticed is that I am
not referring to SCA as a 'standard' any more - it's a full-read,  
best-effort
write activity whose nature is poisonous to open source: it's already
got JBoss in a tizzy of the highest order. The fangs will be pulled when
the thing is submitted to a 'real' standards organization, but that will
be a while in coming. We need a FAQ for this, I would welcome any worthy
wordsmithing ;)

The model can be extended on both ends of course - the controllers  
attached
to the tooling surface may interact with an extender, or if extension is
not required, an adapter may do the trick.

The purpose of this architecture is to allow us to construct a  
roadmap by
having architectural artifacts which we can use as attachment points for
contribs and for collaborations, e.g. Sybase committing some deploy  
stuff
for getting to containers, IONA committing some model control stuff for
WSDL/IDL and a model extender, ServiceMix committing a model adapter/ 
extender
for JBI, WSDL tooling surface to come in from WTP etc etc.

Note that this is developer-centric arch, which is the usual Eclipse
thing, but we also need to have a good idea of the tooling that will add
value for users of the project during the operational lifecycle of the
SOA. There is most likely a lot of material in TPTP that we can mine for
this at a later date. One thing that is missing from this  
architecture
is good stuff around the notion of persisting the assembly model, be it
a trivial file-based serialization or something a bit more advanced like
persistence to an rdbms thru uddi or directly.

In summary, I think the diagram below serves us better than the one we
have on the website at the moment :)  Can you take a long look at it and
give me your comments, please. The sooner we post this to the web site
the more pleasant our lives will be :)

  cheers
   --oh

Attachment: stp-arch.gif
Description: GIF image



<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.