[infod-wg] Issue 2.2

[Djaoui, A (Abdeslem)]

>2.2	describe how registry handles EPRs, especially when logical EPRs for expressions
>
>	logicalEPRs don't current support expressions - define how to do so - indirection
>
>	- Owner: Abdeslem 
>	    - describe options - summarize pbm 
>	    - also, quick description of what an EPR is 	
>	    - target date: INFOD call - July 7

quick description of what an EPR is
==========================
EPR stands for EndPoint Reference. It's a way to refer to web service instance(s). It is defined in WS-Addressing and its content is as follows

<wsa:EndpointReference>
    <wsa:Address>xs:anyURI</wsa:Address>
    <wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters> ?
    <wsa:Metadata>xs:any*</wsa:Metadata>?
</wsa:EndpointReference>

(Note: The following is my current understanding of the spec! but I think it is in line with the latest draft)

The Address element is a URI that can be the physical address of a service or it could be just a name (URN) that can subsequently be resolved to an address (more on this later). This is the only part of an EPR that is required.
Reference parameters (optional): can be used to help dispatch the message to the correct instance (these show up as SOAP headers).
Metadata (optional): This allows the inclusion of any additional metadata about the endpoint. 

So how can we use EPR for dealing with 
1)a subscription on behalve of a single consumer, 
2) a list of consumers and 
3) and expression?

Note that the way we do it is specific to InfoD registry (and is not *standard*). But that's OK since this internal logic.

1) is the simplest as it involves simply passing a standard EPR to the registry. Nothing new here.
2)When dealing with a list of consumers I propose the use of a URN (urn:infod:subscription-list:dieter:ballroom-dance-news:1) 
for the address 
and include the list of EPRs in the metadata section. The URN is then used as an identifier of the subscription. When the EPR is passed to the registry,
the registry maintains the list of consumers assosiated with that particular subscription.
We will need to define at least one operation to the registry (resolveEPR), that takes an EPR and returns a new one (or a list of new ones). 
More work the sematics of this is needed.

3) we could define an infod specific URN (urn:infod:subscription-expression:dieter:ballroom-dance-news:1). Note the use
of subscription-expression instead of subscription-list. This will also be passed in the metadata section of the EPR, We would need to define a new infod specific element for this

<infod:Expression Dialect="xsd:anyURI">
{any}
</infod:Expression>

By dialect I mean SQL or XPATH or XQuery, ...
When this EPR is passed to the registry, the registry evalutes the expression and stores the list of consumers.

How is this for a start? Am I on the right track?


Abdeslem