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??
- From: Andrew Hately <hately@us.ibm.com>
- To: "Steve Capell" <steve.capell@redwahoo.com>
- Date: Thu, 9 Sep 2004 10:37:19 -0600
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
|
To
| "'Steve Capell'"
<steve.capell@redwahoo.com>, <uddi-spec@lists.oasis-open.org>
|
cc
|
|
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 ?
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]