[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
Description: Binary data