Anne Thomas Manes wrote:
Thanks Farrukh. I'll take a look at the profile in the next day or so.
It would be very valuable to get your feedback on this draft spec. In
particular I am interested in holes in the spec, use cases that it does
not currently handle as well as how it compares functionality and use
case wise with the UDDI TN on publishing WSDL. Thanks in advance for
your help.
Can you tell me -- does it work if you aren't storing the
WSDL in the
repository? In other words, can you simply register the WSDL?
90% of the functionality works the same when you aren't storing the
WSDL in the
repository. This includes the content validation, content cataloging
and its automated mapping from WSDL to ebXML Registry metadata, the
WSDL artifact discovery queries.
What does *not* work the same is access control policy enforcement,
lifecycle management, automatic versioning features with respect to the
*WSDL content*. This is because one cannot enforce such governance
policies on WSDL documents unless the registry-repository can intercept
all access to the WSDL content.
This difference is the crux of the argument a few of us have been
making that a repository integrated with the registry is key to
governance of SOA and other artifacts.
That said, the ebXML Registry standard recognized that the whole
world's information cannot be in its repository. While there are trade
off in whether to store WSDL in the repository or store it externally,
ultimately the choice is left to the deployment and its policies.
Thanks,
Anne
On 10/4/05, Farrukh Najmi <[EMAIL PROTECTED]>
wrote:
Paul Denning wrote:
UDDI defines a BP for WSDL that has been around since
UDDI v2, and an
updated TN for UDDI v3.
I hear that ebReg has a catalog profile(?) defined for WSDL, such
that, a WSDL published to the ebReg repository can automatically add
ebReg registry entries (metadata). For example, you could look at
the WSDL and pull out the namespace URIs and add them to registry
entries. This allows you to search the registry for WSDL that use a
particular namespace URI.
I have not found where the WSDL cataloging is specified. Is it
within an OASIS spec, profile, or is it product-specific?
Hi Paul,
Please see link below:
ebXML Registry Profile for Web Service (draft 3):
http://www.oasis-open.org/committees/document.php?document_id=14756
This document provides a normative profile specification for
publishing, management, governance, discovery and reuse of Web Services
descriptions within an ebXML Registry.
The WSDL Cataloging Service is normatively specified in chapter 7
"Cataloging Service Profile".
Also please see following image:
http://ebxmlrr.sourceforge.net/tmp/wsdlDiscoveryAndDrillDown.jpg
This figure illustrates how published WSDL artifacts may be discovered
and then browsed and drilled down upon.
Note that none of the UI in the figure is WSDL specific. It is all
generic ebXML Registry client functionality that leverages the generic
features of ebXML
Registry.
The UI uses JAXR API to access the ebXML Registry which hides
all XML, SOAP, XML Digital Signatures details from the client.
Here is another example of a Web Browser based UI that uses the exact
same stored parameterized query configured in the ebXML Registry to
dynamically display a similar web form for WSDL Service Discovery:
http://ebxmlrr.sourceforge.net/tmp/WSDLServiceDiscoveryQueryWebUI.jpg
This Web UI also uses JAXR API to access the ebXML Registry.
Note that discovery queries may use any of the cataloged metadata for
the object
type being discovered *as
well as* any of the metadata
attributes of
objects that it uses in its implementation.
For example, a WSDL Service may be discovered using Service attributes
as
well as any combination of Port, Binding or PortType attributes. The
spec relies on the ability of ebXML Registry
to support arbitrarily complex ad hoc queries and its ability to hide
the said complexity using stored parameterized queries.
Again, I want to emphasize that the Query Form shown in either images
is not generated by WSDL
specific code but by generic ebXML Registry client code that uses the
stored parameterized query info in the registry to paint the form
dynamically. Configure a new query (say Discover Patient Record) and
the
form will dynamically change to be specific to specified content. Also
note that
there are no special UIs required for publishing WSDL. The generic UI
is not
much different from a FTP like UI which can publish any type of content
other
than WSDL. All the magic
occurs using functionality defined by ebXML Registry 3.0 specs and its
profile for Web Services. It does not matter how the WSDL gets
published
into the registry as long as it is published using ebXML Registry 3.0
protocols. The WSDL Cataloging service does all the magic.
Another important point to note is that the cataloger is normatively
required by the profile spec to process imports within the WSDL
document. So all you do is publish the top level WSDL and the imports
gets magically resolved, validated using business rules and cataloged
to
enforce the mapping rules.
There is much much more than meets the eye in this draft spec so a
detailed reading is suggested.
Also note that the ebXML Registry is working on a whole slew of similar
normative profile specs for other domain specific uses of ebXML
Registry
which should start appearing soon.
Again I would be very grateful if folks on the list can share their
ideas and
suggestions on this spec since it, like its mother spec, is a
community driven
spec. Your comments can continue to influence and evolve it until the
time the ebXML Registry
Technical Committee finales and approves it. My best guess is that it
will go final in the next 2 months.
Lastly, for those that have experience with the UDDI Technical Note for
Publishing WSDL, I would be very
interested in your impressions on how that compares with the ebXML
Registry Profile for Web Service.
Thank you.
--
Regards,
Farrukh
ebXML Registry Metalink page:
http://ebxmlrr.sourceforge.net/tmp/ebXMLRegistryLinks.html
SPONSORED LINKS
YAHOO! GROUPS LINKS
YAHOO! GROUPS LINKS
--
Regards,
Farrukh
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
