Chiusano Joseph wrote:
I would like to recommend that we also include
information regarding how the 2 registry standards can be used together
in a complementary manner, as described in 2 articles that I had
published in April 2003 and September 2003 respectively:
Speaking for the US federal government space,
this type of information would be extremely valuable as there is much
confusion within that space regarding UDDI vs. ebXML Registry that can
be clarified further by including this type of information (i.e. in
addition to the information below). Also, there is a high probability
that in the future the US federal government space could see UDDI and
ebXML registries interacting with one another.
If anyone believes this is not a good idea,
please express concrete reasons as to why it would not be.
Thanks for the valuable suggestion Joe.
Would you like to propose some concrete text that we can consider?
I would suggest keeping it very brief (ideally a couple of sentences)
since we dont want this to become a paper about UDDI and ebXML
Registry.
As a suggestion I propose the use case where a UDDI registry references
an artifact in ebXML Registry within its overviewDoc/overViewURL
using the ebXML Registry HTTP binding.
Rspectfully, the following use cases are ones I feel we MUST NOT
mention and I include my
reasons why below:
"Using UDDI to find ebXML Registry/Repository"
This use case implies that one needs UDDI to find an ebXML Registry and
that somehow ebXML Registry is dependent on UDDI for this. Why cant
an ebXML registry be discovered in another ebXML Registry. More likely
why cant it just get discovered by a google serach. This use case is
not realistic.
I am not aware of any instances of this use case and do not feel it
solves a real
problem.
"UDDI as the registry for ebXML Components"
This use case has nothing to do with ebXML Registry - UDDI interop.
So I feel that it has no relevance in this context.
Thanks again for your valuable comments.
Thanks,
Joe
Joseph Chiusano
Booz Allen Hamilton
Dear colleagues,
Here is the revised text based on Monica's excellent suggestions
for your convenience. I have incorporated almost all her suggestions
with the exception of thos noted in my previous response to her
message. Please comment on this revised version that follows...
As Kathryn mentioned, in order to submit our specs for OASIS
standardization process next week we need
a statement of relationship of our specs with other standards. Per my
ACTION from previous meetings I am
providing the draft text below.
Please share comments on this thread. Thanks.
<draft text>
[3.] A statement regarding the relationship of this
specification to similar work of
other OASIS TCs or other standards developing organizations.
The OASIS ebXML Registry 3.0 specifications are aligned with a variety
of other OASIS standards as described below.
- The OASIS Web Services Security: SOAP Message Security 1.0
specification is used to provide Message Security for the Registry
protocol.
- The OASIS Web Services Security: SOAP Message with
Attachments (SwA) Profile 1.0 specification is used to provide Message
Security for SOAP attachments within the Registry protocol.
- The OASIS XACML 1.0 specification is used to define the
syntax for registry Access Control Policies.
- The OASIS SAML 2.0 specifications are used to support
Federated Identity Management and Single Sign On within the registry
The OASIS ebXML Registry 3.0 specifications have some similarities with
the OASIS UDDI 3.0 standard in that both specifications define a
registry standard.
Both specifications define a registry that is a web service. Both
specifications define a registry that may be used as a registry for web
services.
The two specifications have been independently developed and neither
specifications uses the other as a dependency.
Limited similarities exist between the OASIS ebXML Registry 3.0 and
OASIS UDDI 3.0.
Both specifications define a registry for web services and a registry
exposed as a web service.
No explicit dependencies exist between the two OASIS specification
efforts. UDDI 3.0 specifies a registry only,
while ebXML Registry 3.0 specifies both a registry and a repository.
Other unique and value-added features of OASIS ebXML Registry 3.0
include:
- Custom domain specific artifact discovery queries using
SQL-92 and XML Filter Query syntax
- Parameterized registry-resident (stored) queries
- Life cycle management and artifact governance including
automatic version control
- Content based event notification using domain specific
queries
- User-defined, domain specific, taxonomies
- Domain specific custom relationships between artifacts
- Ability to group related artifacts in packages
- Automatic content specific content validation and cataloging
- Federated queries across multiple registries
- Linking artifacts across registries
- Federated identity and single sign on support based on SAML
v2.0
- HTTP Binding to registry protocol
- Extensible API and protocol
</draft text>
BTW, I would like to also include features in UDDI 3.0 that are not
provided by ebXML Registry 3.0. My reading of the UDDI 3.0 specs
returned no such candidate items. Paul since you are a member of UDDI
TC could you take an ACTION to provide us with a list of UDDI 3.0
features
that ebXML Registry 3.0 does not support? It would be good to state the
features in terms of end user relevant functionality rather than
something like
"UDDI has tModels and ebXML Registry does not". Thanks in advance for
your help.
--
Regards,
Farrukh
---------------------------------------------------------------------
To unsubscribe, e-mail: regrep-unsubscribe@lists.oasis-open.org For
additional commands, e-mail: regrep-help@lists.oasis-open.org
--
Regards,
Farrukh
|