| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| All Java Nodes Implication |
« View previous topic :: View next topic » |
| Author |
Message
|
| essive |
 Posted: Mon Nov 15, 2004 11:02 am Post subject: All Java Nodes Implication |
 |
|
Novice
Joined: 15 Nov 2004
Posts: 24
|
We are evaluating Message Broker 5. Forgive the newbie question again, but, in our organization we have a very large Java practice for application development. Our previous message bus tool was all Java as well.
What would be the impact of running Message Broker development with Java custom nodes as the standard and ESQL only in special cases? Is this possible, or, would this be simply too difficult to manage and too much work per flow? Does anyone do this today? |
|
| Back to top |
|
 |
| kirani |
| Posted: Mon Nov 15, 2004 11:57 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Yes, its possible, but it'd be difficult to maintain. Without knowing what kind of java code it is .. it'd be hard to say which option is better for you. May I know what are the reasons behind migrating to Message Broker V5?
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| essive |
| Posted: Mon Nov 15, 2004 12:20 pm Post subject: |
|
|
Novice
Joined: 15 Nov 2004
Posts: 24
|
| The reasons are organizational and political (I can't say more than that). My assumption here is that the kind of Java code would be everything typically done with ESQL - parsing, validation, transformation, etc. |
|
| Back to top |
|
|
| kirani |
| Posted: Mon Nov 15, 2004 1:28 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Yes, that's true. Broker is mainly used for Transformation & Routing.
One important point you should consider when migrating existing Java code to Broker is that the Broker is NOT an application server.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| SixBlade |
| Posted: Tue Nov 16, 2004 12:49 am Post subject: |
|
|
Apprentice
Joined: 03 Dec 2003
Posts: 26
Location: UK
|
I'm looking into this as well: I've noticed I simply like it better when I have access to a standard programming language, various proprietary languages tend to lack strength in certain cases.
In a Java node, to work with the message tree the broker way is still possible, but it's harder than with ESQL(harder: it requires more code). Something to get used to. Also, java input nodes are not easy to stop(remove message flow). Of course, in Java you have access to XML parsers, reqular expressions etc instead.  I think it will be hard to use just Java unless you develop some helpers or special mapping guis(shouldn't be impossible...?), I mean if you have a lot of this knowledge and at lot of java code. |
|
| Back to top |
|
|
| JLRowe |
| Posted: Tue Nov 16, 2004 5:05 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
Java nodes cannot be deployed using the tooling, sure you could use ant to deploy them, but you still have to restart the broker every time you make a change (also a manual process that could be automated with ant).
If you have a lot of java skills, then I would think very very seriously about message broker and whether you want to invest in ESQL. In a lot of use cases, Java/J2EE is vastly superior to ESQL/WBIMB. The main advantages WBIMB has is data binding when you use MRM to model a message, handling of legacy formats such as tag delimited, fixed length etc and that WBIMB provides more of a 'point' solution for message handling, whereas an appication server such as WAS addresses a much broader set of requirements, but would require more customisation (ant scripts, framework code, library code) to achieve the same goal. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Nov 16, 2004 6:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jlrowe wrote: |
| If you have a lot of java skills, then I would think very very seriously about message broker and whether you want to invest in ESQL. In a lot of use cases, Java/J2EE is vastly superior to ESQL/WBIMB. The main advantages WBIMB has is data binding when you use MRM to model a message, handling of legacy formats such as tag delimited, fixed length etc and that WBIMB provides more of a 'point' solution for message handling, whereas an appication server such as WAS addresses a much broader set of requirements, but would require more customisation (ant scripts, framework code, library code) to achieve the same goal. |
That's only true where J2EE is actually the primary platform of your enterprise.
And I've yet to see an enterprise where J2EE was really the primary platform - from a business point of view. Everyone has PeopleSoft, Oracle Financials, SAP or other such a system for handling financials and HR tasks.
It is of significant architectural and business value to use some sort of broker architecture to decouple applications from the data formats of other applications.
It is of significant business value to allow programmers to focus on the work of the business, and not have to spend time building and tweaking and maintaining parsers and data transformation engine code.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JLRowe |
| Posted: Tue Nov 16, 2004 6:33 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
I would argue that it is worth adopting J2EE as an integration platform, this is clearly the aim of WAS server foundation. I would use WBIMB only for transformation of legacy formats to/from XML.
With J2EE you have a vast choice of JCA adaptors from a multitude of vendors (IBM, iway, attunity, oracle, SAP's own, peoplesofts own etc), with WBIMB you are limited to the WBI adaptors only. JCA can also operate synchronously within a transaction, so you can receive a message, update a database, send a message and update SAP all within a single XA transaction. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Nov 16, 2004 6:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| timna wrote: |
I would argue that it is worth adopting J2EE as an integration platform, this is clearly the aim of WAS server foundation. I would use WBIMB only for transformation of legacy formats to/from XML.
With J2EE you have a vast choice of JCA adaptors from a multitude of vendors (IBM, iway, attunity, oracle, SAP's own, peoplesofts own etc), with WBIMB you are limited to the WBI adaptors only. JCA can also operate synchronously within a transaction, so you can receive a message, update a database, send a message and update SAP all within a single XA transaction. |
With WBIMB you are limited to only those adapters that are able to put messages on a queue or in a JMS message or into a Web Services/SOAP call, not to simply the WBI adapters.
WBIMB is exactly as XA compliant as JCA.
I would use the right tool for the job. J2EE is not always the right tool. Neither is WBIMB.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
