[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] UMM -> UDDI, any comments??
Anybody feel like commenting?
Specifically whether the TC would consider publishing a TN on this (hopefully
co-authored with UN/CEFACT TMG). Yes / No / Ambivalent ? Steve Capell Red Wahoo Pty Ltd +61 410 437854 From: Steve Capell
[mailto:steve.capell@redwahoo.com] Hello all, During the last teleconference I promised to write an e-mail
outlining a proposal for publsihing B2B collaboration models to a UDDI
registry. The rationale for this is that most modern B2B collaboration
designs begin with information and process modelling exercise - in technology
neutral terms. The idea is that the same model can be used to generate
several technology specific deployments. Perhaps the most widely
recognised B2B collaboration modelling framework is the UN/CEFACT
UMM. Likely deployment technologies for UMM processes include
EDIFACT/EDIINT, RosettaNet, ebXML, and Web Services. Although UDDI is
obviously a part of the Web Services framework, I see no reason why it cannot
be used to model services deployed on other technologies. In fact, I
think large corporates will demand that their central services registry be able
to register all their interfaces and services and not just the WS-xx
ones. So if we accept the premise that a UDDI registry can usefully
carry service definitions for a variety of technology frameworks then an
obvious question is how to model them. A key benefit of publishing the
model itself is that it can be used to link several different technology
deployments to the same semantic and process model. A high level picture
of the proposed model is shown below: Explaining the diagram: At the top level there are some business domain level
classifications. A typical domain might be “Australian grain
industry”. The domain is split into business areas and process
areas (which would be implemented as checked value sets). A domain also
contains several partner types - for example in the Australian Grain industry a
typical partner type would be “Bulk Handler” or
“Marketer”. Each process Area would contain one or more
processes. Remember that these are collaborative B2B processes –
they are collaboration definitions rather than orchestrations and so they are
not “executable” in the same sense that a BPEL can be executed on a
BPMS. The next levels (grey boxes) contain lower level model
elements and the corresponding WS or ebXML schema (vertical boxes).
Multi-party collaboration models are just below the domain level
classifications. These can be described using an ebXML BPSS or something
like WS-Choreography. Note that BPEL is not appropriate at this level because
it describes only one side of a collaboration. The next level is the
single partner service definition level (ie the services exposed by one of the
roles in a multi-party collaboration). This level is described by a BPSS
/ CPP in ebXML and by WSDL(portType) / BPEL / WS-Policy in WS services.
Next there is the technology specific bindings that have no corresponding model
element (but share common classifications with higher level elements).
The bindings are described in WSDL Bindings or ebXML CPP service
bindings. Finally there is the information model semantics that is
represented by XML, EDIFACT, or some other syntax. The top level classifications have no physical object
related to them (ie the overview URL is empty). The physical objects at lower
levels include the model files (typically XMI files from some UML tool) and all
the technology specific XML deployment files. The idea is that there is a
model file at the same level as the deployment files and that there are a set
of NDR (naming & design rules) that describe how the deployment schema can
be generated from the model. Note that these NDR exist for ebXML objects
but not yet for WS Objects. So for example, an ebXML BPSS can be
generated from a process model. UDDI tModels can be generated from
BPSS schema similar to the way in which PortType & Binding tModels are
generated from WSDL schema using the rules in the WSDL-UDDI Technical Note. There is nothing incompatible about this model and the
existing WSDL-UDDI, BPEL-UDDI (draft) and ebXML-UDDI technical notes.
Indeed I would propose that this approach be compliant with all exisiting
technical notes. It could be regarded as a “superset” of the
existing technical notes that acts as the glue to bring them all together into
one model for the B2B context. What Queries would this support? Publshing UMM models and associated deployment schema to a
UDDI registry permits business users to make queries in business
language. “Show me what processes are defined that include the role
Marketer in the Australian Grain industry”. From there the
technologists (or better still, automated deployment software) can take over to
download technology specific schema and build compliant interfaces for
organisations that wish to paarticipate in process automation in a particular
industry domain. At a lower level, a well defined model would permit a query
like “show me all organisations with a complementary binding that matches
my binding”. This provides a mechanism, for example, for a seller
that supports the Australian EAN Retail Procumrement process to find all buyers
with matching business process and technology framework. From
there, complaint software could setup automated bilateral agreements (ebXML CPA
or WS-Policy) and thereby support automated binding. What next? I would like to propose that I co-author (with UN/CEFACT
TMG, the owners of UMM) a technical note called something like “Using
UDDI for model driven B2B collaborations.” Your comments welcome. Steve Capell Red Wahoo Pty Ltd +61 410 437854 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]