RE: [uddi-spec] Publishing UN/CEFACT UMM models to a UDDI registry

["Steve Capell" <steve.capell@redwahoo.com>]

Monica,

Thanks for your comments.  My example may have separated ebXML from WS a
little too much.  I do understand that the lines are getting blurred and
that there is likely to be much greater interoperability as things like CPA
- WSDL mapping efforts progress.  That is all very good for everyone.
However I'd suggest that all this does not change the principle thrust of
the proposal which is to have regaitry meta-data derived from abstract
models to represent the semantics of a process and then permit as many
technical deployments as you want - all pointing to the same abstract model.
Initially I'm just looking for support for the princple that a technical
note on UMM - UDDI mappings is a good thing to do.  No reason why the same
approach and semantics can't be applied to an ebXML registry as well of
course.

By the way, you say that a "business transaction" is mapped to a WSDL
"abstract name".  Can you be more precise as what you mean by "abstract
name" and "business transaction"?  To my mind a BPSS business transaction is
an abstract concept that specifies a request and response activity.  It is
then bound to a binary collaboration where the roles are linked to specific
transaction activities.  I can't see how a whole business transaction maps
to anything in a WSDL which is, by nature, a single party interface
description.  However I can see how a BPSS collaboration role maps to a WSDL
port type.  And below that how a BTA within the collaboration maps to a WSDL
Operation.  

I'm VERY interested to hear about other view on BPSS - WSDL mapping because
we are building infrastructure based on my assumption that Collaboration
Role = portType and BTA = operation!  

Regards,

Steve Capell
Red Wahoo Pty Ltd
+61 410 437854


-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] 
Sent: Tuesday, 7 September 2004 8:51 AM
To: Steve Capell
Subject: Re: [uddi-spec] Publishing UN/CEFACT UMM models to a UDDI registry

See inline (mm1).

Steve Capell wrote:

> 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.
>
mm1: Have you tried this using the BPSS draft schema posted last week 
(this was a minor update from 2 August 2004 version)? We also can now 
allow WSDL abstract name association with a business transaction (more 
work required for the OperationMappping but the idea is clearly there).

> 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.
>
mm1: There may be comments coming out of WS-BPEL regarding the technical 
notes you reference which should be considered before the above.

> 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.
>
mm1: The lines are no longer as clear as stated in your diagram. With 
errate v2.1 changes to CPPA, web services can be used (see Dale Moberg 
for more details). In addition, the upcoming W3C workshop may / could 
change the landscape for policy in general. Thanks.