[kurtstam]

Actually I was thinking the findServiceBinding could be Collection findEPRs(Service service)

[marklittle]

I think that all makes perfect sense. A good way to start. Once we get deployments in the real world, we'll get feedback soon enough.

[kurtstam]

I think it makes sense to categorize(classify) the services, so that one could look up all the 'transformation' services. Each service can have have multiple ServiceBindings. Each ServiceBinding relates to an EPR.

Questions:
1. from where in the EPR can I get the serviceName (it looks like PortReference has this, should I use this?)
2. can we add the service category to the EPR somewhere (or should we add it in the serviceName by convention?)

[marklittle]

Why do you want the serviceName from the EPR?

Why do you want the service category in the EPR? An EPR is a physical endpoint address (c.f., a TCP/IP host/port pair, or a WWW URL). Given an EPR I cannot/should not be able to infer the type of service. The same endpoint, addressed through the same EPR, could be offering difference capabilities to different clients and hence appear as difference services.

[kurtstam]

There is no problem to register an EPR under multiple services, but when I register the EPR I need to know under what Service I'm going to register it.

We can add the (logic) serviceName as a separate argument and assume that who ever does the registration knows to what Service (and category) this thing belongs. Does that work?

Same holds for unregistring. And you'd only unregister the EPR listed under that category and service.

[marklittle]

There is no problem to register an EPR under multiple services, but when I register the EPR I need to know under what Service I'm going to register it.

We can add the (logic) serviceName as a separate argument and assume that who ever does the registration knows to what Service (and category) this thing belongs. Does that work?

Actually that's precisely how I thought it would work.

Same holds for unregistring. And you'd only unregister the EPR listed under that category and service.

+1

[tfennelly]

I was asking Kurt about this yesterday and he informed me that the requested behavior re EPR lookups from the registry was that the list of returned EPRs would only include services that are currently up and running i.e. services are supposed to register and deregister from the registry as they come up and go down.

If I understand this correctly, this creates a usability issue from the perspective of this ESB Admin Console App. Basically, it will mean that configurations associated with a particular EPR cannot be created while that Service/EPR is down/offline/deregistered.

Is there a way around this e.g. instead of just having a register and deregister, could we also have "online" and "offline" states/steps. So the following service lifecycle events could apply... "register"... "online"... "offline"... "online"... "offline"... etc... "unregister"

[marklittle]

Lifecycle information is not normally stored in the registry. That's contrary to the model. In most cases, the EPR is only valid for the life of the service, which means if the service goes "down" then when it comes "up" again it'll register itself using another EPR. You should probably not store configurations associated with EPRs anyway, since they can change even for the same service. The best thing to use would be the logical service name.

[tfennelly]

Sure thing on the Logical Service name etc... but I take it that this is also not available when the EPR is not available i.e. is this not accessed via the EPR?

On the Logical Service Names (and a little off topic perhaps).... I don't think they're available from the EPR interface that's in SVN i.e.Message.getHeader().getCall().getFrom/getTo etc

[kurtstam]

You may have multiple EPRs per Service, so typically you will just unregister the EPR and leave the service.

[marklittle]

You may have multiple EPRs per Service, so typically you will just unregister the EPR and leave the service.

+1

Think of the EPR like a CORBA IOR: unless you create it with a persistent policy, each time you create the service you'd get a new (unique) IOR.

[kurtstam]

The issue is fixed. It turned out that it's probably a bug in scout, where all ServiceBindings got deleted when you ask to delete one. I put a workaround in and will address the bug in scout after GA. It seems to work ok now.
See also: http://jira.jboss.com/jira/browse/JBESB-250

As far as a uddi browser goes. When you deploy the juddi.war that ship with our esb, you enable access through soap, which means that you can use any uddi brower. You can use http://uddibrowser.org. I don't find it particularly user friendly, but it seems to do the trick. Note that the juddi.war it self comes with a console too, but I think this is not fully upgraded from uddi v1.0 to v2.0, so not all queries (most actually) don't seem to work.

Cheers,

--Kurt