RE: [uddi-spec] UDDI and Semantics: another perspective

[GARG Shishir / FTR&D / US <shishir.garg@rd.francetelecom.com>]

Title: UDDI and Semantics: another perspective

What I meant was that the client request is not necessarily handled at the current UDDI Query API level, but at a level above that. Then, that leads us to the second aspect of my e-mail that you disagreed with, which is regarding a statement in the standard about "pluggable manner" to support some mechanisms for doing semantic mark-up, and letting the API at the higher level be essentially some kind of negotiation protocol.

 

However, the taxonomy server related comment is not something we need to consider, it was just a comment on how we approached the problem. Now, Luc, you agree that the TC should select one or more approaches and spec it... all I was saying is that we should offer (perhaps by leveraging a negotiation protocol) a means to let the client and server agree upon their mutual capabilities and go from there.

 

Looking at John's message, I agree that that is really a key question. If we choose to let everything be pluggable, then the next question is, how much do we want to say if anything about any of the multiple pluggable mechanisms. If we choose to bake aspects into the UDDI core, we will have to detail that. If we want to support both pluggable (but limited to an agreed upon set) and baked-in (more than the taxonomy support that exists now) capabilities, then perhaps this kind of negotiation layer will be useful in letting client and server come to an agreement on. Note that I'm not talking about semantic negotiation, but more about some sort of a protocol agreement, or capability negotiation mechanism.

 

-Shishir.

 

 

 

-----Original Message-----
From: Luc Clément [mailto:luclclement@verizon.net]
Sent: Tuesday, December 09, 2003 9:06 PM
To: GARG Shishir / FTR&D / US; uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] UDDI and Semantics: another perspective

Shishir,

 

Could you please expand on what you mean by "Accept client request at taxonomy server level" as I don't understand this statement.

 

As I've stated today, I'm concerned about "modular and incremental approaches" proposed today and in your note for a number of reasons. While these are great design principles, I think the TC needs to settle on a limited set of approaches that are spec'ed end-to-end. First and foremost, leaving the door open to many possible (open-ended) solutions will create more problems that it attempts to solve IMO. Taking that approach will leave vendors and 3rd parties faced with likely too many options and solutions to implement and test. The same can be said for customers attempting to deploy these solutions, which unless we limit the scope of possibilities, will be non-workable in heterogeneous environments. Leaving it open for others to spec would also likely result in stagnation and a lack of adoption as we've seen as in the case of external value set providers and necessary commercial implementations.

 

I think that the TC should select an (or a set of) approach(es) and spec it; our approach should be as you suggested modular and incremental in its design. In short, we need to lead by putting a stake in the ground. Thus, I can't agree with the statement "to let the standard say that all of these are supported (in some pluggable manner), and provide a query mechanism to let client and server synchronize their capabilities."

 

We must bare in mind that at the end of the day, we need to spec solutions that are compelling for the community, and that we obtain broad vendor support in a timely manner given that at the end of the day in order for standardization to be possible, we require implementations and arguably demonstrated interop.

 

Luc

---

From: GARG Shishir / FTR&D / US [mailto:shishir.garg@rd.francetelecom.com]
Sent: Tuesday, December 09, 2003 15:47
To: 'uddi-spec@lists.oasis-open.org'
Subject: [uddi-spec] UDDI and Semantics: another perspective

Hi,

After listening on the TC call to a lot of discussion around the use of Semantics (and SW technologies) in conjunction with UDDI, I wanted to offer some perspectives as well.

I do agree with Tom that we have to put a clear stake in the ground with respect to what the TC wants to do in this space, and what we consider to be the roadmap for the convergence of these technologies.

I have often heard and do agree that the best convergence points for WS & SW technologies will be in the areas of discovery. UDDI does come to mind at that point, doesn't it ;). In addition, the existing taxonomies support only offers only essential discovery capabilities through the query APIs.

In terms of timing, I think that it couldn't be better. With the work that the CMU folks have already done, with some mentions from other members about work that they are also doing in this space, it looks like the right time to work on the topic.

We have also been doing some work on leveraging an externalized taxonomy server to build more complex queries against a standard UDDI Query API. Its true that while the architecture leaves the UDDI api untouched, the clients that don't use the taxonomy server will not get the best and most relevant responses. 

So this brings us to some issues to be mindful of IMO:
- Backward compatibility with existing UDDI APIs. This means we can add additional Query APIs or a new Negotiation API to let the client and the system come to a mutual understanding of what both sides are capable of communicating.

- Modular and incremental approach: Several models were discussed today, including adding semantic annotations to core UDDI elements, all the way down to a completely independent system that works in conjunction with the standard UDDI (as we know it today). Would it be possible to let the standard say that all of these are supported (in some pluggable manner), and provide a query mechanism to let client and server synchronize their capabilities. I've seen some discussion of WS-Agreement? at the WS-DM but it is very early stage. Perhaps we could consider using such an approach in our roadmap? Does anyone have more information about this?

- Federated registries: This would also be impacted, as it would imply that the negotiation should offer the use of other registries that are better equipped to converse with the client rather than just the primary registry being approached. Also, if the ontology capabilities are external to the UDDI, then we need to consider whether or not they can simultaneously apply to multiple UDDI registries

Regarding the mechanism to build a response, the approach we seem to be considering is:
- Accept client request at taxonomy server level
- build out a series of UDDI queries based on metadata inspection
- Send concrete queries to UDDI registry(ies)
- Aggregate responses and return to client

But this may just have to do with our project requirements. However, we heard other approaches to this, for example to keep the UDDI API as the front end to all client interactions. I guess we need to discuss the pros and cons of the various approaches. Another topic to be considered is the response time. The system needs to expand the possible responses to account for the widest set, but within reasonable delay for a good user experience. As a suggestion, we could base that on whether the request is received synchronously or asynchronously.

Hope this is useful for discussion.

Shishir Garg
France Telecom R&D.