[stp-dev] minutes of EclipseCon committer's meeting

[Oisin Hurley <ohurley@xxxxxxxx>]

Hi all,
Please find below the minutes of the committers meeting that we held
at EclipseCon 2006. Thanks to all attendees for turning up at 8pm
for this meeting! The minutes contain the gist of the conversations
that we had at the meeting rather than the verbatim conversation,
so please let me know if anything here seems contradictory to what
you heard or said in the meeting.

regards
  Oisin

----------8<------------------8<-------------------8<----------------

STP Committers Meeting Wednesday March 22, 2006
Minutes

PMC =>  Oisin Hurley, Carl Trieloff, Karl Reti, Alain Boulze (Naci
         Dai deputized for this meeting)

Contributions:

. IBM's EMF model for Service Assembly is in Bugzilla -- URL send to
   newsgroup

. Scapa has committed the b2j code.

. Intalio - we will be contributing a BPMN modeler and underlying
   metadata model, we are working on eliminating some of the
   proprietary parts as we move to eclipse and gef.

. Sybase - we have the DTP components that already exist and we want
   to leverage these to provide a way to deploy to multiple run-times

. IONA - we have to firm up but it will be a way to integrate with
   multiple protocols

What about JBI? ObjectWeb has petals and they are wiling to donate to
the stp project in supporting runtimes with different standards.

Corona guys want to use SCA to help deployment of OSGI.

Service mix is working with Apache Tuscany to align overlap areas.  We
have some early code with a JBI engine and we are investigating if it
would fit with this project so we are trying to understand scope.
Someone needs to take the lead on driving closure on the JBI - maybe
we could have some flow from ServiceMix guys on progress - drive it
from the run-time side?  We need to figure out packaging and how we do
it.

Karl (Sybase) - Are you talking about accepting SCA assemblies into
ServiceMix and being able to deploy those?

Winston - The two communities haven't done anything together, the
committers are exploring using it but we haven't done that much
together so far.

Alex (Intalio) - What is the system architecture of STP?  Carl -
Charter calls out that the assembly model is SCA because it's the best
working attempt to create a model that is technology and
implementation neutral so you can deal with all types of technologies.
We would like all services to be deployed across all run-times with
primary runtime not requiring translation being an SCA runtime.

Alex (Intalio) is there a document that shows the specification?  Yes.
You can google and find the SCA specification.  The specification is
the SOA assembly model (core contribution from IBM), specification for
each binding, assembly language, for example how to bind to C++ etc,
the SOA System, and then run-time.  Carl described a bunch of things
that can be found in the charter and other docs.


Module - Service Creation Model - SOA Assembly Tying of these up and
visualization of how components come together in the wiring - the SOA
System (SOAS)

Alex (Intalio) When looking at the marketecture chart in STP
presentation, have the APIs been defined?  What's the real
architecture?  It will be based on SCA at the core, and we were
waiting to get the contribution and it is now in.  component is an
implementation with a contract, a module contains components and is
the unit of deployment - sort of like a WAR or EAR file.  At subsystem
level wiring together modules that are communicating together remotely
with one another.  Recommended that people read the spec and then ask
questions on the dev list.  Is the subsystem model part of the spec?
The system is not formally modeled but everything else is part of the
contribution.


3 things to discuss
1) JBI/Tuscany issue
2) SCA to JBI Mapping
3) Xform from SCA to produce packaging for the actual execution to
   the platform of your choice

Probably seeing the code we can now provide feedback.  Winston will
make sure it is posted on ServiceMix list about SCA model
availability.  The OSGI discussion will probably happen on the Equinox
list.  Corona team will make sure anything appropriate will be sent to
the STP dev list.

Lets drill into the subproject items.  Now that we have code, we need
to get the build going.  Naci has promised to help out to disseminate
how the system will work, he understands WTP system and we will adapt
that system to our needs.  The goal is to try to get the ball going in
next week or two to start moving forward.  Does anyone else want to
help?  Someone from IONA will help - looking for volunteers from other
organizations to give coverage.


DavidB, Naci, Carl, Maven Man:
In terms of code quality issues, in IRC we agreed to be sensible on
what will be required.  We would be good citizens and write tests but
it is not formalized.  If you make a merge you have to send a mail out
saying what is in that merge.  You are strongly advised to write good
tests and have your code reviewed but it is not strictly required.  We
use retroactive code review process - meaning you put it in and if
someone doesn't like it then they let you know.  The WTP build tests
for API coverate as well and that forces a certain level of test.  Two
parts - automated test and then there is an accountability on the
calls if your tests fail.  WTP Build is basically platform build but
other things are attached to it like the APIs - unique to WTP.  With
each build we run the tests.  Carl and guy from Maven will give input
- we don't have a build system right now.  We are thinking to use the
WTP template and we will be building it in the next two weeks.  Maven
is great but we have problem applying it to eclipse because they are
dependencies in OSGI not maven, you have to build the plugin xmls -
that is the only stopper using maven for eclipse.  Automated firing of
tasks is built in. Maven/Eclipse PD build is an issue outside the
scope of STP, a Platform thing. The PD build is already setup to do a
lot of what we need.  This project may be building more than just
plug-ins.  We could use PDE for plug-in and maven for non-plug-in
artifacts.  Lets build a build team.  Naci will be the build leader.

Oisin:
Service creation - we had a number of conversations about service
creation on the mailing list.  The creation of a service is a phased
approach - you set up a staging - a contract is for example an
interface and metadata, then when you move onto assembly for example
the XML serialization descriptor files pointers to the inside of a
WSDL, - the SCA definition is about wiring, but it didn't focus on the
action of I am going to put together an interface for my service.

Dan:
Creating a service is a bit abstract, creating an interface I
understand that.

Oisin:
If you use the (IONA) tools ship it includes
creating an interface, defining bindings and code to implement it and
bring the service in.  We don't do assembly.  SCA is good at assembly
but not strong with the contract with the client.  From what I am
seeing our customers doing I see it as what is the service going to
look like to the consumer of the service all of the information that a
client will need.  This is a top down model.  Tops down interface
first.  The commonality of it is the creation of the interface part.
You can sketch out your participants in your assembly and build it
like that.

Dan:
If service is JAX-WS service, there will be a whole set of
tools.  The line splits when you get to the implementation type.  The
contribution supports bottoms up and tops down you can create a
component without an implementation.  You can wire a whole
implementation together.  We have a way to use introspection to look
at service and take the contract and apply it to the implementation.
In bottom up situation your introspector - in wtp where your provide
for EJB there would be a registered introspector that would be able to
know with 2 way introspection and the implementation will store the
information that stores the contract.  You have an introspector for
ejbs and pojos for example, is there enough in there to allow others
to make it extensible.  Just pojo is there right now.  EMF will be one
unit - service creation and assembly but maybe some of the specific
domain specific extensions could be broken out like PHP.

Dan:
I think we need to get into a paradigm where other projects own the
extensions rather than it sitting in STP, so for example some in WTPs
and have dependencies.  We also have a second contribution that is
coming from another group at IBM around integration with component
implementations - there is another layer that provides language
integration for different interface types, UIs to be built.  This
other layer provides extensions that would make it much easier to
build UIs.  We can put out documentation on what it will do, legal
approval is still pending.  Hopefully a couple months.

Oisin:
Let's have everyone look at the code and then we can figure out if we
want to flatten out the subprojects, maybe just have core and system
and then some extensions either under STP or external to STP.  At the
implementation level we need to be careful, many implementations don't
require STP.  We want STP to be extensible without pulling in code
that requires other projects.  We don't want to do a binding from STP
to BPEL or WTP (bad example) we will have dependency on WTP.

??
There are a couple handy things we could use back and forth STP and
WTP but for end-user if I have to download WTP to get STP would that
be a problem?

John:
Have you evaluated using the WTP runtime framework or facet?
No.  If you want to champion it join the dev list.

Karl:  we have spent a lot
of time looking at it - it's a mixed bag.  We've done quite a lot of
work on it.  In one of Sybase's products they use both WTP and this
newer model and looking at using parts of both together.  How about
how to deal with proprietary parts of servers, that is where the
facets came up.  You will get profile structure from DTP anyway.
Right now it is for databases but could be used for service containers
as well.  It would be really nice if we could find a way to bring
these two models together.