Posts
It shouldn't be that difficult to build a standalone Weblogic
WS-Security enabled client for invoking JAX Web Services, but the
reality is that it is. Let's find out why.
What is recurring in the above passages is 'classpath' and the need for the Weblogic Server libraries to be available to it.Thing is I don't want to go through setting up a WebLogic instance just to get to those libraries, or build a client that depends on the classpath as well as the machine's or host OS's intricacies.Furthermore, any setup would have to be multiplied by 10, the number of machines looking to access the same web service.
In any case my Java client should always call into a Weblogic, well, 'client' library in order to consume the necessary functionality.Turns out that choosing the appropriate one is convoluted:
Do I need wlfullclient.jar, wlthint3client.jar, wlclient.jar, wljmsclient.jar, wlclient.jar, or maybe wlsafclient.jar? Also, don't forget wljmsclient.jar, wljmxclient.jar and wseeclient.jar.Spoiler alert, the one I used was wlsafclient.jar.
Terminology is not of much help either.You see, the manuals use the term 'standalone client' in a vague way, as in the JAX-RPC section we saw earlier, with The stand-alone client JAR file does not, however, support invoking Web services that use the following advanced features.But what is meant by that;is it referring to the 'standalone' Java 'client' I'm looking to build? Turns out that by 'client' is meant the jar that my Java client should call into in order to invoke the web service.In JAX-RPC's occasion this is wseeclient.jar.
But from now on and for the purposes of this article, 'client' will always mean 'my Java client' in either source or packaged form.
Going back to square one I wasn't particularly fond of this replication and the technical glitches I might have to confront.Instead I needed a solution able to work anywhere and under any environment with the minimum requirements possible, something that mostly boiled down to locating and importing the necessary library dependencies at runtime in a portable way.In other words, take care of those pesky import statements:
full article on i-programmer
What is recurring in the above passages is 'classpath' and the need for the Weblogic Server libraries to be available to it.Thing is I don't want to go through setting up a WebLogic instance just to get to those libraries, or build a client that depends on the classpath as well as the machine's or host OS's intricacies.Furthermore, any setup would have to be multiplied by 10, the number of machines looking to access the same web service.
In any case my Java client should always call into a Weblogic, well, 'client' library in order to consume the necessary functionality.Turns out that choosing the appropriate one is convoluted:
Do I need wlfullclient.jar, wlthint3client.jar, wlclient.jar, wljmsclient.jar, wlclient.jar, or maybe wlsafclient.jar? Also, don't forget wljmsclient.jar, wljmxclient.jar and wseeclient.jar.Spoiler alert, the one I used was wlsafclient.jar.
Terminology is not of much help either.You see, the manuals use the term 'standalone client' in a vague way, as in the JAX-RPC section we saw earlier, with The stand-alone client JAR file does not, however, support invoking Web services that use the following advanced features.But what is meant by that;is it referring to the 'standalone' Java 'client' I'm looking to build? Turns out that by 'client' is meant the jar that my Java client should call into in order to invoke the web service.In JAX-RPC's occasion this is wseeclient.jar.
But from now on and for the purposes of this article, 'client' will always mean 'my Java client' in either source or packaged form.
Where it all began
What prompted this quest was being handed a copy of a program's source, aka the 'client', that invokes a message level WS-Security Weblogic powered web service.This client software is expected to be receiving HL7 messages from another application and forward them to the Weblogic (JAX-WS) service.This setup then had to be replicated across 10 CentOS Linux production machines.eingGoing back to square one I wasn't particularly fond of this replication and the technical glitches I might have to confront.Instead I needed a solution able to work anywhere and under any environment with the minimum requirements possible, something that mostly boiled down to locating and importing the necessary library dependencies at runtime in a portable way.In other words, take care of those pesky import statements:
full article on i-programmer
Comments