[infod-wg] INFOD object model, questions

[Chris Kantarjiev]

Stephen and I are slowly working on action 64, 'Complete the object model for 
INFOD and place on gridforge'. We certainly won't be done by 22 December; we're 
generating more questions than answers.

I've been trying to think about this from an implementer's/deployer's point of 
view. It's probably useful for people to look at my version of the interfaces 
(in the CarUseCase Poseidon file) which are pretty much a straight translation 
of section 3.

The registry, that is, the InfodRegistryService, pretty clearly needs to 
implement all those interfaces, and it's going to have lots of objects floating 
around.

Does the registry need an object 'publisher' or just a list of publications with 
  contact information (EPR)? The InfodRegistryService needs to do mutual 
filtering of publishers and subscribers, so it needs more than just EPRs; it 
really needs all the information that has been supplied for doing this.

What's on the client side? Say, of a publisher (a Car Dealer). A publisher wants 
to create a publication that the registry knows about. The spec says that the 
publisher sends  CreatePublication to the registry, gets back an EPR. This 
doesn't make sense to me: I would think that the publisher should be creating 
the new EPR and telling the registry about it, since the publisher is going to 
be getting the messages about subscribers. I know I don't really understand how 
EPRs work, but I have to think that the end point that's being referenced really 
wants to be at the publisher, not the registry.

Do I have that wrong? If so, then my decomposition of a publication into two 
pieces isn't right at all; the publisher should be sending the EPR along and is 
really just registering a publication, not creating one. Perhaps the operation 
at the registry is more appropriately called RegisterPublisher ... I know that 
we've been around this naming issue at least once before, but I want to be clear 
on what's going on, no matter the name.

The publisher needs some object to hang on to, for managing the publication. It 
would be convenient if it was the same object at the publisher and the registry.

The registry needs to know the EPRs of the publications and subscriptions, so it 
can do matchmaking (tell a publication that there's a new subscriber and how to 
contact that subscriber).

  - It's not clear how, in the spec, this is done. Consume()? Is there an 
implicit INFOD_Consumer for every publication and subscription? I don't see a 
suitable message in the XML in the appendix for this kind of notification.

  - Stephen suggested that there might be subscribers and publishers that wish 
to hide their EPRs from one another - in this case, the Registry would act as a 
forwarder, presumably creating new EPRs and handing those around. Do we really 
want to support this, especially in the Base spec?

Comments and particularly answers are most welcome.

chris