Andrew,
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:
- 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..
- 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
As for dropping the stuff about automated
binding, I have no problem with that.
Regards
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.
Regards,
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 |
|
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]
Sent: Monday, 6 September 2004 3:39 PM
To: uddi-spec@lists.oasis-open.org
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