[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [stp-dev] Skeleton outline for Service Creation subproject
|
Hi Dan
Getting back to a bit late, my apologies!
Ok, well the picture did what it was intended to do :) Let me say
that there's no intention on my part to try to do any duplication
of the SCA model. But, there's one thing that I'm missing and I
think I did mention this at the F2F back late last year.
The relevant bits in the Assembly model are the ComponentType
and Module.
The ComponentType descriptor has a link to the logical parts
of the contract (the interface) :
<componentType ...>
<service name="foo.bar">
<interface.wsdl interface="..." />
</service>
</componentType>
then the Module descriptor brings that together with a pointer
to the concrete parts of the contract (the binding)
<module ...>
<entryPoint name="foo.bar">
<interface.wsdl interface="...." />
<binding.ws port="..." />
</entrypoint>
</module>
The interface.type and binding.type can be anything at all, and
this is the basis for extensibility. But we need tooling to be
able to make instances of the interface type and the binding type.
The contract model that I am talking about is basically the
in-memory representation that are used by tools that allow you
to make these interface/binding pairs that can then be passed
on to the SOA system assembly stage and coupled into the SCA
model.
I hope that explains my thinking a bit more!
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.
Let's have that discussion! I'm leaning towards the canonical model,
yourself
and Dave have said that matcher approach is better. I'm used to
drawing together
commonalities of interface languages (IDL, copybooks, java,
proprietary XML,
WSDL) as a canonical form for integration projects, so that's my
comfort zone. Do you think yourself (and you Dave) could expand
on the matchers approach for us all?
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.
Great, I'm really looking forward at taking a look at this code!
regards
Oisin
