Thanks for the draft Farrukh. I don't believe it is necessary to
stress all the features and differences between UDDI and the ebXML Registry
(this is not a marketing package :-). The point of item three is to define
relationships with other standards. Please keep it simple. I recommend a simple statement
that there is no dependency or relationship between the UDDI specs and ebXML
specs. Remember this is the information package that is sent out when the
specs go out for vote as standards. This is not the time to go into
details about the functionality of either one. Note in the example I sent
you that UDDI does not mention ebXML:
Kathryn Breininger Boeing Library Services 425-965-0182 phone
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
|
--- Begin Message ---
- From: "Breininger, Kathryn R" <kathryn.r.breininger@boeing.com>
- To: "Farrukh Najmi \(Farrukh Najmi\)" <Farrukh.Najmi@Sun.COM>
- Date: Fri, 4 Mar 2005 15:14:58 -0800
Title: Example of statements regarding the relationship of a spec to similar work
Farrukh,
Here is the submission package from WSDM TC for their spec. Scroll down to item three to see their statement regarding relationship with other work: http://lists.oasis-open.org/archives/tc-announce/200502/msg00002.html (sorry, when I tried to copy and paste it all ran into one large paragraph that was very difficult to read!).
The SAML submission claimed no relationships:
3. A statement regarding the relationship of this specification to similar work of other OASIS TCs or other standards developing organizations:
To our knowledge, this specification has no relationship to the work of other OASIS TCs or other standards developing organizations.
Here is the statement from UDDI's submission:
[3.] A statement regarding the relationship of this specification to similar work of other OASIS TCs or other standards developing organizations.
The UDDI v3 specification builds on top of the OASIS UDDI v2 Standard. This version of the specification has been designed to be used in combination with other complementary Web services specifications. UDDI Version 3.0 builds on the vision of UDDI: a "meta service" for locating web services by enabling robust queries against rich metadata. Expanding on the foundation of the OASIS UDDI v2 Standard, UDDI v3 offers the industry a specification for building flexible, interoperable XML Web services registries useful in private as well as public deployments.
Hope these examples are helpful!
We can talk about this next week if you want.
Thanks,
Kathryn
Kathryn Breininger
CENTRAL Project Manager
Emerging Technologies
Boeing Library Services
425-965-0182 phone
425-237-3491 fax
kathryn.r.breininger@boeing.com
How was your service? Please click link below.......
http://socal.web.boeing.com/ssglibsurvey/
--- End Message ---