Hi,
I just checked in a first cut of the SCDL files composing the WS-I
SupplyChain sample application, as well as the WSDL files describing the
ports for all the Web services under tuscany/cpp/sca/samples/SupplyChain.
I tried to follow the structure described in the WS-I supplychain
architecture document at
http://www.ws-i.org/SampleApplications/SupplyChainManagement/2003-12/SCMArchitecture1.01.pdf,
including:
- a demo sub-system, including a client reference and a logging service
- a retailer sub-system, composed of a retailer service component and
three Warehouses
- manufacturer sub-systems serving the Warehouses
- composites describing the implementation of the logging, retailer,
warehouse and manufacturer components.
Note that I'm still using the sub-system terminology here... My
intention is not go back to the 0.9 spec :) but I am influenced by the
WS-I spec which uses the term system to refer to these things, and I'm
looking for good terms to distinguish between
system-configuration-composites and
composites-describing-pieces-of-implementations.
After this first pass trying to define all the SCDL artifacts, I have a
few comments, and requests for comments:
- I had to repeat <service> definitions many times just to
publish/promote services out of composites. IMO this needs to be
simplified. I opened issue JIRA 660 for this and also raised it to the
OSOA specification workgroup.
- In my composite definitions I just needed to declare SOAP bindings for
my services and references, but since <binding.ws> requires a port I had
to create dummy ports with dummy SOAP addresses for all the services and
references, knowing that these would be different once deployed to my
system. I'll raise this issue to the spec group as well.
- I was not sure when to use wires and when to use URIs on bindings. I
tended to use binding URIs instead of wires in all the cases where I had
to specify the binding anyway, resulting in very few wires. It would be
great if some SCA spec experts on this list could look at what I've done
and help me get the wiring right...
- The callback pattern described in the WS-I document didn't seem to fit
with SCA conversational callbacks as I understood them. The supplychain
callback does not seem conversational to me, or if it is then the
correlation between the various exchanges is done through business data
and URLs "manually" added to SOAP headers, and I'm not sure how that
fits with SCA callbacks. So for now I have modeled this contract with
two independent reference + service in both directions. This seems
consistent with what the other existing implementations of the WS-I
supplychain sample have done as well.
- I was not sure how to publish a reference with multiplicity out of a
composite. See supplychain.retailer.composite to see what I did to
define the "warehouses" references (which needs to point to three
warehouses). The warehouses reference is first defined in the Retailer
component type, then promoted out of the supplychain.retailer.composite
and bound to SOAP by a composite reference. In doubt I specified
multiplicity 0..n on both the component reference and the composite
reference, but I'm not sure that this makes any sense at all :)
- Finally I organized the artifacts like we recently discussed on this
list, the composites configuring and assembling "sub-systems" under a
configuration/ folder, and the composites describing installed
implementations under packages/.
Thoughts?
Is anybody interested in helping with the design and implementation of
this scenario?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
