AW: consolidated use cases and discussions for Issue 6917

Hi.

I would welcome a solution that uses WS-Topics, so harmonization would be
achieved between WS-E and WS-N at least for handling of topics. 


Concerning 4.2/4.3: I think that WS-Topics can help here. In the email
exchange you mentioned, I provided an example of a TopicSet that actually
describes the topics currently implemented by the service. To know which
messages are posted on each topic, WS-Topics uses the TopicNamespace, like
this here:

<?xml version="1.0" encoding="UTF-8"?>
<wstop:TopicNamespace targetNamespace="http://www.opengis.net/swes/1.0"
xsi:schemaLocation="http://docs.oasis-open.org/wsn/t-1
http://docs.oasis-open.org/wsn/t-1.xsd"
xmlns:wstop="http://docs.oasis-open.org/wsn/t-1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:swes="http://www.opengis.net/swes/1.0" final="true">
  <wstop:Topic name="ServiceMetadataChanged">
    <wstop:Topic name="OfferingAdded" messageTypes="swes:OfferingReport"/>
    <wstop:Topic name="OfferingRemoved" messageTypes="swes:OfferingReport"/>
    <wstop:Topic name="OfferingChanged" messageTypes="swes:OfferingReport"/>
  </wstop:Topic>
  <wstop:Topic name="SensorMetadataChanged">
    <wstop:Topic name="SensorRecalibrated"
messageTypes="swes:RecalibrationReport"/>
    <wstop:Topic name="SensorMoved" messageTypes="swes:MovementReport"/>
  </wstop:Topic>
</wstop:TopicNamespace>

Each topic in a TopicNamespace can state which event type or types a client
should expect to receive when subscribing for that topic. "If the list is
empty, or the attribute is not defined, then a Notification can have any XML
element as root." [1] So when looking at a TopicSet of a service and parsing
the TopicNamespace of a given topic of that set (the TopicNamespaces used
could be modelled as resources of the service, at the OGC we are currently
investigating this option), you know which message types you will get.
You can also add additional documentation to each topic (both in the
TopicNamespace and TopicSet, which could explain the information one would
receive when subscribing to that topic in more detail). This seems to
address 4.2 c). By adding a specific element (could be defined by WS-E) to
each topic in the TopicSet of a service, where a link to an event type
definition of the service (or notification?) WSDL is included, you could
address 4.2 a).

As to 4.2 b): This is a subscribe request according to WS-N

<?xml version="1.0" encoding="UTF-8"?>
<wsn-b:Subscribe xsi:schemaLocation="http://docs.oasis-open.org/wsn/b-2
http://docs.oasis-open.org/wsn/b-2.xsd"
xmlns:wsn-b="http://docs.oasis-open.org/wsn/b-2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
  <wsn-b:ConsumerReference>
    <wsa:Address>http://www.igsi.eu/consumer</wsa:Address>
  </wsn-b:ConsumerReference>
  <wsn-b:Filter>
    <wsn-b:TopicExpression
Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116">//*[namespace-uri()='
http://www.opengis.net/sps/2.0' and
local-name()='TaskStatusUpdate']//*[@*[namespace-uri()='http://docs.oasis-op
en.org/wsn/t-1' and local-name()='topic']='true']</wsn-b:TopicExpression>
  </wsn-b:Filter>
</wsn-b:Subscribe>

Unfortunately the TopicExpression element is defined by WS-BaseNotification,
not WS-Topics - but WS-E could define a similar element. I am sure that an
agreement could be made.

Not sure about what information needs to be made available for addressing
4.2 d), but lifecycle of topics is an interesting aspect which I guess is
not yet handled by WS-N.


As I said in a previous email, WS-Topics is not an easy read, and some
concepts are also not easy to grasp directly. But there is a minimum set of
functionality which could serve as a basic profile, if the full
functionality of WS-Topics is not wanted in WS-E.

Regards,
Johannes Echterhoff


[1]
http://docs.oasis-open.org/wsn/wsn-ws_topics-1.3-spec-os.htm#_Toc122514744



> -----Ursprüngliche Nachricht-----
> Von: public-ws-resource-access-request@w3.org [mailto:public-ws-
> resource-access-request@w3.org] Im Auftrag von Li, Li (Li)
> Gesendet: Dienstag, 26. Mai 2009 19:34
> An: public-ws-resource-access@w3.org
> Cc: Chou, Wu (Wu)
> Betreff: consolidated use cases and discussions for Issue 6917
> 
> I thought it might be a good idea to collect previous use cases and
> discussions related to this issue to solicit group feedback on which
> direction to pursue.
> 
> 1. Performance Problem
> This is raised by Mr. Ben Kloosterman in Issue 6917
> (http://www.w3.org/Bugs/Public/show_bug.cgi?id=6917) regarding the
> efficiency of content-based X-Path filter in WS-Eventing spec. To avoid
> the expensive X-Path evaluations, he says several WS-Eventing
> implementations invented their own topic mechanism.
> 
> The concept of topic is also informally used in current WS-Eventing
> spec
> samples (Example 4.1
> http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#Table4 and
> Example
> 5.1 http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#Table13).
> 
> Mr. Kloosterman therefore suggests WS-RA to standardize a topic filter
> to optimize event filtering and routing.
> 
> 2. WS-Topic Discussion
> There were some discussions on the relationship between WS-E and
> WS-Topic from OASIS by Gil and Johannes Echterhoff
> (http://lists.w3.org/Archives/Public/public-ws-resource-
> access/2009Apr/a
> tt-0151/00-part).
> 
> Basically, Mr. Echterhoff said WS-E does not support topic based
> subscriptions and mentioned OASIS WS-Topic as a potential solution.
> 
> 3. Dynamic Resource Problem
> Issue 6425 http://www.w3.org/Bugs/Public/show_bug.cgi?id=6425)
> described
> some CSTA uses cases related to the concept of topics. In CSTA ECMA-348
> web services, for a computing function (event sink) to receive events,
> it has to create a monitor on the switching function (event source)
> using a service request. The set of event types the switching function
> can generate are defined in the WSDL, but the set of events a monitor
> can generate depends on the monitor filter, which is specified in the
> monitor creation message. When a monitor is removed (by either event
> source or sink), the event sink ceases to receive events from that
> monitor.
> 
> To address this issue, we proposed to address event source by
> WS-Addressing EPR and model such monitors as part of the EPR. The issue
> was FIXED and CLOSED without specifying how the EPR is extended to
> include such monitors.
> 
> After revisiting the topic issues, it seems possible to also model such
> monitor as a special topic.
> 
> 4. Possible Solutions
> Given these uses cases and discussions, there seems to be the following
> solutions suggested by various people so far:
> 
> 4.1 Do nothing
> We could claim these use cases are outside the scope of WS-E and leave
> them to the implementations to extend WS-E or compose it with other
> specs, e.g. WS-Topic.
> 
> 4.2 Propose a simple topic mechanism
> Here we need to consider these issues:
> a) how topics are advertised and linked with event types in WSDL
> b) how topics are represented in subscribe messages (in EPR or filter)
> c) how topics are associated with notifications
> d) how topic lifecycle is managed
> 
> 4.3 Adopt WS-Topic with profiling
> Describe a subset of WS-Topic and how to compose it with WS-E.
> 
> 
> Li Li

Received on Wednesday, 27 May 2009 09:00:36 UTC