Does JBossWS optimize local invocations?

[mageshbk]

Ovidiu Feodorov says:

If both http/soap Webservice client and Webservice (server) are deployed in the same VM, will JBoss Remoting optimize the invocation, pass it by reference, avoiding serialization and the HTTP stack, or will serialize the invocation and send it over the HTTP stack?

What is the default behavior?
Can it be configured?

[mageshbk]

As far as Remoting goes the invocation is localized if it is in the same process space:

http://labs.jboss.com/jbossremoting/
"Local invocation - if making an invocation on a remoting server that is within the same process space, remoting will automatically make this call by reference, to improve performance."

Please see http://labs.jboss.com/jbossremoting/docs/guide/ch05.html#section-http-invoker section "5.9. Configuration by properties"

"BYVALUE (actual value is 'byvalue') - indicates if when making local invocations (meaning client and server invoker exists within same jvm), the marshalling will be done by value, instead of the default, by reference. Using this configuration, the marshalling will actually perform a clone of the object instance (see org.jboss.remoting.serialization.SerializationManager.createMarshalledValueForClone()). Value for this property should be of type String and be either 'true' or 'false'. In releases prior to 2.0.0, using this configuration setting would have forced invokers to be remote, which can now be done via FORCE_REMOTE config (see below).

FORCE_REMOTE (actual value is 'force_remote') - indicates if when making local invocations (meaning client and server invoker exists within same jvm), the remote invokers should be used instead of local invoker. Is equivalent to making invocations as though client and server were in different jvms). Value for this property should be of type String and be either 'true' or 'false'."

By default BYVALUE is false.

Although these are configurable in Remoting, JBossWS does not expose these as configurable parameters to the WS developer.

[mageshbk]

Darran says:

I do not believe this is actually the case, Remoting is only used to
transmit the message it is not used at the server side so this
optimisation is not possible.

I can't find it at the moment but I think their is an outstanding WS
Jira to allow in-vm optimisation.

[mageshbk]

I am not saying JBossWS does any optimization. The protocol specific
invocation happens through remoting layer and whatever he does is like a
black box to us. AFAIK these are documented in
org.jboss.remoting.InvokerLocator and the JBossWS client uses it for
invokation(invoke method). So obviously this optimization should
follow.

[thomas.diesler]

Well, a jbossws call by reference probably does not make sense, since handlers require the XML view of the payload. If object to XML serialization takes place anyway (which by nature is expensive) it remains to be shown what can be gained by a local remoting invocation.

Before we invest in an optimization at the transport level in VM we should investigate for what kind of payload this would make sense first.

In case there are no handlers involved an in VM optimization would theoretically be possible, but since web services is about document based integration of heterogeneous IT systems and not RPC you probably want to use something else (instead of WS) when you need RPC functionality.

[ovidiu.feodorov]

Hi Thomas,

Thank you for your answer.

It looks like we're talking about effects of two different mechanisms here. One is payload-to-XML serialization, which I understand cannot be avoided, and that is fine.

However, for co-located topologies, Remoting allows you a choice of either passing the already-serialized XML payload over the full TCP/IP stack and Tomcat HTTP Connector or just passing it directly to a local connector, which is obviously faster.

Does JBossWS take advantage of this second mechanism?

Thanks,
Ovidiu

[thomas.diesler]

Does JBossWS take advantage of this second mechanism?

No it does not, but my point is that the gain would probably be neglegable anyway because XML serialization is so expensive.

However I don't have data to support either claim.