JBossDeveloper

Next thing that I can think of is the Distributed nature of the Registry. Clustered Registry I should say. And it would be stand alone as well. So the first thing we need is a listener for requests. Would we grow this from scratch or we reuse currently available listeners from some application?

Clustering, implementation and transport technology should not be reflected in the interface that you are defining. The intention is to define an abstraction that can be mapped onto any registry implementation using any transport.

Clustering is an implementation detail and is not relevant to the interface, neither is SOAP.

The interface must define a clean, functional API that can be backed by any implementation providing similar functionality.

Thanks Kev. I think we're clear on the fact that we're trying to define an interface here and that issues such as clustering will very likely not effect that interface. All that said, I can't see any harm in talking around these topics a little here in the forum.

As far as this interface is concerned, we've been thinking that we really just need an Inquiry interface along the lines of that defined in the UDDI spec.

So the next questions I have in my head are:
1. Do we need the same level of capability, or can we do with something more basic in the short term? I'd hope we can!
2. How does this interface compare with the equivalent interfaces in the other reg specs?

Good, I'm glad that's clear :-)

It may be that I have misunderstood the discussion but my concerns were the following
- talk of defining the interface in SOAP and embedding in a servlet container
- talk of clustering facades for non clustered implementations

While both of these may be important from an implementation and deployment perspective, neither is relevant to the service interface being defined.

The priority for now is to work out the requirements for this interface and, while we should keep the implementation details in mind, these details should not distract us from the specification of the interface.

So Mugdho, you've been studying these standards, right? How do the Inquiry APIs compare - what have they in common/different etc? Hopefully these should give us an idea of what we need :-)

Hey Mughdo, sorry for being so slow in replying. I had some serious laptop issues - all sorted now though!!

I spent some time this morning looking at these reg specs - JAXR, UDDI etc. What's outlined in the JAXR spec def seems to be more inline with the direction that Mark wants us to take (as I understand it ;-) ). I'm talking mainly about the data model!! See the UMLs for an idea of the type of relationships.

In the JAXR model, it has the concept of:
- A RegistryObject which acts as a base type for everything that's stored in the registry.
- Numerous specialisations of ServiceObject that I think are relavant to anything we'd be doing wrt a regsitry interface. These include: Service, ServiceBinding, Classification (and related types!) and more...

In order to access these RegistryObjects JAXR defines the QueryManager interface. We'll need something along the lines of this interface too.

Sorry - a missleading typo there in the last post. I should have said "Numerous specialisations of RegistryObject that I think are relavant..."

So Tom, our current objective is to think along the lines of the QueryManager right?

Like you said on the lines of the data model, wouldn't the RegistryObject be a part of the Registry which the user would be plugging in?

So we would need to think as to how the implementation of the QueryManager communicates with the RegistryObject and its specializations right?
I think what we need to do now is define the basic types that we need for the reg interface + the Inquiry interface. I think this JAXR interface can help us here - especially re defining the types.

The JAXR QueryManager interface is very generic in that it allows you query any type of data under it's control - Organisations, Users, Classifications etc. Do we need/want this? For now, do we need anything more than query methods for accessing "Service" instances? Can/should we reuse the <a href="http://java.sun.com/javaee/5/docs/api/javax/xml/registry/infomodel/Classification.html">Classification</a> and <a href="http://java.sun.com/javaee/5/docs/api/javax/xml/registry/infomodel/Concept.html">Concept</a> concepts to support the querying e.g. query the reg for services based on their classification? Is this too complex? Can we get away with simply specifying getServices() query method that returns a full list of the services, leaving it up to the clients to sift through the "Service" objects as it sees fit.

So how about this for a 1st stab at the Registry interface (defined in Java):

public interface RegistryService {
 public Service[] getServices();
 public EPR getServiceEPR(Service service);
}

Should the Service object contain the EPR, or should that be requested seperately (as above)?

Ups, messed up there (again ;( )

The last bit should have been:

So we would need to think as to how the implementation of the QueryManager communicates with the RegistryObject and its specializations right?

public interface RegistryService {
 public Service[] getServices();
 public EPR getServiceEPR(Service service);
}