effects of WSDL Definition caching on WS URLs

[Scott Kurz <sc...@gmail.com>]

Hi,

This is my first post.  I work on SCA for IBM.

I found an issue (which I mentioned on the phone to Sebastien today).  I'm
not sure if it was a purposeful or accidental design decision, so before
opening up a JIRA I thought I'd write this up.

In short.. do you really want to cache the URLs along with the WSDL
Definitions for both EntryPoints and ExternalServices (for WS binding)
together?

In detail:

When invoking over a WS binding, it might be nice to say that, although both
client and server have a copy of the WSDL, that only the client URL matters,
but not the server's.

I'm talking about the <wsdlsoap:address> tag, for example in sample
HelloWorldWSClient as:

            <wsdlsoap:address location="
http://localhost:8080/helloworldws-SNAPSHOT/services/HelloWorldService"/>

As long as the client is invoked from a separate J2SE environment, you don't
have to match your server-side WSDL's <wsdlsoap:address> URL with the actual
deployment location and you can set the server-side WSDL to a URL that can't
receive HTTP requests.

However, when you call the same service over an external service WS binding
from a service co-hosted in the same Tomcat server as the module with the WS
Binding entry point, you have a new issue.  You generally must  keep three
pieces of data in synch: client URL, server URL, and deployment URL.

Unless you are lucky enough for the client module to be started up first.
In that case the server URL no longer matters.    Generally speaking, I
don't know when the order of module loading is allowed to matter, but I
wonder if this is unintended.

The low-level reason is the definitionsByNamespace map used by the method
org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.loadDefinitions
,
which maps namespaces to WSDL Definitions.

If the map and WSDL Definition processing were refactored somehow to save
the common portion of the Definition but to only cache the URL portion for
ExternalServices, not for EntryPoints, (or something like that), we could
eliminate the extra piece of redundant data.

Thanks,
 Scott Kurz

Re: effects of WSDL Definition caching on WS URLs

[Scott Kurz <sc...@gmail.com>]

At a high-level, the problem is just that the URL in the EntryPoint-side
WSDL used in a WS binding.sometimes matters and sometimes does not.

If an ExternalService using a WS binding with the same namespace as the
Entry Point is hosted in the same process as the Entry Point, then the URL
used to invoke the ExternalService will come from whichever WSDL Definition
is loaded first,
the EntryPoint's or the ExternalService's.

If the ExternalService lives in another JVM, however, then the EntryPoint
WSDL's URL is irrelevant for invoking the SCA WS over the External Service
WS binding.

At a low-level, you're much more familiar with the code than me.... all I
was suggesting is if there were value caching the WSDL Definitions per
Namespace, that maybe you could implement the cache such that
EntryPoint-side URLs would not take precedence over an ExternalService-side
URL in this manner.

If you're not sure what I'm saying still..... take the HelloWorldWSClient
sample, and put a JSP front-end on it, and package it into a WAR.    Then
take the HelloWorld WS sample WAR, and tweak the URL to something that
doesn't match your Tomcat server's URL.

If you install both WARs and you ensure that the newly-created
HelloWorldWSClient WAR starts before the HelloWorld WS WAR (with bad URL),
the sample will work fine... HelloWorldWSClient WAR will call out the WS in
HelloWorld WS.   If, however, the apps are started in reverse order, the
garbage URL on the EntryPoint-side will take effect and it don't work.

(Apologies if this exactly doesn't work, since I've been making mods to the
sample and don't know if I tried EXACTLY this.. but you get the idea).

Scott

On 4/18/06, Jeremy Boynes <jb...@apache.org> wrote:
>
> I'm not sure I fully follow but as I'm making changes in this area
> (switching over to using a central WSDLDefinitionRegistry) I'll bite.
>
> What I think you're suggesting is that the registry should not cache
> WSDL by location but by target namespace and that it should merge the
> various definitions it loads into one cached entry. In other words, it
> doesn't matter how many files we parse, all the information gets merged
> together and we return the union. Is that right?
>
> The thing that would concern me about that approach is that I am not
> sure how strict people are about not re-using namespaces in incompatible
> ways. I realise the intention is to use them to uniquely identify sets
> of definitions but I can't help but fear that in many cases the reality
> is they get reused. If that happens then I would be afraid the merging
> approach may lead to unexpected problems. Does anyone have more
> information here?
>
> Perhaps we can have a way in which namespaces can be tagged as "unique"
> or "reused" and in the first we support merging the definitions together
> into one entry but in the second we key solely off the physical location.
>
> --
> Jeremy
>
> Scott Kurz wrote:
> > Hi,
> >
> > This is my first post.  I work on SCA for IBM.
> >
> > I found an issue (which I mentioned on the phone to Sebastien
> today).  I'm
> > not sure if it was a purposeful or accidental design decision, so before
> > opening up a JIRA I thought I'd write this up.
> >
> > In short.. do you really want to cache the URLs along with the WSDL
> > Definitions for both EntryPoints and ExternalServices (for WS binding)
> > together?
> >
> > In detail:
> >
> > When invoking over a WS binding, it might be nice to say that, although
> both
> > client and server have a copy of the WSDL, that only the client URL
> matters,
> > but not the server's.
> >
> > I'm talking about the <wsdlsoap:address> tag, for example in sample
> > HelloWorldWSClient as:
> >
> >             <wsdlsoap:address location="
> > http://localhost:8080/helloworldws-SNAPSHOT/services/HelloWorldService
> "/>
> >
> > As long as the client is invoked from a separate J2SE environment, you
> don't
> > have to match your server-side WSDL's <wsdlsoap:address> URL with the
> actual
> > deployment location and you can set the server-side WSDL to a URL that
> can't
> > receive HTTP requests.
> >
> > However, when you call the same service over an external service WS
> binding
> > from a service co-hosted in the same Tomcat server as the module with
> the WS
> > Binding entry point, you have a new issue.  You generally must  keep
> three
> > pieces of data in synch: client URL, server URL, and deployment URL.
> >
> > Unless you are lucky enough for the client module to be started up
> first.
> > In that case the server URL no longer matters.    Generally speaking, I
> > don't know when the order of module loading is allowed to matter, but I
> > wonder if this is unintended.
> >
> > The low-level reason is the definitionsByNamespace map used by the
> method
> >
> org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.loadDefinitions
> > ,
> > which maps namespaces to WSDL Definitions.
> >
> > If the map and WSDL Definition processing were refactored somehow to
> save
> > the common portion of the Definition but to only cache the URL portion
> for
> > ExternalServices, not for EntryPoints, (or something like that), we
> could
> > eliminate the extra piece of redundant data.
> >
> > Thanks,
> >  Scott Kurz
> >
>
>

Re: effects of WSDL Definition caching on WS URLs

[Jeremy Boynes <jb...@apache.org>]

I'm not sure I fully follow but as I'm making changes in this area
(switching over to using a central WSDLDefinitionRegistry) I'll bite.

What I think you're suggesting is that the registry should not cache
WSDL by location but by target namespace and that it should merge the
various definitions it loads into one cached entry. In other words, it
doesn't matter how many files we parse, all the information gets merged
together and we return the union. Is that right?

The thing that would concern me about that approach is that I am not
sure how strict people are about not re-using namespaces in incompatible
ways. I realise the intention is to use them to uniquely identify sets
of definitions but I can't help but fear that in many cases the reality
is they get reused. If that happens then I would be afraid the merging
approach may lead to unexpected problems. Does anyone have more
information here?

Perhaps we can have a way in which namespaces can be tagged as "unique"
or "reused" and in the first we support merging the definitions together
into one entry but in the second we key solely off the physical location.

--
Jeremy

Scott Kurz wrote:
> Hi,
> 
> This is my first post.  I work on SCA for IBM.
> 
> I found an issue (which I mentioned on the phone to Sebastien today).  I'm
> not sure if it was a purposeful or accidental design decision, so before
> opening up a JIRA I thought I'd write this up.
> 
> In short.. do you really want to cache the URLs along with the WSDL
> Definitions for both EntryPoints and ExternalServices (for WS binding)
> together?
> 
> In detail:
> 
> When invoking over a WS binding, it might be nice to say that, although both
> client and server have a copy of the WSDL, that only the client URL matters,
> but not the server's.
> 
> I'm talking about the <wsdlsoap:address> tag, for example in sample
> HelloWorldWSClient as:
> 
>             <wsdlsoap:address location="
> http://localhost:8080/helloworldws-SNAPSHOT/services/HelloWorldService"/>
> 
> As long as the client is invoked from a separate J2SE environment, you don't
> have to match your server-side WSDL's <wsdlsoap:address> URL with the actual
> deployment location and you can set the server-side WSDL to a URL that can't
> receive HTTP requests.
> 
> However, when you call the same service over an external service WS binding
> from a service co-hosted in the same Tomcat server as the module with the WS
> Binding entry point, you have a new issue.  You generally must  keep three
> pieces of data in synch: client URL, server URL, and deployment URL.
> 
> Unless you are lucky enough for the client module to be started up first.
> In that case the server URL no longer matters.    Generally speaking, I
> don't know when the order of module loading is allowed to matter, but I
> wonder if this is unintended.
> 
> The low-level reason is the definitionsByNamespace map used by the method
> org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.loadDefinitions
> ,
> which maps namespaces to WSDL Definitions.
> 
> If the map and WSDL Definition processing were refactored somehow to save
> the common portion of the Definition but to only cache the URL portion for
> ExternalServices, not for EntryPoints, (or something like that), we could
> eliminate the extra piece of redundant data.
> 
> Thanks,
>  Scott Kurz
>