OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Discussion thread on ebXML Registry Profile for Web Services


FYI...

This thread has some interesting discussion relevant to TC.

At the top is just my points on why a repository is important to SOA 
Governance and why a registry alone is insufficient.

But the email below that is a very good overview of what the WS Profile 
spec is about. It contains links to screen shots that show
how the WSDL discovery query may be used by the user.

I thought to share this as TC members reviewing draft 3 may find it as 
helpful background. Thanks.

-- 
Regards,
Farrukh


--- Begin Message ---
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 <farrukh.najmi@sun.com> 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
Service-oriented architecture Computer monitoring software Computer and internet software
Free computer monitoring software

YAHOO! GROUPS LINKS





YAHOO! GROUPS LINKS





-- 
Regards,
Farrukh



SPONSORED LINKS
Service-oriented architecture Computer monitoring software Computer and internet software
Free computer monitoring software


YAHOO! GROUPS LINKS




begin:vcard
fn:Farrukh Najmi
n:Najmi;Farrukh
email;internet:farrukh.najmi@sun.com
tel;work:781-442-9017
url:http://ebxmlrr.sourceforge.net/tmp/farrukhRacePointIcon.jpg
version:2.1
end:vcard

--- End Message ---
begin:vcard
fn:Farrukh Najmi
n:Najmi;Farrukh
email;internet:farrukh.najmi@sun.com
tel;work:781-442-9017
url:http://ebxmlrr.sourceforge.net/tmp/farrukhRacePointIcon.jpg
version:2.1
end:vcard



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]