OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [uddi-spec] UMM -> UDDI, any comments??



Thanks for your support.   Yes, the key thrust is to provide abstract B2B model concepts to used as classification for the concrete technology objects.  And, yes, utility does depend on uptake of UMM.  On the matter of UMM uptake, what I see happening is there are two types of interoperability projects out there:

  1. The first type is where an organisation or government department creates a service – often with their own internal semantics and then offers / requests / demands that their partners use the service.  That service is often just a replication of some back office API but wrapped in WS technology.  If published to UDDI it will typically not be linked to any standards.  This is quite common when there is one heavyweight player in an industry or one organisation / government agency that provides a unique service (eg tax office).  You can characterise this as a “one to many” scenario that is reasonably well suited to a bottom up approach to interoperability.  The big organisation publishing their service may benefit from a UMM modelling but they certainly won’t see it as essential and so are more likely to go straight to WSDL generation from legacy APIs..
  2. The second type is where a larger community of more equal partners recognises a need to automate some buisness processes.  They realise that if each one just publishes a service that is generated from their legancy APIs then there will be as many different service definitions as there are partners in the community and interoperability is down the tubes.  They setup some kind of community working group, often under the governance of a “standards organisation” like EAN/UCC.  In this scenario the working group will amost always (these days) start with a model driven approach.  Some examples are Eurofer (European Steel industry), SuperEC (Australian Superannuation / 401k) industry, GrainFlow (Australian Grain industry), and several more.  Also EAN/UCC has adopted UMM (a slightly simplified version of UN/CEFACT UMM) for their new approach to standards development so we can expect to see more & more of this.  Also all the UN/CEFACT business working groups that previously publsihed all the EDIFACT standards are moving to a model driven approach to migrating EDIFACT to the modern era (again using UMM).  I think that availability of tools the permit deployment schema generation from abstract models will accelerate the use of the modeling approach.  Such tools are in development by a variety of companies. 

I think a lot of organisations think that type 1 fits them but when they start to try to grow their automated community they realise that they really should have taken a type 2 approach.


So it may be a bit early to do this as an OASIS TN but I think it will be increasingly relevant.  It is certainly a need for us here is Australia.  If we don’t get a UN/CEFACT – OASIS TN on this then we’ll have to publish a Standards Australia TN – the problem with that is that all the tModels will need to be in the standards-com-au domain which is not really the owner of UMM and wont help international interoperability.


As for dropping the stuff about automated binding, I have no problem with that.




Steve Capell

Red Wahoo Pty Ltd

+61 410 437854


From: Andrew Hately [mailto:hately@us.ibm.com]
Sent: Friday, 10 September 2004 2:37 AM
To: Steve Capell
Cc: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] UMM -> UDDI, any comments??


Although I need more time to better understand UMM before I can provide relevant comments, this seems reasonable to me.  Am I interpreting this correctly that the key part of this paper to use UMM to codify a taxonomy to distinguish different abstract B2B model objects by further decorating the concrete technology models or creating a formal derivation for describing the relation of concrete models to abstract B2B model objects?

It seems the ultimate utility of this paper and registration of models in UDDI would be driven by the ability of indiustries to define these abstract technology independent models in terms of UMM.  Are there examples of industries using UMM (or UML exports to UMM) to produce these models?  

The only thing that I'd still prefer to avoid is much mention of the follow sentence: "From there, complaint software could setup automated bilateral agreements (ebXML CPA or WS-Policy) and thereby support automated binding."  I think a paper supported by the TC should focus primarily on the discovery of the artifacts that need to be fed into process software.  If we start discussing the level of B2B automation in UDDI TC documents again, we would need to spend significant time on the caveats and considerations.

I hope to have more detailed comments for you next week.


Andrew Hately
IBM Software Group, Emerging Technologies
email: hately@us.ibm.com
phone: (512) 838-2866

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

09/09/2004 01:19 AM


"'Steve Capell'" <steve.capell@redwahoo.com>, <uddi-spec@lists.oasis-open.org>




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]
Monday, 6 September 2004 3:39 PM
[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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]