[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 ?
Red Wahoo Pty Ltd
+61 410 437854
From: Steve Capell
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.
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.
Red Wahoo Pty Ltd
+61 410 437854