[UPlat] Notification

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

In response to [assign champions for each item. Start discussions on mailing list * Igor - Notification.]

Following the definition & need for management of Notification expressed in http://lists.oasis-open.org/archives/wsdm/200310/msg00059.html

"
When considering requirements on the platform with regards to means of notification, it is important to separate capability of simple message exchange for the purposes of notification from the complex event processing (CEP). The former may be achievable with a little effort and the later is a discipline of its own and usually requires a lot of supporting infrastructure that has nothing to do with means of notification, per se. To be concrete simple notification is required to efficiently provide manageability of resources. CEP can be built on top of simple notification and may be considered out of scope for now.

To make simple notification possible the folowing has to happen
	1. recipient has to know how to register interest with the source of information
	2. source has to know how to deliver information to recipient
	3. recipient needs to know that is it being notified ans also by which source

Assuming that both the source and recipient are implemented and run on Web services platforms with Web services tools. Assume that both source and recipient want to implement notification using Web services. Web services tools/platforms are designed to facilitate easy creation and deployment of a client and a service type of applications, in which case, traditionally, a client is an initiator and a service is the responder in the interactions. To make it possible, service provides a description how it expects the interaction to happen and client understands it. The interesting difference is that both recipient and the source have to be initiators and responders to be able to implement the three requirements outlined above. Therefore both recipient and source need to provide descriptions how the interactions need to happen. Each side can only provide descriptions of interactions it will respond to. The source can provide description of how a recipient needs to register its interest in available information, and the recipient can provide description how a sourc can deliver information to it. Definitely, both sides need to have an apriori agreement on (and knowledge of) both of the descriptions to allow the bidirectional interaction to happen.

The claim is that if the above three requirements are satisfied by a standard, that is both recipients' and sources' side descriptions are standardized, it is possible to use existing Web services tools and platforms to implement recipient and source as Web services. In that case each Web service is actually a client and a service to the other one, but both are aware of ecah other's abilities as a recipient or the source.

Such standard would have to define
	source's side description with
		- how to register an interest in an identifiable information (e.g. name, QName, URI, etc.)
		- how to convey address of a deliverable recipient (e.g. WS-Addressing, URL, etc.)
		- how to verify registration of the interest
		- how to cancel registration of the interest
		- how a source can notify of the unilateral cancellation of the interest
	recipient's side description with
		- how to deliver infromation and identify that it is a notification
		- how to tell what source it came from and possibly what is the context at the source
"

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: John DeCarlo [mailto:jdecarlo@mitre.org] 
Sent: Thursday, October 23, 2003 2:28 PM
To: WSDM TC
Subject: [wsdm] [UPlat] 2003-10-23 Conference Call Minutes

Hello,

Attached are the minutes in PDF format.  Corrections welcome.

Thanks.

-- 

John DeCarlo, The MITRE Corporation, My Views Are My Own
email:      jdecarlo@mitre.org
voice:      703-883-7116
fax:        703-883-3383
DISA cube:  703-882-0593