Sal and i we just had a short conversation about Topic Filtering, i just want to summerize the method i think we could use. Therefor i'm imagine a Brokered Network with Subscriber A, Broker B, and Publisher C. A subscribes at B and C is publishing his notifications to B. So B is the filtering instance.
--
First i want to summarize how i do Filtering based on XPath filters for WS-Eventing:
Filters for WS-E are (subset of) XPath expressions. So when B gets a notification from C, it starts filtering. All the subsriptions(filters) that are matching will get notified.
The Broker B has a statemachine(Yfilter). This statemachine contains all subscriptions(filters) as a set of states. for example:
/a/b are two states in the machine with one transition a->b. Now imagine there is a second Subscription(filter) which is /a/c,
so just a third state c is added and a transition from a->c. Both subscriptions are now sharing the state a, thats why its called shared path statemachine.
If a notification arrives, the statemachine is driven by parsing of the notification: for example
<a><c>hello</c></a>. First a is parsed ant the statemachine is in state a, now c is parsed and the machine makes a transition to c. After parsing, all endstates of the machine are matching filters/subscriptions and the notif is going to be forwarded to the subscriber.
This allows only one parsing for millions of filters to be applied. --
Now lets come to the WS-Topics filtering. Since WSN is using semantic filters, it is the other way round like in ws-eventing.
so we just use plains XPath evaluation:
Our Broker B has a TopicSpace XML document. like
<topicspace><topic name="sports"><topic name="tennis"/></topic></topicspace>
now a subscription is made via a TopicExpression: tns:sports/tennis
We could just add a subscriptionsTag to the topic tennis in our topicSpace:
<topicspace><topic name="sports"><topic name="tennis"><subscription epr="..." id=".."/></topic></topic></topicspace>
Now a notification arrives at the Broker. Every Notification has to specify ONE topic on which this notif is about with:
/wsnt:Notify/wsnt:NotificationMessage/wsnt:Topic
The notification is probably about tns:sports/tennis, so an XPath expr is created:
/topicspace/[EMAIL PROTECTED]'sports']/[EMAIL PROTECTED]'tennis']
This XPath expression is applied to the topicSpace XML DOM and
<subscription epr="..." id=".."/> is returned.
If multiple subscriptions are matching they are all returned by the XPath evaluation.
This technique just needs one XPath eval for millions of subscriptions.
What you think about that?
All sounds fine to me. One thing though... If you look at the topicexpression xpaths found in the few examples in the WS-Topics spec, you'll notice they look like:
/sportsnews:sports/tennis
as opposed to:
/[EMAIL PROTECTED]"http://sportsnews.com/"]/[EMAIL PROTECTED]'sports']/[EMAIL PROTECTED]'tennis']
I noticed this while studying the spec yesterday. If you closely read the grammars defined by the spec for concrete and full topicexpressions, they also indicate that the xpath elements correspond to the topic names and not the Topic elements from the TopicSpace document. So, I think, from an implementation perspective, that this means we'll either have to:
1) (XSLT?) transform the TopicSpace doc(s) to the form:
<sportsnews:sports xmlns:sportnews="http://sportsnews.com/";> <tennis /> <basketball /> </sportsnews:sports>
or
2) transform the topicepression xpaths to a form that can be applied to the TopicSpace doc(s), e.g. "/[EMAIL PROTECTED]"http://sportsnews.com/"]/[EMAIL PROTECTED]'sports']/[EMAIL PROTECTED]'tennis']"
3) Do not use the TopicSpace/Topic types at all and instead just store the TopicSpace doc(s) from the get-go in the form:
<sportsnews:sports xmlns:sportnews="http://sportsnews.com/";> <tennis /> <basketball /> </sportsnews:sports>
I think 1) is preferable over 2), because it could be done once up front (as well as if/when topics are added or removed at runtime), whereas 2) would have to be done for every call to subscribe() or notify(). I think I like 3) better than 2).. I just don't see the point of the TopicSpace/Topic types - XPaths can't be applied to them directly and neither the consumer not the publisher accesses them directly. I might very well be missing something; this is one of the things I want to discuss with William this afternoon.
Ian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
