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