coarsegrained

WS-Eventing feedback workshop

Excited that its going on tomorrow at Tibco Palo Alto and that I have an excuse to be home in the Bay area yet a few more days. WS-Eventing is a great spec. I've provided some feedback on this blog on it already. I have more substantive suggestions for tomorrow.

Below is a sample C# command line utility I wrote tonight that allows you to subscribe a URL-specified endpoint to XPath-specified document content. It does this by sending WS-Eventing Subscribe messages to a WS-Eventing supporting Content Based Routing service. Full source (with comments even!), WS-E WSDL file, VS project files and executable is also available here. Works against our WS-Eventing implementation nicely it seems.

* Shouldn't be necessary to have such caveats on a personal blog, but it has not been tested very much at all, and for all I know has all kinds of bugs (certainly should be doing more sanity checking of the SubscribeResponse than I do below). The only real use of it will be that some variation of it will probably end up as a sample in an article or tutorial somewhere. In other words, its true CTO-quality code...

Haven't tried it against Casey Chesnut's WS-Eventing implementation (which requires Microsoft SQL Server) since I don't have SQL Server on any systems here (shocking since I was on that team at Microsoft). Any other implementations to interop test this against? I'm sure I'll find out a few tomorrow...

Couldn't resist showing how simple the program gets to be due to the straightforwardness of WS-Eventing and how easy it is to subscribe to document traffic. Now, getting source code to appear nicely on a blog is another story, as the indentation is totally lost below :-(.

using System;
namespace CBRSubscribe
{
class MainClass
{
[STAThread]
///////////////////////////
static void Main(string[] args)
{
if (args.Length<3)
{
Console.WriteLine(
"Usage: CBRSubscribe <web service for notifications> <filter expression> <CBR URL>");
return;
}
bool result;
result=Subscribe(args[0],args[1],args[2]);
if (result)
Console.WriteLine(
"Endpoint {0} is successfully subscribed to documents matching {1} with CBR service {2}!",
args[0],args[1],args[2]);
else
Console.WriteLine("Subscription failed!");
return;
}


static bool Subscribe(string notifyAddress,string subscriptionFilter,string cbrServiceURL)
{
CBRSubscribe.CBRService.Subscribe subscription=new CBRSubscribe.CBRService.Subscribe();
subscription.NotifyTo=new CBRSubscribe.CBRService.EndpointReferenceType();
subscription.NotifyTo.Address=new CBRSubscribe.CBRService.AttributedURI();
subscription.NotifyTo.Address.Value=notifyAddress;
subscription.Filter=new CBRSubscribe.CBRService.MessagePredicateAssertion();
subscription.Filter.Value=subscriptionFilter;

CBRSubscribe.CBRService.Eventing objEventing=new CBRSubscribe.CBRService.Eventing (cbrServiceURL);
CBRSubscribe.CBRService.SubscribeResponse subscribeResponse=
new CBRSubscribe.CBRService.SubscribeResponse();
subscribeResponse=objEventing.SubscribeOp(subscription);

// sanity check the subscription results
bool result=true;
if (!subscribeResponse.Id.StartsWith("uuid:"))
result=false;
return result;
}
}
}


UDDI Face to Face Meeting

Last week's UDDI Face to Face meeting in San Francisco (hosted by Maud Cahuzac and Shishir Garg of France Telecom) was extremely productive. All of the details and minutes are public up on the OASIS UDDI site (there's nothing here that you won't see there in other words). But to summarize:
- Concrete progress was made on nailing down a method of range searching for category values. This is particularly crucial for some proposals we are working with others on for storing management information associated with web services in the registry.
- A simple method of performing boolean searching with category bags and combinations of them, without requiring a fullfledged new query language, looks like it will be introduced. The default of reducing everything to conjunctive normal form by default (implied OR for values within category bags, and implied AND between category bags) is great way to get arbitrarily complex queries without forcing learning and implementation of new "keywords"
- There was a proposed simplification of requirements of taxonomies to concentrate on identity between nodes (within and across trees) and parent/child relationships. It needs to be verified further but I think its a step in the right direction. After the goals are agreed upon, I would imagine it should be quick work to come up with a representation: whether its based on an existing format such as a subset of OWL or RDF, or a new format entirely.
- Methods of representing ACLs were worked on, which is an important thing to happen I think, though I wasn't attending that track of the session.
- It was agreed that it would be value for the UDDI TC to put out a Tech Note, in consultation with WSDM, for storing quality of service information in UDDI. Fred Carter of AmberPoint and I will be working on this, with hopefully lots of guidance and help from other management vendors on WSDM and sage advice from UDDI TC members.

Speaking of sage advice, Tom Bellwood of IBM did a great job driving topics to quick, practical and shorter term closure. All of this bodes quite well for UDDI in general. In my days as VPE at Commerce One I remember not being enthusiastic about UDDI V1. But UDDI V3 is a very solid specification as it stands. And the enhancements discussed seem like they should be able to be layered on top of V3 without major changes and thus are perhaps not too far in the future in being available to customers. Whether its Systinet or IBM or Microsoft's UDDI registry, companies should strongly consider using a current UDDI implementation as the central site for storing all of their web service information.

Extending UDDI

Just spent the last couple of days at the UDDI Face to Face meeting in San Francisco. Among other things presented a joint proposal with AmberPoint for storing quality of service information for web services in UDDI. Its a good first steps toward an Enhanced Web Service Registry. More details on that later as it gels. In the meantime coincidentally the following article was published in Web Services Review on Extending UDDI.

WS-Notification feedback

After writing about WS-Eventing and its value for content-based routing, I have received several questions about its relation to the subsequent WS-Notification publication. There are encouraging comments from both groups that there will be some effort to rationalize the two specifications, perhaps having WS-Notification somehow layered on top of WS-Eventing. In the meantime here is some high level feedback on WS-Notification itself (not really its relationship to WS-Eventing), especially with regard to its applicability to building simple XML document-focused content-based routing systems.

Topic Abstraction
Its not obvious to me that it is always valuable to have an intermediate abstraction of "topic" for many content-based routing publishing scenarios. In an XML document-centric world (perhaps not what WS-Notification is totally focused on?), subscribers presumably can describe their interests (subscription rules) easily enough with XPath expressions. Especially if there is a good XPath tool that lets people view the XML document schema and easily identify the fragments and values of interest.

One of the potential downsides of this approach is of course that many different subscribers will generate identical rules. But a good implementation of Content-Based Routing should "compile away" such duplication before runtime. The total duplicates are easy enough to handle. There is good work by Chan and Felber from Bell Labs on doing such duplicating rule matching in content-based routing even more optimally by recognizing when one subscription rule is "covered" by another one.

The topic abstraction also allow many different types of events which may have nothing to do with XML documents to be normalized to be represented as topics. This may make sense. However as the web services world progresses, one would guess that all of these events will be serialized in some XML form.

Finally the topic abstraction is an opportunity for to optimize publishing where one doesn't want to publish unless there are interested subscribers (the specification calls this "demand-based publishing"). Topics make this easier to do since you can check if there are subscribers before publishing. This specification implements demand-based publishing by having the notification broker "pause" or "resume" subscriptions with the publisher on given topics based upon whether there are subscriptions on those topics. This would be difficult to do with just XPath rules for subscribing to content since a given set of content (an XML document) may or may not meet subscription rules (expressed as XPaths). The only way to determine if a given set of content needs to be published or not is to have the subscription manager evaluate all of the rules.

However, there is an entire world of messaging-oriented middleware that provides such hierarchies of topics for performing publish/subscribe messaging. The specification clearly provides a way for those MOMs to be addressed in standard and web services-oriented ways. This will probably be very valuable for existing MOM infrastructure users. Its not clear whether you would want to have to support full WS-Notification if you were trying to build an XML document-centric publish/subscribe mechanism from scratch.

Notification Brokers
While I think there is value to content-based router services, which do act as notification brokers (they accept subscription requests from notification consumers and publish requests from notification publishers), its not clear whether there needs to be a separately recognized notification broker abstraction. The good news is that the only additional message exchange introduced is one for RegisterPublisher (a NotificationBroker must also support the Notify message that notification consumers support). This RegisterPublisher is an opportunity for the publisher to find out if they are allowed to publish on given topics. This makes sense as optimization of topic-based publishing. For publishing arbitrary XML content where only at runtime can you determine who is subscribed to a given instance of an XML document, its not clear that this one extra interface (RegisterPublisher) has value. And given that, its not clear that it makes sense for there to be an explicit notification broker abstraction in an XML and XPath focused content-based routing system.

Subscription Manager
WS-Notification proposes a subscription manager interface. Beyond the basic explicit destruction and expiration of subscription (which builds on WS-Resource), additional messages are supplied to pause and resume subscriptions, important for the "demand-based publishing" scenario (don't publish if noone is interested). As mentioned, its not clear that this is valuable in a XML document-focused content-based routing system that uses subscription rules. But the general idea of a subscription management interface is valuable. Indeed, messages to support subscription creation, deletion and listing of subscriptions are valuable things to have even in a much simpler XML document-focused content-based routing system. Its especially valuable to allow simple subscribing endpoints to enumerate their own subscriptions of interest, which can lessen the burden of them maintaining their own store of subscriptions.

For example, while WS-Eventing allows for expiration and deletion of subscriptions, it doesn't provide messages for enumeration of subscription. But subscribers must keep track of the IDs of their subscriptions in order to manage them (delete them, renew them and so on). A subscription management interface (e.g. messages to enumerate subscriptions of interest) can make it much easier for subscribers to have a user interface to manage the content they are subscribed to, without requiring that they implement a database of subscriptions.

More on how simple things messages might be added to supplement what is already available in WS-Eventing to make it easier to build content-based routing systems soon.