Naming for webservice endpoints

[kcbabo]

Would like to get some community input on how we reference webservice endpoints in JBossWS from JBoss ESB configuration.  Today, SOAPProcessor and SOAPProxy can be configured with the name of webservice endpoint hosted in JBoss WS in the following manner:

SOAPProcessor

{code:xml}<property name="jbossws-endpoint" value="fooservice"/>{code:xml}

SOAPProxy

{code:xml}<property name="wsdl" value="internal://jboss.ws:context=foo,endpoint=HelloWorldWS"/>{code:xml}

Magesh is about to fix an issue with SOAPProcessor that will produce the following configuration change for SOAPProcessor:

{code:xml}<property name="jbossws-context" value="myapp"/>
<property name="jbossws-endpoint" value="fooservice"/>{code:xml}

The new jbossws-context property (optional and thus backward compatible) will allow JBossWS endpoints to be uniquely identified by using the combination of context and endpoint name.

David, Magesh, and I had a discussion last week around whether the SOAPProxy configuration should be updated to use a simplified syntax.  The following was thrown out as an example:

{code:xml}<property name="wsdl" value="jbossws://foo:HelloWorldWS"/>{code:xml}

The idea being that the above configuration value is easier to type and parse for humans (eliminates the boilerplate ObjectName syntax).  The question we have for the community is whether this would be desirable.  Is this configuration a pain point today?  Would changing it make the action significantly easier to use?  Your feedback is very much appreciated.

Cheers!

[mageshbk]

The following was thrown out as an example should be:

<property name="wsdl" value="internal://foo:HelloWorldWS"/>

[tfennelly]

For SOAPProcessor, how about also supporting the context defined on the "jbossws-endpoint" property (eliminating the need for the "jbossws-context" property) ala:

<property name="jbossws-endpoint" value="myapp:fooservice"/>

Of course, making sure it's backward compatible etc.

For "pure" consistency between SOAPProcessor and SOAPProxy, couldn't they both be coded to also support exactly the same format for internal endpoints i.e.

<property name="jbossws-endpoint" value="foo:HelloWorldWS"/>

and

<property name="wsdl" value="foo:HelloWorldWS"/>

So in the later... the "internal" scheme is implied by the absence of a scheme.... hmmm actually "foo" would be the scheme.  Actually... something that looks odd with the SOAPProxy.  The wsdl URI is kinda corrupt when defining it ala "internal://foo:HelloWorldWS".  Looks like a URI, but "HelloWorldWS" is where a port number would be expected.  Wouldn't that be an invalid URI syntax?  Maybe ye don't care about that, but I'd have though it would be good to maintain a valid URI (parseable etc).

[kcbabo]

Magesh Bojan wrote:

The following was thrown out as an example should be:

<property name="wsdl" value="internal://foo:HelloWorldWS"/>

I prefer the version I included in my original post since it does not change the existing syntax of "internal://" as it's used today.

[kcbabo]

For SOAPProcessor, how about also supporting the context defined on the "jbossws-endpoint" property (eliminating the need for the "jbossws-context" property) ala:

<property name="jbossws-endpoint" value="myapp:fooservice"/>

This is an interesting alternative, although I would prefer to use a jbossws: scheme to clearly separate values for new config from the old config.

For "pure" consistency between SOAPProcessor and SOAPProxy, couldn't they both be coded to also support exactly the same format for internal endpoints i.e.

<property name="jbossws-endpoint" value="foo:HelloWorldWS"/>

<property name="wsdl" value="foo:HelloWorldWS"/>

Now this is where things get really interesting.  I was thinking that we couldn't have a config syntax that would make sense between SOAPProcessor and SOAPProxy, but I think you are on to something here.  Only thing I would ask is that we actually use the jbossws: scheme (I think David suggested this in an email originally).

Re: the URI issue, a quick read of RFC 2396 leaves me with the impression that ":" is allowed in the path section of the URI.  I could be misinterpreting it though; relevant definitions from the RFC below ...

{code}
<scheme>://<authority><path>?<query>
path          = [ abs_path | opaque_part ]
abs_path      = "/"  path_segments
path_segments = segment *( "/" segment )
segment       = *pchar *( ";" param )
param         = *pchar
pchar         = unreserved | escaped |
                ":" | "@" | "&" | "=" | "+" | "$" | ",

{code}

[kcbabo]

I'm giviing up on the formatting of the URI syntax above.  The bottom line is that a path segment consists of the following:

pchar         = unreserved | escaped |
                      ":" | "@" | "&" | "=" | "+" | "$" | ","

Which leads me to believe that jbossws://foo:bar would be legal.

Can the context or endpoint names contain a "/" for JBossWS configuration?  That could cause a problem, I guess.

[kcbabo]

Related to the above post.

URI u1 = new URI("jbossws:/foo:bar");
System.out.println("scheme : " + u1.getScheme());
System.out.println("path   : " + u1.getPath());

scheme : jbossws 
path   : /foo:bar

[tfennelly]

Keith Babo wrote:

Related to the above post.

URI u1 = new URI("jbossws:/foo:bar");System.out.println("scheme : " + u1.getScheme());System.out.println("path   : " + u1.getPath());

scheme : jbosswspath   : /foo:bar

Ah cool.... QED

I must be mixing up with the URL syntax.

On the inclusion/exclusion of the scheme... I was thinking you could support a few options and recommend the explicit use of the scheme.  I just think it's nice to support at least one version common between both.  Then people can just cut & paste and it works... no need to remember to add/remove the scheme.  I think that would be workable... match in decreasing order of specificity type thing.

[tfennelly]

Of course another option for SOAPProxy... you could leave the existing "wsdl" property format as is and add support for a new (alternative) property that has exactly the same name and value format as the SOAPProcessor i.e. support 2 options.

URI:

<action ...>
    <property name="wsdl" value="http://...."/>
    ... etc
</action>

and, endpoint ObjectName...

<action ... class="org.jboss....SOAPProxy">
    <property name="jbossws-endpoint" value="foo:HelloWorldWS"/>
    ... etc
</action>

Raise an error if both are configured.

Just say'n.

[kcbabo]

Hmm ... that's an interesting idea. My impression is that adding a separate property to SOAPProxy might be a bit funky, but that's just me.  David is best qualified to address that.

Generally speaking, I like the idea of having a single way to reference JBossWS hosted services across ESB actions.  If we end up creating more confusion by changing the SOAPProxy config, however, then it's best to just fix SOAPProcessor and leave SOAPProxy alone.

[dward]

So, I've read this thread, and I'll repeat what I've said many times before.  I don't want to change the internal:// scheme's format.  It should stay the same for existing users.

I am also NOT okay with introducing a new property.  "Which should I use?" and "What happens if I use both?" will be frequent questions.

But I AM okay with introducing a new scheme/format.  So, leave this alone:

<property name="wsdl" value="internal://jboss.ws:context=foo,endpoint=HelloWorldWS"/>

and just add this:

<property name="wsdl" value="jbossws://foo:HelloWorldWS"/>

"That's my story, and I'm stickin' to it."

[kcbabo]

I've been thinking about this on and off for the last couple days and I think that we should go with Magesh's original proposed fix with two separate properties in SOAPProcessor, e.g.

<property name="jbossws-context" value="myapp"/>
<property name="jbossws-endpoint" value="fooservice"/>

We should leave SOAPProxy alone.  The existing method works, it's documented, and it's pretty darn easy to get the value of the internal: scheme (just copy and paste from the jbossws/services page).