Thanks Farrukh. I will draft something over the weekend and send. I will
take all perspectives into account (all are valuable), which will include the
perspective of the needs of the US federal space as well as our TC members, to
make sure that all needs are accounted for. Once submitted, we can vet the exact
text within the TC collaboratively.
Joe
Joseph Chiusano
Booz Allen Hamilton
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
--------------------------------------------------------------------- To
unsubscribe, e-mail: regrep-unsubscribe@lists.oasis-open.org For additional
commands, e-mail: regrep-help@lists.oasis-open.org
|