Hi
Recently we were in need of connecting to a thirdparty server which hosts webservice. The twist is we cannot connect to them using normal soap connectors. They had provided their own “yyyclient.jar” and inorder to include this in our package, had to include all the axis.jar, common-logging.jar, log4j and couple of related jar files. The behaviour that we see is, within webMethods when we invoke method on 'yyyClient.jar", there is large CPU utilisation and GC happening with close to 60 sec for the process to connect to target system and receive response FIRST TIME after package reload/server restart.Subsequent calls are pretty was fast. We had included all the necessary files in “code/jars” of the “YYYpackage”.
It has to be noted that same set of services running outside webMethods provides results in 1 sec.
Also we explored the possibility of moving this to “code/jars/static” folder, which worked very well without latency. However the jars inside the static folder gets loaded as server starts up, we had a clash of log4j version which we have in IntegrationServer/lib/jars with jar version in “YYYpackage”.
Is there any better way of handling this, considering the fact that we need to maintain 2 versions of log4j ? Or Is there any other alternative to reduce the latency.
Any help on this appreciated
This probably isn’t helpful, but the obvious solution is to get rid of the “yyyclient.jar” and all the supporting jars. It makes no sense to me that if they are exposing a web service that you would need to use these libraries.
Typically when someone uses the term “web service” they are describing functionality that can be invoked by sending a SOAP message to the service provider. In this case, it sounds like the provider has also created the client code to consume their own service and wants you to use it.
It’s nice that they provided an example, but you certainly don’t need to use their client code to invoke the service they are providing. Since IS can create SOAP requests without using any third-party jars, I agree with Rob that these are almost certainly not required.
You should obtain the WSDL that describes the Web Service from the service provider and use it to build a Flow service that will produce the correct SOAP request and send that request to the endpoint URL.
I totally agree on this possibility. However there are certain issues.
When we invoke the client jar files i had highlighted, it actually starts up a client thread (startup thread). Then the first call is made to the system (authentication) and we get back a serialized user object. This user object is passed in the method in the next call for the actual functional call.
Due to these dependencies we are not in a position to make use of the built-in soap services of webMethods to connect /retrieve data.
That’s not a web service then. It’s a kludgy, non-standard, pile 'o crap calling itself a web service, IMHO.
My guess is that you can make a web service call to some type of “login” method that will return the user “object” that can be used on subsequent calls.
Again, get the WSDL, it will tell you what you need to know. If there is no WSDL and you have to use their custom java app then what they are providing is not a “web service” and is certainly not interoperable. What if your company were a Microsoft shop?