Re: [stp-dev] Skeleton outline for Service Creation subproject

[Daniel Berg <danberg@xxxxxxxxxx>]

Hi David,

Regarding your first comment on the
stability of SCA.  While the 0.9 version of the spec is a good start
there is still a lot of work to be done.  So this will mean changes
will be made to the specification prior to the 1.0 version is declared.
 This will cause some amount of churn in the code (both runtime and
tools) but it is better to base the tooling off of a specification that
has growing adoption and has a plan to move towards standardization than
to make up our own model for assembly.

I agree with the matcher solution as
well.  I think it will perform much better and is a much more direct
approach for doing the matching.

Regards,
Dan

David.Brandow@xxxxxxxxxx
Sent by: stp-dev-bounces@xxxxxxxxxxx

03/09/2006 10:02 AM

Please respond to
STP Dev list

To	STP Dev list <stp-dev@xxxxxxxxxxx>
cc
Subject	Re: [stp-dev] Skeleton outline for Service Creation subproject

I guess my first general comment would be that I'm not convinced of the
stability of the SCA spec at this point.  I have no real point, I
just wanted to say it. 

In the absence of much else concrete to talk about, perhaps we should discuss
the matcher solution vs. the canonical model solution.  Personally,
I'd prefer the matcher solution, it seems on the surface to be easier to
extend and although its likely more work, I'm leery of greatest common
denominator solutions, often the answer is too low a number.  To map
it to the real world, if you are trying to interpret different languages
(English, French, Mandorin, German, ...), while in principle you could
convert from the source language to a common language (Esperanto?) and
then to any destination language, in practice its too lossy a translation.
 Perhaps this isn't a very good analogy, and this is only one person's
opinion, but I felt the need to have a somewhat concrete discussion about
something. 

-----------------------------------------------
Keep your stick on the ice,

David Brandow
Sybase EAServer Engineering

Daniel Berg <danberg@xxxxxxxxxx>
Sent by: stp-dev-bounces@xxxxxxxxxxx

03/08/2006 11:51 PM

Please respond to
STP Dev list <stp-dev@xxxxxxxxxxx>

To	STP Dev list <stp-dev@xxxxxxxxxxx>
cc
Subject	Re: [stp-dev] Skeleton outline for Service Creation subproject

Hi All, 

I haven't seen any comments on this picture so I will start firing.  :)

First of all I don't really understand the picture.  For example I
don't know what each element in the picture is supposed to represent.  What
is an IContractSource or an IContractContribution?  For that matter
what is a contract or the ContractModel? 

So without going much further into this picture I want to throw out some
other important points. 

1.  SCA already defines an extension mechanism for interfaces (e.g.,
Java, WSDL).  The interface is the contract between components.
2.  SCA defines a ComponentType (bad name) which describes the contract
supported by a given implementation.  This "contract" describes
the configurable elements of an implementation (i.e., properties, services,
and references). 


As part of the proposed IBM contribution to the core subproject we have
an EMF model for SCA.  In this we have an extension mechanism for
registering implementation "introspectors" which will be used
to resolve a given implementation for a component and return the ComponentType
(contract).  There is a well defined API for instropectors to react
to changes made by clients (i.e., editors and operations) to the in memory
ComponentType definition.  When this happens it is up to the Intropsector
to resolve the changes and drive them back into the implementation.  There
is also a set of APIs that allow introspectors to react to their individual
implementation changes (using the best mechanism that suites the implementation
type) and drive those changes  back to the in memory ComponentType.
 Clients will then use standard EMF notifications to react to changes
to the ComponentType (i.e., update UIs). 

There is still a lot that needs to be added to this core contribution but
it is a good start.  For example we need better rules for matching
interfaces.  This would be interfaces of the same type as well as
interfaces that are different types (Java to WSDL).  The question
here is whether we need a canonical operation model for all interface types
(e.g., we could use WSDL/XML Schema for this) or is this really overkill?
 Would it be best (and faster) to register interface "matchers"
that would be type specific to handle domain matches.  For example
if a new interface is introduced into the tool then by default a matcher
would be required to handle matching interfaces of that type.  Other
matchers would be required if we wanted to supported this new type matched
to other interface types (i.e., php to WSDL or Java to C).  There
are pros and cons to both the matcher solution and the canonical model
solution that need to be discussed. 

I know this isn't very fair since we don't have the IBM contribution delivered
yet but I want to ensure everyone that we definitely intend to contribute
our core tooling in this area based on the public SCA specification.  There
are several processes that we have to jump through within IBM to contribute
code to the open source.  We have done most of the jumps but there
are still a few more left.  We are pushing to get this done as fast
as possible. 

Regards,
Dan

-------------------------------------------------
Daniel Berg
IBM Rational SOA Tooling Lead
(919) 486-0047

Oisin Hurley <ohurley@xxxxxxxx>
Sent by: stp-dev-bounces@xxxxxxxxxxx

03/08/2006 06:50 AM

Please respond to
STP Dev list

To	STP Dev list <stp-dev@xxxxxxxxxxx>
cc
Subject	[stp-dev] Skeleton outline for Service Creation subproject

Hi all,
To get some discussion started on the SC subproject, I've attached
a picture of how I see the deliverables being structured as a strawman.

There's a couple of ways to get a service together - you can pull
in existing implementations and infer how it is going to appear
from those, or you can start with a clear slate and construct the
appearance, then create the implementation starting point from that.

I think we will need to support both these approaches, and the way
to do it is to define a core model of a service contract then
enable a diversity of contributers to the contract. You can easily
see how one could construct a contributer that would introspect
Java classes to extract JAXWS annotations and supply the contract
details from that, or how you could write a WSDL parser that would
populate the contract.

Another capability we will need in the model is a means to detect
changes and notify interested parties and a way to visit it. The
sketch below I hope indicates the capabilities we need - ignore
the contract source part, I can't remember why it is there :)

I think our first order of the day is to get this contract model
sorted out. I personally would be a fan of making an EMF model
of the details and growing that as we need to. There are other
options of course, like taking on something like JWSDL or
similar that can provide a purposed, specific model.

Your input is sought! If we can have a round of this on the mailing
list and can reach some consensus, I'll put the results up on the
web site.

cheers
 --oh



_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
[attachment "stp-service-creation-skeleton.pdf" deleted by David
Brandow/SYBASE] _______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev