SOAPProxy initialization and deployment ordering

[dward]

When the SOAPProxy action is constructed, it pulls the wsdl url as configured. The normal use case for a webservice proxy is that the webservice is "someplace else" and already available, and if it's not available, it rears itself as an initialization exception of the SOAPProxy.

However, what if the webservice is deployed in the same server as the esbservice containing the SOAPProxy? Well, right now, the war containing the webservice needs to be deployed first before the SOAPProxy, and the HTTP connector has to be started and available.

I'm starting this thread because I would like input on the following options (add more if you like):

1. Change nothing. Aren't proxied webservices normally external and should already be available?

2. *Lazily* initialize SOAPProxy on it's first real usage/invocation. I don't like this one because it's really a lie then if the esbservice seemingly successfully deploys, when in reality there's something wrong (in the case where the wsdl URL is bad or not available).

3 .Investigate using deployment.xml (<jbossesb-deployment>web applicationweb container</jbossesb-deployment>)? If this would work, I think it would be the best option.

[mvecera]

What about making the lazy initialization optional using a property in the action definition, or even make it possible to read the target WSDL URL from the message?

[bradsdavis]

SoapProxy is meant to take a service and expose it on the ESB.   However, proxing services exposed on localhost requires the services to  be written in JBossWS.  Otherwise, trying to proxy a localhost service  will cause the Server Restart to Freeze.  The server will get to the  point of trying to proxy, and then will try and attempt to load the WSDL  definition to proxy from the LocalHost, which is not yet available  because the server has not completed starting up.  This does not time  out, and leads to an unresponsive SOA-P server.

Additionally, in the case the  Web Service being proxied is not on the same box, the following  situation could occur.  If the SOA-P server is restarting and tries to  fetch the remote Service to proxy, if the remote service is temporarily  unavailable, the whole service containing the SOAP-Proxy will fail  deploying.  This is not ideal, since other services may be dependant on  the failed SOAP-Proxy service, leading to a domino affect of many  services failing.

Idealy, the service would start, and hitting the  SOAP-Proxy would return a service temporarily unavailable code, or  Soap-Fault.  However, it is crucial that the service start and also that  the service continues to periodically try and Proxy the remote service  to ensure when it comes online, the server can service requests  appropriately.

So to summarize, I think it should be Lazily initialized, and in the case that the service is unavailable when it does Lazily initialize, I believe that we should actively try to re-engage with the Proxied Web Service. Otherwise, when the remote services comes back online, if your organization has built against the ESB, even though the service is now available, the ESB Service will remain indefinately down until server restart.

[kconner]

proxing services exposed on localhost requires the services to  be written in JBossWS

Sorry, but this is not true.  If you mean that to proxy a service within the same VM then that is certainly the case by default.

trying to proxy a localhost service  will cause the Server Restart to Freeze.

Proxying a webservice within the same VM, over HTTP, will freeze as the web endpoints are not enabled until the server has started, there is a valve within the web server which controls this.  You can, however, workaround this by using the internal notation.

if the remote service is temporarily  unavailable, the whole service containing the SOAP-Proxy will fail  deploying

Yes, this is deliberate at present because we publish the derived WSDL and validate the configuration at that point.  As mentioned earlier in the week though, this is easy to work around by using a local copy of the WSDL and will give you the behaviour you require.

Kev

[bradsdavis]

The documentation says that internal:// is reserved for JBossWS.

Additionally, if localhost:// causes a server freeze, shouldn't it automatically see this as internal?  I dont think a server freeze should ever be possible from a URL configuration in the SoapProxy.

[kconner]

The documentation says that internal:// is reserved for JBossWS.

Correct, it can only be used against JBossWS services running within the same VM as it uses a JBossWS internal API.

If you chose to use a different SOAP stack, perhaps as a servlet within one of your deployments, then it would not help.

Kev

[bradsdavis]

Yes, this is deliberate at present because we publish the derived WSDL and validate the configuration at that point.  As mentioned earlier in the week though, this is easy to work around by using a local copy of the WSDL and will give you the behaviour you require.

I am saying if this is deliberate, we should fix it because it is a design flaw.  That is why I opened the support ticket.

[kconner]

if localhost:// causes a server freeze

Sorry, localhost is an IP address and is not relevant.  It is the referrral of a service within the same VM that can cause it to hang if goes through the web server valve.

Kev

[bradsdavis]

If you chose to use a different SOAP stack, perhaps as a servlet within one of your deployments, then it would not help.

I don't think in an ESB we should be restricting people to use one SOAP stack.  Especially considering some people prefer the Spring + CXF stack.  Or have legacy endpoints written in Axis.  The whole point of an ESB is to integrate with many technologies.  Considering legacy apps is one of the main drivers in ESB integrations in the field, it is not a viable solution to say "our ESB only works with JBossWS!"

[kconner]

I am saying if this is deliberate, we should fix it because it is a design flaw.

And I have been saying that we are doing it deliberately for good reasons.  It was not a decision that was taken lightly.

Kev

[bradsdavis]

Sorry, localhost is an IP address and is not relevant.  It is the referrral of a service within the same VM that can cause it to hang if goes through the web server valve.

Precisely my point.  localhost is really irrelevant; the point is, the SoapProxy should not freeze a deployment, no matter if the service lies on the same server or a different server.

And additionally, it should be tolerant when the proxied service is up or down.

[bradsdavis]

And I have been saying that we are doing it deliberately for good reasons.  It was not a decision that was taken lightly.

What were those reasons?  Did you consider at the time that if 10  services use the deployment descriptor to depend on the Proxy service  which fails, all 10 of those dependant services will also fail?  And then any services that rely on those 10 services could also then fail?  That is what I mean by domino affect.

[dward]

Brad Davis wrote:

Yes, this is deliberate at present because we publish the derived WSDL and validate the configuration at that point.  As mentioned earlier in the week though, this is easy to work around by using a local copy of the WSDL and will give you the behaviour you require.

I am saying if this is deliberate, we should fix it because it is a design flaw.  That is why I opened the support ticket.

I'm sorry, I can't resist responding.  How is this a design flaw?  If we went with a lazy approach, then we would have a deployed service for which we would not be able to expose WSDL for!  We need to pull in the WSDL on initialization so we can transform it and provide it to consumers of the ESB.  If we went the lazy way, we would get more bug reports from people saying "WSDL contract unavailable!"

[kconner]

localhost is really irrelevant;

It is irrelevant because it tells you nothing, you cannot base any decision on it.

Kev

[bradsdavis]

See: What were those reasons?  Did you consider at the time that if 10   services use the deployment descriptor to depend on the Proxy service   which fails, all 10 of those dependant services will also fail?  And  then any services that rely on those 10 services could also then fail?   That is what I mean by domino affect.