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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4118161#4118161
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4118161
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-inv... 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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4118145#4118145
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4118145
hi everybody,
i merged my changes for the metro integration today.
trunk now contains an wsrm example, which is a good starting point
if you want to explore configuration mechanisms. basically it's all
driven by WSDL snippets, that contain policy declarations for each
particular extension and get deployed through WEB-INF / META-INF.
Netbeans is a big plus to correctly configure WSIT features.
More examples to follow.
In order to build it requires proper java.net access to the CVS.
I'll keep you posted.
/Heiko
I just sent this to the CXF dev forum
anonymous wrote :
| Hi Folks,
|
| over the last couple of days I tried to integrate CXF's WS-RM implementation with JBossWS. Last summer, we announced that JBossWS would provide a pluggable WS framework (see the links below) that would allow JBoss customers to run CXF as the preferred WS implementation in JBoss.
|
| JBossWS supports CXF as a pluggable WS framework
| http://netzooid.com/blog/2007/07/02/jbossws-supports-cxf-as-a-pluggable-w...
|
| JBossWS supports pluggable Web Service stacks
| http://www.jboss.org/index.html?module=bb&op=viewtopic&t=112417
|
| We have setup a common testsuite for JAX-WS endpoints and clients that we test against (JBossWS) Native, Metro and CXF. In a nutshell, the integration of cxf-2.0.3 looks promising with only a few outstanding issues
|
| Resolve JBoss common jax-ws testsuite issues
| https://issues.apache.org/jira/browse/CXF-1243
|
| The next thing I tried was to integrate CXF's WS-RM implementation. In essence I tried to setup JAX-WS RPC/Document endpoints that I configured to use RM. On the client side I tried to stick to standard JAX-WS API as much as I could. The issues that I encountered on the way are aggregated here
|
| Resolve JBossWS/CXF WS-RM integration issues
| http://issues.apache.org/jira/browse/CXF-1328
|
| some of them have workarounds, others not. What I currently have are endpoints that reject non RM messages, but choke on RM messages because of [CXF-1321]. The client seems to work ok for Document but not for RPC [CXF-1322]
|
| Ideally, I would like to get this work completed early next year. Perhaps there is somebody available, who I could contact to discuss what I should expect in terms of working functionality and how to get things working in an integrated environment.
|
| As a result I would write a step by step guide on howto enable a JAX-WS endpoint for RM [CXF-1311].
|
| Have a good holiday & cheers
| -thomas
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115010#4115010
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115010