| Author |
Message
|
| mqsiadm |
 Posted: Fri Oct 31, 2008 6:53 am Post subject: can JavaCompute node invoke webservice client jar file? |
 |
|
Novice
Joined: 05 Mar 2006
Posts: 12
|
i am trying to invoke webservices client jar from java compute node. are there any specific steps which needs to be followed?
any advice will be appreciated.
thx,
Chris. |
|
| Back to top |
|
 |
| zpat |
| Posted: Fri Oct 31, 2008 7:09 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Why not use the WMB 6.1 SOAP nodes provided?
Use of Java in WMB should be kept to a minimum and never used where there is a built-in WMB node providing the same function.
The purpose of Java compute nodes is to allow transformation using Java rather than ESQL syntax. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 31, 2008 7:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| Use of Java in WMB hould be keep to the minimum |
Use of Java in WMB should be used where skills in ESQL do not exist, and mapping node functionality is insufficient for the need. ESQL and Java are both equally valid approaches for use in Message Flows.
| zpat wrote: |
| and never used where there is a built-in WMB node for the same function. |
Yes, this I agree with 100%. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 31, 2008 8:02 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
ESQL is, in my opinion, extremely easy to use and anyone with any kind of programming experience can pick it up. It's power to manipulate messages and database tables is unrivalled.
Java, in my opinion, suffers from it's fussy C language heritage and can be hard to understand.
Most WMB sites will already be using ESQL and it will add to the long term cost of maintenance to use Java as well, just because of individual preferences.
In a greenfield WMB site, which has plenty of Java resources and wants to use the same developers on WMB then fine. I still think it is making life more complex.
The point of WMB is to make it simpler to develop MQ based applications and not to be another type of Java app server.
IBM have always been keen on Java and yet they chose ESQL for the broker product - there were (and remain) good reasons for that.
They have added in Java for completeness after many years without it!
In my view it should only be used for simple transformation statements but inevitably it will be mis-used and lead to long-term maintenance nightmares. Calling JAR files is one example of this. |
|
| Back to top |
|
|
| mqsiadm |
| Posted: Fri Oct 31, 2008 9:01 am Post subject: |
|
|
Novice
Joined: 05 Mar 2006
Posts: 12
|
zapt & mqjeff thanks!!
internal to our organization Webservices client jars are distributed rather than WSDL. this makes life easy if there is any change to the Webservices.
now take this example. we had a Webservices server running on WAS5 and the client being broker consuming it using URL and HTTP nodes. Now the Webservices is upgraded to WAS6 and it has started returning tons of namespaces. The old broker code in ESQL started failing here.
Instead of this if the broker code was developed using java & jar client these issues could have been avoided as java node would be just invoking methods on the client jar.
the jar client file is webservices client which runs on WAS server so do i even need the http node to invoke the WS client? can i not bypass the http nodes just use javaCompute + webservices jar?
In a greenfield WMB site, ----------- zpat, where can i get the url to this?
thx,
Chris. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 31, 2008 9:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
This is a very tightly coupled way of distributing web services.
It is best practices to distribute the WSDL and not any kind of prebuilt jar file that contains code.
What if the verison of WAS that is supposed to run this jar file is using Java 1.6? You can't run Message Broker version 6 with Java 1.6, so you can't use this class.
What if you need to use a .NET client to call the Web Service? Or a php client?
Yes, every time a service changes it's definition, then everyone who uses that service has to change their code. Every time you change any kind of interface at all, everyone who uses that interface has to change their code.
EVEN WITH YOUR TECHNIQUE, if new fields are added to the service, you *still* have to change YOUR code to populate those new fields... So how does having someone else build the 'client jar' make that any easier?
You have no idea how many other classes that client jar is dependant on. You have no idea how much work it will take to allow you to make that work in a JavaCompute node.
It's going to be a *lot* easier to generate a message set from the WSDL, and write ESQL (or Java Compute) code to use that message set. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Oct 31, 2008 2:37 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| it has started returning tons of namespaces. The old broker code in ESQL started failing here. |
What was the failure? Were you using the ( non-namespace aware ) XML domain, instead of XMLNS?
My instinct is to agree with mqjeff. I would challenge my assumptions very strongly before taking the route which you are following. Specifically, I would want to prove to myself that WSDL and its associated standards really could not meet the requirement. |
|
| Back to top |
|
|
|
|
