[jira] [Commented] (JUDDI-941) Dynamic discovery of web service endpoint

["Alex O'Ree (JIRA)" <ju...@ws.apache.org>]

    [ https://issues.apache.org/jira/browse/JUDDI-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15005359#comment-15005359 ] 

Alex O'Ree commented on JUDDI-941:
----------------------------------

I agree. After looking at the code, the annotations support tokens which can be supplied via configuration file, system properties, java properties, etc.

See
https://github.com/apache/juddi/blob/master/juddi-client/src/main/java/org/apache/juddi/v3/annotations/AnnotationProcessor.java#L126

In Java:
@UDDIServiceBinding(
   accessPoint="${myProtocol}://${myHostName}:${myServerPort}/juddiv3-samples/services/helloworld?wsdl")
)

In config file, under /uddi/client/nodes/node[yourUddiServer]/properties/
<property name="myProtocol" value="https" />
<property name="myServerPort" value="myhostname" />
<property name="myHostName" value="443" />

I haven't tested this, but it should work. Give it a shot

So then the harder part would be to obtain that information (outside of Java code) and supply it via some sort of script (I'm assuming this is some sort of elastic cloud use case you're thinking of). In which case, I think you'd want to reference system environment variables. The code doesn't do that right but we can change it. The other option would be to create the config file via script using whatever method is available. We could also add something that resolves predefined variables at runtime to IP addresses, ports, system hostname etc. There's risk with that since often machines have multiple network cards ( which IP do we pick?) and the hostname may not be externally resolvable (localhost.localdomain).

Let me know if this helps and if we need to change things around in the code

> Dynamic discovery of web service endpoint
> -----------------------------------------
>
>                 Key: JUDDI-941
>                 URL: https://issues.apache.org/jira/browse/JUDDI-941
>             Project: jUDDI
>          Issue Type: Improvement
>          Components: juddi-client
>    Affects Versions: 3.3.1
>            Reporter: Matthieu Ghilain
>              Labels: SOAP, discovery, dynamic, endpoint, juddi
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Here is the example from the JUDDI documentation:
> {code:title=HelloWorldImpl .java|borderStyle=solid}
> @UDDIService(
>   businessKey="uddi:myBusinessKey",
>   serviceKey="uddi:myServiceKey",
>   description = "Hello World test service")
> @UDDIServiceBinding(
>   bindingKey="uddi:myServiceBindingKey",
>   description="WSDL endpoint for the helloWorld Service. This service is used for "
> 				  + "testing the jUDDI annotation functionality",
>   accessPointType="wsdlDeployment",
>   accessPoint="http://localhost:8080/juddiv3-samples/services/helloworld?wsdl")
> @WebService(
>   endpointInterface = "org.apache.juddi.samples.HelloWorld",
>   serviceName = "HelloWorld")
> public class HelloWorldImpl implements HelloWorld {
>     public String sayHi(String text) {
>         System.out.println("sayHi called");
>         return "Hello " + text;
>     }
> }
> {code}
> The problem with this kind of registration is that it is still static. The accessPoint should be resolved dynamically at runtime. Otherwise it is not possible to spawn new service instances dynamically and to scale. This in my opinion should be part of the JUDDI features.
> What do you think?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)