[infod-wg] RE: 'advanced' operations of RegistrationManager interface

[Djaoui, A (Abdeslem)]

Hi Cecile
Sory about the late reply, but with the holiday period I am struggling to keep up with the Email backlog. Things will get back to normal in a couple of weeks times, so there is hope after all (=:
Please see inlined comments <AD/>
 
Abdeslem

-----Original Message-----
From: Cecile Madsen [mailto:madsen at us.ibm.com]
Sent: Thursday, August 25, 2005 5:12 PM
To: Djaoui, A (Abdeslem)
Cc: infod-wg at ggf.org
Subject: 'advanced' operations of RegistrationManager interface



Abdeslem and all,

The next draft of the specs will be split into 2 docs:
<AD> good </AD> 
- one for base patterns (RegistrationManager and Consume interfaces) 
 <AD>Looking through the current draft interfaces spec (which now deals extensively with vocabulary management), What do

you think about a separate document for a INFODBasicVocabularyManager and a separate document for the RegistrationManager. I am still not 

at ease with the consume interface. Thinking about composing our specs with existing pub/sub specs such as WS-BaseN or WS-Eventing, we can defer to those specs for that interface (Eventing does not definbe one and WSN allows raw-mwssages or Notify()). So we will only concentrate on the extensions to those specs thus allowing people to use INFOD with those specs.  So our base pattern will use INFODBAsicVocabularyManager INFODRegistrationManager and the publisher and subscriber entities. The other entities envolved whatever they happen to be (Events sources or Producers , conmsumers are as defined in WSN or WSEventing</AD> 
- one for advanced patterns: PO Box, Disseminator, XDisseminator 
<AD> Isn't POBox just a consumer, and as such it should really be in the base documents. In WSN Pullpoint is a BaseNotification. Yes the adanvced patterns in my view deal with disseminators and propagations (or are propagations gome?). But since the advanced patterns are based on the basic patterns they can of course use POBox </AD> 

 
For base patterns, entities like publishers, consumers, 
subscriptions are created in the (base) Registry using the
(base) RegistrationManager interface (operations CreateXXX).
<AD> Is the difference between baseRegistry and advanced just the ResolveEPR(). Again this distinction is not necessary since ResolveEPR() is used for subscription even in the base patterns. SO in my view we need only ONE RegistrationManager</AD> 
For advanced patterns, entities like a disseminator are 
created in the Registry using the RegistrationManager operation 
'CreateDisseminator'. Other operations are also available in
the RegistrationManager for advanced patterns.
<AD> As we discussed before the spec can define PublisherRegistartionManger interface, SubscriptionManager interface, ConsumerRegistrationManager interface etc ...Then the registrationManager is the web service that implements those interfaces. If somebody is only interrrested in the base patterns they don't have to implement CreateDisseminator().</AD> 

The base RegistrationManager interface should obviously
not include advanced operations. How can we model this ? :

Option 1. Have 2 (Base and Advanced) RegistrationManager interfaces. 

The issue with that option is whether queries can be done across 
entities owned by the 2 different interfaces... as we have a GetMData
that will require disseminators being searched based on publishers, 
consumers, etc. So the GetMData operation of the advanced
RegistrationManager would have to possibly query data maintained
by the base RegistrationManager (?!).

I'm not sure that is possible. Is it ?! This is assuming that our entities in 
the registry are ws-resources, so follow that pattern (interface with 
resource properties document).

Option 2. Extend base interface with advanced operations

Keep one interface and have it extended with the new operations.
This is dependent on wsdl 2.0 supporting inheritance - which is currently
a draft, targeted for Oct 05 ? -
<AD>The way to do this cut-and-paste as for WSDL1.1 or inheriatnce as in WSDL 2.0 is irrelevant I think. 

Anyway I better send this now to give you time to think about it befroe the call (Soryy about the typos

I won't have the tome to check them.</AD>

 

--> We're opting for option 2. Comments welcome.... 

Cecile


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/infod-wg/attachments/20050901/ad4d5c57/attachment.htm