I am interested in seeing at least the information model
piece of it. The rest would probably be useful to people over time, but I
personally have no requirement for at present. I think
Steve's TN proposal is not without merit - I would be in favor of adopting a
quality solution in this area.
Daniel
From: Steve Capell
[mailto:]
Sent: Thursday, September 09, 2004
10:20 AM
To: 'Steve Capell';
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:]
Sent: Monday, 6 September 2004 3:39
PM
To:
Subject: [uddi-spec] Publishing UN/CEFACT
UMM models to a UDDI registry
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
smime.p7s
