How to store EPRs in the registry?

[kurtstam]

Now that the registry is ready it's time to put something in it. We seem to have 2 classes of services:

1. Gateways, ESB-unaware services - Gateways can be used by non-ESB aware clients/services to access ESB services. The addresses for these gateways can be arbitrary and shouldn't be influenced by the EPR. It seems logical to use a URI to define such and endpoint and we can store URI's in the registry (the ServiceBinding contains a URI-element)

2. ESB-aware services. ESB-aware services have a fully populated EPR and all of this information can no longer be stored in an URI. The current thinking is to store the entire XMLized EPR to the registry. To store WSDL the tModel is used (in JAXR this is a Concept(fingerprint) and/or Classification(namespace), see also http://java.sun.com/developer/technicalArticles/WebServices/jaxrws/
. We may want to store the EPR-XML in the same place. If we do so, what will we put in the URI reference for the ServiceBinding. Maybe something like "epr://jbossesb" to define what type of 'protocol' we are using.

Well I hope this is enough to start a discussion on this matter.

--Kurt

[marklittle]

We're assuming that the Registry is available to both ESB-aware and ESB-unaware clients/services.

(i) If ESB-unaware services want to register in it for use by ESB-unaware clients then the format they use for storing information is entirely up to them, i.e., we don't need to worry about it.

(ii) if ESB-unaware services want to register for use by ESB-aware clients, then we obviously can't require that those services register EPRs because they are ESB-unaware. However, since our clients are ESB-aware, they'll expect EPRs to address those services, which means that the use of an external gateway is the way to go: the EPR addresses the gateway, which then translates the request message as well as redirecting the resulting message to the real service.

(iii) if ESB-aware services want to register for use by ESB-unaware clients, then they publish their addresses as EPRs, since that's what ESB-aware services do naturally. We would develop a series of gateways to map EPRs to ESB-unaware address formats; these formats will typically be tied to the client's deployment environment (e.g., JEE or CORBA), so there will need to be a series of these adapters.

(iv) if ESB-aware services want to register for use by ESB-aware clients, then they publish their addresses as EPRs and the clients use those EPRs.

I think that just about covers it for now.

[marklittle]

1. Gateways, ESB-unaware services - Gateways can be used by non-ESB aware clients/services to access ESB services. The addresses for these gateways can be arbitrary and shouldn't be influenced by the EPR. It seems logical to use a URI to define such and endpoint and we can store URI's in the registry (the ServiceBinding contains a URI-element)

The gateway concept is still under development, so I'd prefer to postpone any discussion on this until we've got that completed. Otherwise it's potentially like shooting at a moving target.

2. ESB-aware services. ESB-aware services have a fully populated EPR and all of this information can no longer be stored in an URI. The current thinking is to store the entire XMLized EPR to the registry.

That approach has precedent with Web Services.

To store WSDL the tModel is used (in JAXR this is a Concept(fingerprint) and/or Classification(namespace), see also http://java.sun.com/developer/technicalArticles/WebServices/jaxrws/

We'll certainly need to store WSDL and other contract definition information later, as we really explode how the ESB uses the Registry. At the moment we're really looking at the first steps though: more like a basic naming service. So I wouldn't expect we're looking at anything more complex than an EPR. Would you?

. We may want to store the EPR-XML in the same place. If we do so, what will we put in the URI reference for the ServiceBinding. Maybe something like "epr://jbossesb" to define what type of 'protocol' we are using.

Well I hope this is enough to start a discussion on this matter.

--Kurt

Is this not where the Logical Name comes in? From the outset we've talked about two types of names:

(i) the "physical" name, which is the EPR and needed to address the service. This name may be obtained from the Registry or from elsewhere. But the Registry is the preferred approach.

(ii) the "logical" name, which is a convenient short-hand, like "Kurt's Travel Agency". Obviously in order to interact with a service you need a real address, so if all you've got is a logical name you need some way of mapping one to the other. That's where the Registry comes in again. The Registry maintains a tuple space of <logical name, physical name>.

We could set the logical name as the URI. As you say, something like: epr:jbossesb:version:1.0:logicalname:KurtsTravelAgency

[kurtstam]

At the moment we're really looking at the first steps though: more like a basic naming service. So I wouldn't expect we're looking at anything more complex than an EPR. Would you?

No, I agree for now EPR is what we should be going after, I just brought this up as an analogy.

Is this not where the Logical Name comes in? From the outset we've talked about two types of names:

(i) the "physical" name, which is the EPR and needed to address the service. This name may be obtained from the Registry or from elsewhere. But the Registry is the preferred approach.

(ii) the "logical" name, which is a convenient short-hand, like "Kurt's Travel Agency". Obviously in order to interact with a service you need a real address, so if all you've got is a logical name you need some way of mapping one to the other. That's where the Registry comes in again. The Registry maintains a tuple space of <logical name, physical name>.

We could set the logical name as the URI. As you say, something like: epr:jbossesb:version:1.0:logicalname:KurtsTravelAgency

Every Service and ServiceBinding can have a name. This name is used when querying for a service. The physical and logic names you refer to are more 'addresses' to me. But I agree with what you say.

OK so I guess we now have:
-ServiceBinding.name = "Kurt's Travel Angency"
-ServiceBinding.URI = "epr:jbossesb:version:1.0:logicalname:KurtsTravelAgency"
I'm going to see how we should be using the 'tModel' to store the EPR. I think it will be something like this:
-ServiceBinding.Concept = the EPR-XML
-ServiceBinding.Classification = "jbossesb-aware"
but let me look into this a little.

I pretty sure we gain searchability from classifying things. So the way we organize things may help us when searching for a Service.

--Kurt

[kurtstam]

Small correction. ServiceBinding does not actually have a name (not implemented on the UDDI side), but it's parent Service does.

[marklittle]

Is this not where the Logical Name comes in? From the outset we've talked about two types of names:

(i) the "physical" name, which is the EPR and needed to address the service. This name may be obtained from the Registry or from elsewhere. But the Registry is the preferred approach.

(ii) the "logical" name, which is a convenient short-hand, like "Kurt's Travel Agency". Obviously in order to interact with a service you need a real address, so if all you've got is a logical name you need some way of mapping one to the other. That's where the Registry comes in again. The Registry maintains a tuple space of <logical name, physical name>.

We could set the logical name as the URI. As you say, something like: epr:jbossesb:version:1.0:logicalname:KurtsTravelAgency

Every Service and ServiceBinding can have a name. This name is used when querying for a service. The physical and logic names you refer to are more 'addresses' to me. But I agree with what you say.

OK so I guess we now have:
-ServiceBinding.name = "Kurt's Travel Angency"
-ServiceBinding.URI = "epr:jbossesb:version:1.0:logicalname:KurtsTravelAgency"
I'm going to see how we should be using the 'tModel' to store the EPR. I think it will be something like this:
-ServiceBinding.Concept = the EPR-XML
-ServiceBinding.Classification = "jbossesb-aware"
but let me look into this a little.

I pretty sure we gain searchability from classifying things. So the way we organize things may help us when searching for a Service.

--Kurt

This is all in a state of flux now that WS-A has become a standard and UDDI evolves. However, what we do for the initial release doesn't necessarily have to be the way we continue to do things. So I think if we can agree on a "good enough" approach for the 4.0 release, we can revisit this later.

[kurtstam]

This is all in a state of flux now that WS-A has become a standard and UDDI evolves. However, what we do for the initial release doesn't necessarily have to be the way we continue to do things. So I think if we can agree on a "good enough" approach for the 4.0 release, we can revisit this later.

[kurtstam]

We have chosen JAXR-1.0 for this release, so I would think that drives the "good enough"? We need to put a stake in the ground somewhere.. I mean we can let go of JAXR (or wait for 2.0) if that's what you're suggesting, but as you say for 4.0 that's not really an option anymore. Also we'd like to people to use their existing UDDI systems right?

[marklittle]

No, I'm not suggesting dropping JAX-R or UDDI. By "good enough" I meant: let's just take a schema along the lines of the one you outlined and use that.

[kurtstam]

OK you confused me there :). Everything evolves and will be changing over time, especially in our world of software.

[marklittle]

Just a thought, and not for the up coming release. We could assume that EPRs are created (the term used by the WS-A TC is "minted") on demand. In some cases this is the case and each user gets a unique EPR for the same service. In which case, the EPR is never published in the registry. Rather, the URI of the minter is placed there and the client then sends a "create EPR" request to that URI.

[marklittle]

I wouldn't worry. If we support this approach and associated use case then it'll be in 2007 and not the release we have planned for this year.

[kurtstam]

I'm working on the RegsitryUnitTest as an example on how to store and retreive one of our EPRs. I'm playing with how to classify and categorise them so that we have maximum flexibily and search capability. That work shouldn't really go much beyond today, which makes us ready for integration next week, or whenever we merge in the latest architectural changes into the trunk.

[marklittle]

Sounds good. How much of this will be hidden from users (services when they publish and clients when they search and use) and how much of it will they need to know?

[kurtstam]

I think that when we agree on the structures, we can hide it all from the users. In fact we can probably define that right now. I think it will probably be something like this:

Class EPRRegistry {

publish(String serviceName. EPR epr)

Collection<Services> findServices();
Collection<Services> findServices(String serviceType);
Collection<ServiceBindings> findServiceBindings(Service service);
... more finders

I'm assuming we will publish all Services under the same "JBossESB Organization". So we could hardcode that (or not..) We'll see, but this is what I was thinking of.

I do think the user will usually get a collection of Services back, so he or she will have to decide which one to use, and then for that Service there may be multiple Bindings (each continaing an EPR), so again the user will have to figure out which one to use. Does that make sense? Or do you see clear rules on how to narrow down the results?