This is both a Test Submission to check out the GridForge, and a source of comments on the primer material.


Dave Snelling wrote.
Folks,

On 30/5/03 12:51, "Djaoui, A (Abdeslem)" <A.Djaoui@RL.AC.UK> wrote:

> Hello,
> 
> I have done some more editing in the notification concept section 4.8 and in
> doing so came across some questions. The answer to the some of the questions
> might be "implementation-depended", but it would be good if we can make sure
> where this is true and where it isn't.
> 
> �       In OGSI the semantics of a subscription and what notification messages
> result from a subscription are declared using the subscribeExtensibility SDE
> of the NotificationSourcePortType. OGSI  defines a subscribeExtensibilty SDE
> of value "subscribeByServiceDataNames" where a minInterval and MaxInterval
> attributes are defined (page 52 of the spec: by the way there is a typo in the
> spec, read subscribeByserviceDatanames not queryByServiceDataNames). Then on
> page 53 it states what should be returned as part of the notification message
> (note: there is no hint of what should be returned in the
> subscribeByServiceDataNames definition).

It should state that the requested SDE values be returned. It parallels
findByServiceDataNames.

> Is this the only way to describe what
> should be sent as a notification message? Suppose I want to send just the
> changed SDE value not the full set, should I define a new
> subscribeExtensibility?

Yes, you should define a new one.
 
>  Since the only difference would be the returned message (which is not part of
> definition) how can an application differentiate between  the new
> subscribeExtensibility and "ogsi:subscribeByServiceDataNames" SDE value?

From my reading, the spec is fairly clear on what should be returned. I
agree that it is not indicated in the XML, but it is part of the spec. Your
new subscription would look exactly the same, except for the name which
would carry with it the alternative semantics.

> How can an application find out what is returned from the new subscription?

For the published subscribeByServiceDataNames, it is the SDE values. Other
subscriptions would define other types. The actual types contained in the
SDE values are those of the corresponding ServiceDataNames used in the
subscription. These are frequently extensibility elements, so some form of
introspection on the actual type is probably required.

[Since I have been implementing this stuff recently, I have noticed that it
is really quite a nested complex structure.]

> �       What happens to a subscription if its NotificationSubscription
> instance dies (is destroyed, killed ...) while the source is happily streaming
> notifications to a sink? Will the source and sink be unware of that fact
> unless they query the NotificationSubscription status?

No the definition of deliverNotifiction is the only one way message in OGSI
(and the sink need not even be a GridService). We had discussions about a
deliverWithAck operation, but this has been postponed to V2.0.
 
> �       What happens if the sink goes away? Will the source keep sending
> messages until the timeout period for the subscription is reached.

It will keep trying until the subscription expires, but as the deliver is
single sided, it will never notice.

> �       And of course what happens to the sink and subscription if the source
> dies? 

The sink may notice that they have stopped, but that's about it. The
subscription probably dies with it in most implementations (as I see it
being implemented as just a data structure within the NotificationSource
(much like the ServiceGroupEntry).

One general comment; The OGSI spec clearly does not define a reliable
messaging service, only a notification service. A reliable binding could be
used to turn this into a reliable messaging service, but there are still
many vagaries in the semantics of ServiceData that probably mean something
else is needed to make it really what we think of as a reliable messaging
service.


-- 

Take care:

    Dr. David Snelling <d.snelling@fle.fujitsu.com>
    Fujitsu Laboratories of Europe
    Hayes Park Central
    Hayes End Road
    Hayes, Middlesex  UB4 8FE

    +44-208-606-4649 (Office)
    +44-208-606-4539 (Fax)
    +44-7768-807526  (Mobile)



 .