[Design of JBoss ESB] - Re: Registry Design
by tfennelly
Ups, messed up there (again ;( )
The last bit should have been:
anonymous wrote : 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 Classification and Concept 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)?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967517#3967517
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967517
19 years, 7 months
[Design of JBoss ESB] - Re: Registry Design
by tfennelly
anonymous wrote : So Tom, our current objective is to think along the lines of the QueryManager right?
Well, I'm just saying that the data model and query interface as defined in JAXR might not be such a bad starting point for us re a reg interface/abstraction for the ESB Registry Service. After all, this is exactly what JAXR was designed to be - an implementation agnostic interface.
anonymous wrote : 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?
I'm not really saying that. Not sure if or how such an abstract type would appear in our interface - it might not!
anonymous wrote : 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 Classification and Concept 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)?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967516#3967516
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967516
19 years, 7 months