SOA Repository and UDDI integration. WAS: Revised use case f

[jervisliu]

SOA Repository and UDDI integration is a very important topic, So I start a new thread here to better track this issue. Below is the original message posted by Jeff:

One other feature I would like to see is the ability to publish WSDL locations for Web services to a registry, in particular the jUDDI registry. While this is not the same as service deployment (which I think you explained very well is accomplished outside the Service Repository), it is an important function that can be automated by the Service Repository by using standard UDDI APIs.

[jervisliu]

So what does the use case look like? JBOSS ESB + a third-party standalone UDDI registry or JBOSS ESB + ESB embedded UDDI registry? I know JBOSS ESB has an embedded UDDI registry, but I believe it is used internally by ESB to handle service endpoint addresses for runtime only. I am not sure if this UDDI is open for extenal usage or it can be open for external usage.

If the use case is JBOSS ESB + a third-party standalone UDDI registry, we can do following:

1. Repository Explorer -> SOA Network -> Add new UDDI Registry: From the "New UDDI Registry" wizard we fill in UDDI server information like host name, port name, UDDI version etc.

2. Click the service icon, choose "Publish WSDL to UDDI Registry" from the pop up menu.

[jeffdelong]

While it is true that the ESB uses the registry for internal purposes, it is available for external uses; i.e. publishing the WSDL location.

However, I think what you describe in Step 1 is right on, whether the UDDI directory is our embedded jUDDI or some third party, it should look the same and the API to publish should be same (it is a standard after all). We are currently working on UDDI v3 support for jUDDI, so we should be able to standardize on the v3.

As for Step 2, I think there is a step within a service to select a Registry to publish to. I suppose there could be more than one in fact, for example a development registry, a testing / QA registry, and a production registry.

As far as publishing to the registry, it could be the user chooses to do this as described in your Step 3, or this could be the result of entering some phase in the Lifecycle, e.g., when entering service testing the service is published to the QA registry, when entering service deployment the service is published to production registry.



I will forward this forum post to Kurt in case he has any comments on this.

[jervisliu]

So a revised process is as below:

1. Repository Explorer -> SOA Network -> Add new UDDI Registry: This will start a "New UDDI Registry" wizard. From this wizard we fill in information like UDDI server host name, port name, UDDI version etc.

2. Click the service icon, choose "Publish WSDL to UDDI Registry" from the pop up menu. This will start a "Publish WSDL to UDDI Registry" wizard. This wizard will list all available UDDI registries (which were created in step 1). The user will be able to choose to which UDDI registry he/she want to publish the WSDL.

[kurtstam]

Thx for pinging me Jeff. Couple of comments. As far as the ESB is concerned it is not really 'internal'. The only thing specifically ESB about publishing the servicebinding is that it registers an EPR (rather then a URL).

ad 1. We may want to decide to only support the UDDI v3 specification.

ad 2. The jUDDI console (portlet and GWT based) has this functionality. Rather then duplicating it, we maybe be able to embed it. Note that only the location (URL) of the WSDL gets registered, it does not store the actual WSDL.

Also we're working on annotations to auto-register (web) services and their bindings, so this should lower the bar significantly to register services. So this may be a nice complementary feature.

--Kurt

[jervisliu]

"kurtstam" wrote:

ad 2. The jUDDI console (portlet and GWT based) has this functionality. Rather then duplicating it, we maybe be able to embed it. Note that only the location (URL) of the WSDL gets registered, it does not store the actual WSDL.

Kurt, thanks for the comments. What functionality? I presume the SOA Repository only needs a very simple GUI to input the location of UDDI server, then the SOA Repository will call some sort of UDDI client API (HTTP based or REST based?) to register a WSDL. Is is this correct?

[kurtstam]

Yeah the UDDI API is SOAP based. UDDI allows for looking things up, and organizings (categorizing) things using standard categorization schemes, but not for storing things. That's where guvnor comes in. I would think the UDDI would store the meta data. So I guess the "SOA repository" is the thing that sits on top of both UDDI and Guvnor, and this would be where the integration lives?

--Kurt