JBossDeveloper

Hi Mugdho,

EPR = EndPoint Reference

There are some notes on what an endpoint is classed as, on the esb wiki.

"mugdho" wrote:
About the piece of code which you provided below, I was wondering if we could have something like a name space lookup for getting the Services. Wouldn't that be better on the user side, since he will be aware of which service he is interested in.

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

One question at this point. When an user queries on a Registry isn't he essentially interested in one of the EPRs? While thinking of examples on when a user should query the Registry all that came to my mind are EPRs.

But ofcourse I guess there can be scenarios the user just needs information about the Service and is essentially not interested in the EPR right?

But if in most of the cases the user is looking for the EPR then Tom, I think Service Objects may need to have the EPRs in them.

Further to that perhaps we can think of querying on the RegistryObjects using the Classification / Concept. But yeah wouldn't the RegsitryObject need to have such a criteria already present if we were to query on it?

Now one question about the getServices method. Will any user get the list of all Services or will there be some type of roles present here?

Another thing, JAXR provides a lot of methods for the RegistryObject interface. I am wondering if we need to provide implementations for all of them?

Some food for though, which may be relevant or not.

1) The state of an endpoint service in the registry. This would be needed for clients and also reporting.

2) Each service should be categorised, either via a hardcoding of type under the registry, or a spi provided categorization. This may lead to signatures like searchByCategory etc.

3) Policies per service, and optionally on a per category basis.

4) I'm not sure at what point we need to think of templating services for each category, so that clients may at least know what template to possible work to, the underlying service impl can be changed transparently.

5) Aside from just services, will the registry hold dependant objects such as an XSD if there is say a validation service? Would this be classed as a ServiceResources and be grouped under the ServiceEntry such as ServiceEntry.getResources() ?

Thanks Arvinder.

"arvinder" wrote:
1) The state of an endpoint service in the registry. This would be needed for clients and also reporting.

"arvinder" wrote:
2) Each service should be categorised, either via a hardcoding of type under the registry, or a spi provided categorization. This may lead to signatures like searchByCategory etc.

"arvinder" wrote:
5) Aside from just services, will the registry hold dependant objects such as an XSD if there is say a validation service? Would this be classed as a ServiceResources and be grouped under the ServiceEntry such as ServiceEntry.getResources() ?

"arvinder" wrote:
1) The state of an endpoint service in the registry. This would be needed for clients and also reporting.

If this was supported I'd expect it to be part of the EPR. Each Service can have multiple EPRs and the "state" of each could be different, right?

"arvinder" wrote:
2) Each service should be categorised, either via a hardcoding of type under the registry, or a spi provided categorization. This may lead to signatures like searchByCategory etc.

We were saying that this type of more advanced lookup might be part of a future release. JAXR has the ideas of Service "Classification" and "Concept" and I'd guess that these could be used as parameters to a lookup. In the mean time though, the client/user can manually filter the Service list returned from getServices by manually interpretting the Classification/Concept settings on each Service.

"arvinder" wrote:
5) Aside from just services, will the registry hold dependant objects such as an XSD if there is say a validation service? Would this be classed as a ServiceResources and be grouped under the ServiceEntry such as ServiceEntry.getResources() ?

Note really sure about this Arvinder. So does the client need access to the physical XSD, or does it simply request the service to perform validation "XYZ"?

"arvinder" wrote:
What i think I was leaning to was, will we use the registry to hold objects other than Services, such as XSDs and XSLTs that are application resources that need to be accessed centrally? Thereby implying can a Service also be classed as an Application Resource ?

Hit send to fast there...

What I mean by "need the query capability..." is, all these ServiceObjects would be managed by the Registry - just like the Service objects. We could provide query interfaces for them e.g. getClassifications, getX, getY etc, but I dunno should we in the short/medium term???

Query capability and (Service) Object classification would be good candidates for initial inclusion or rather as part of the registry core use cases.

Are there any code skeletons that can be put inside svn or maybe wait till mark gets back? Btw, I am assuming that the registry is going to be a standalone server as well as embedded within the soa stack. Clients may want to run the registry as a standalone service. I'll have to look over the previous discussions to check, this may be irrelevant.

Lets wait for Mark to come back on this stuff. While certain features may be nice to have, I'd prefer to see only core capabilities added initially. Once we do a release we'll have a better idea of what we/others really need.

"Kevin.Conner@jboss.com" wrote:
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.

"Kevin.Conner@jboss.com" wrote:
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.