JAX-RPC client vs. Spring's JAX-RPC client

[currys]

Hello all,

I must admit to being new at this so excuse the newbie question. I colleague of mine stated that using normal JAX-RPC, I can call a web service using about three lines of code: 1) get locator, 2) get port, 3) call operation. However, with the Spring version using a JaxRpcPortProxyFactoryBean is far more code and XML configuration to do the same thing.

One could still create a managed bean in Spring that does the plain JAX-RPC call to get the IoC benefits.

I was planning on using the Spring version because I am a huge fan of it, but my coworker stated it would nuts to do so, since it is easier in plain JAX-RPC. I think we are missing something here but not sure what. So....

So, my question is, why does Spring provide the JaxRpcPortProxy? What benefit does it provide over plain JAX-RPC? Why does it seem to be harder to do in Spring than in JAX-RPC?

Thanks for helping enlighten us both.

Scott

[dejanp]

Well, what's a benefit of the DI and transparent integration anyway?

The Spring proxy solution makes your class independent of the actual implementation. There are no dependencies on rpc, RemoteExceptions, locators etc. You only see the simple business interface. That means that you can write a unit test for your class, provide a dummy implementation of the service and test it in isolation.

But really, I don't think that JaxRpcPortProxyFactoryBean needs _that_ much configuration. You need xml definition for interface, wsdl and that's it, more or less. In java code you don't need anything, afaik.

[derek]

The Spring proxy solution makes your class independent of the actual implementation. There are no dependencies on rpc, RemoteExceptions, locators etc. You only see the simple business interface.

That's not entirely correct. I may be mistaken too, but my experience a year or so back was that the Spring proxy solution doesn't throw the business exceptions declared by the service interface. It only throws wrapped RemoteExceptions (from which the business exception can be obtained).

Someone else posted about this recently: http://forum.springframework.org/showthread.php?t=42265

[currys]

Well, what's a benefit of the DI and transparent integration anyway?

The Spring proxy solution makes your class independent of the actual implementation. There are no dependencies on rpc, RemoteExceptions, locators etc. You only see the simple business interface. That means that you can write a unit test for your class, provide a dummy implementation of the service and test it in isolation.
.

I understand the benefits of DI (e.g. unit testing made easy, etc.), but it appears you can get all the benefits with just a simple DI bean design. That is, specify an interface, create an implementation that uses plain JAX-RPC or an alternate implementation that stubs out the service call, and switch between the two via DI configuration transparently. All this can be done without the JAX-RPC spring proxy.

I guess I am looking for something like the analogous DAO support. If you look at the JDBCTemplate (or ORM templates), they not only make DI easy, they provide real value on their own (e.g. closing of resources, exception translation, smaller LOC, etc.). My coworker is doubting the value of Spring's JAX-RPC proxy and I am trying to argue for it, but struggling to justify it. Perhaps is just not apparent to either of us.

Any help is appreciated. TIA.

Scott

[dejanp]

Well, of course, you can write your own "proxy" delegate implementation that will use the service locator that you have to generate. With Spring proxy you don't need an implementation class, you don't need generated service locator, etc.

[dejanp]

That's not entirely correct. I may be mistaken too, but my experience a year or so back was that the Spring proxy solution doesn't throw the business exceptions declared by the service interface. It only throws wrapped RemoteExceptions (from which the business exception can be obtained).

Someone else posted about this recently: http://forum.springframework.org/showthread.php?t=42265

That's the same problem I had with pure Axis, far before Spring times.

[currys]

Well, of course, you can write your own "proxy" delegate implementation that will use the service locator that you have to generate. With Spring proxy you don't need an implementation class, you don't need generated service locator, etc.

Great! Thank you for the feedback. So the follow up question, is how does the Spring proxy work without any generated code. That is, how does it do OXM, the mapping between the objects and the XML message for both request and response of the call? How does it create a stub to call? Finally, how would HTTPS work with the call?

TIA,

Scott

[derek]

That's the same problem I had with pure Axis, far before Spring times.

Is it only Axis that has this problem, or is it the same with other implementations?

[dejanp]

Great! Thank you for the feedback. So the follow up question, is how does the Spring proxy work without any generated code. That is, how does it do OXM, the mapping between the objects and the XML message for both request and response of the call? How does it create a stub to call? Finally, how would HTTPS work with the call?

TIA,

Scott

I never said it works without any generated code. You need to provide a business interface, so obviously you need to have some java classes.

The stub is created as a proxy of the interface you provide. Rest is, more or less, up to the implementation library, there is no standard, so there's not much Spring can do about it.

The implementation I tried a long time ago was Axis 1 and it was pretty awful. Newer stuff (Axis 2, CXF) should be better, but on the other hand, RPC is a dying standard and no-one wants to spend a long time polishing that area (XFire, for example, skipped the RPC support completely).

My suggestion would be: if you can - skip rpc and use document style using CXF provided Spring integration. If you have no control over the style of the service so you have to use rpc and the service is not trivial (it's not trivial if you use complex types as params and/or return values) - I'd go for the manually written delegate using generated locator/stub. The effort trying to make it work with Axis 1 is far too much and I have no idea how much effort would it be to make it work with Axis 2 or CXF.

[dejanp]

Is it only Axis that has this problem, or is it the same with other implementations?

In my experience, it was an Axis 1 problem. I never used JaxRpc with anything else so I can't really tell.

On the other hand, today, I'd never use RPC or faults/exceptions in web services if I don't have to. RPC is an interoperability nightmare (not my opinion really, i don't know enough about it, I'm just quoting Dan Diephouse and other WS gurus) and I have pretty bad experiences with using exceptions on system edges. I'm a firm believer in using runtime exceptions for technical errors and return values for everything else, when it's going to be used for remoting purposes.