| Author |
Message
|
| RINU |
 Posted: Wed Jul 21, 2004 1:41 pm Post subject: Enterprise Integration using WBI |
 |
|
Newbie
Joined: 21 Jul 2004
Posts: 6
|
Hi,
We are currently working on a ground up J2EE/JAVA project. At the enterprise Integration tier (with mainframes) there is a push to use WBI product as an integration tool.
Today we had a vendor demo; I am still not convinced it is the right tool in its current incarnation. Following are some concerns I have.
1) JAVA vs ESQL. Our project started off as a completley open Java/J2EE project. We have lot of business/integration rules within
each integration point. Is it a good idea to introduce and code those
in a proprietary language like ESQL.
2) We were told the demo version (v5 service pack 2 ?) have only limited
java plug in support; category 3. We were also told that the WBI tool
is more moving towards J2EE. Is it worth waiting for the next version
before we dig in further?
3). Is it as reliable as we were told - in production heavy transaction volume environment such as millions of messages
4) Though I understand the value of integration bus (and other high level
tooling on top of message broker such as workflow etc ), I am still struggling to find the value of using this tool in the current project. To me
all our integration requirements and better code re-use can be achieved using stratight Java/J2EE and queues.
I would really appreciate if you could share your thoughts and comments on this.
regards,
RINU |
|
| Back to top |
|
 |
| kirani |
| Posted: Wed Jul 21, 2004 5:00 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
| RINU wrote: |
1) JAVA vs ESQL. Our project started off as a completley open Java/J2EE project. We have lot of business/integration rules within each integration point. Is it a good idea to introduce and code those in a proprietary language like ESQL.
|
Well, ESQL is very much like SQL, so don't think that it as an aliean language!! Using ESQL it's very simple manipulate parsed tree and convert it to different format. A Java programmer can learn ESQL very easily.
| RINU wrote: |
2) We were told the demo version (v5 service pack 2 ?) have only limited java plug in support; category 3. We were also told that the WBI tool is more moving towards J2EE. Is it worth waiting for the next version before we dig in further?
|
I don't know what the Sales person meant by "moving towards J2EE". But in next Fixpack (Microsoft users term ServicePack) you can call Java classes from your ESQL code. Please see this thread for what's coming in WBIMB FixPack 4.
| RINU wrote: |
3). Is it as reliable as we were told - in production heavy transaction volume environment such as millions of messages
|
I don't know what you were told!! But from experience I can say that given "good hardware" and "good message flow design" you can achieve "good throughput".
If you have tight SLA for heavy volume data then do some analysis before. In our environment we are processing around 5-6 million records using WMQI 2.1 Broker on window platform per day during our batch processing. For online systems, we have around 1200 users going thru the same Broker (RQST/RPLY Transformation) in a day. It's good to setup some type of guidelines before indicating what should be implemented in the broker and what shouldn't. Many people think that Broker is an application server, which is incorrect.
| RINU wrote: |
4) Though I understand the value of integration bus (and other high level tooling on top of message broker such as workflow etc ), I am still struggling to find the value of using this tool in the current project. To me all our integration requirements and better code re-use can be achieved using stratight Java/J2EE and queues.
|
This tool lets you keep your message layouts centralized. It comes with built-in parsers for handling many standard message formats like C Structure, COBOL Copybooks, XML, Tagged Delimited messages, etc. It also provides you the framework for writing your own parsers and plug-in nodes. I believe it'll be too much to write a code for handling/parsing standard messsage formats like SWIFT, EDI etc. correct?
I hope thins answers some of your questions.
What type of processing are you going to use this Broker for? Can you explain?
_________________
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 |
|
|
| jefflowrey |
| Posted: Thu Jul 22, 2004 5:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If all that you ever have to talk to is another J2EE application running inside the same J2EE container, then you don't need something like WebSphere MQ Integrator.
But there isn't a single enterprise out there that is a pure J2EE environment and does not ever talk to an external entity except through HTML.
If you want to integrate other systems with your J2EE applications, or your J2EE applications with other systems, it is far better to separate the integration into a separate system. That way you can manage change, rather than struggle with it! And you can keep your applications tightly focused on their particular purpose - which means that your applications can be smaller and easier to design, code and maintain.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PGoodhart |
| Posted: Thu Jul 22, 2004 6:01 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
Just had to put in my two cents:
1. Java/J2EE is a programing language, not a solution. WBI is a solution, not a programming language. If you don't have the proper needs, WBI does not make sense.
2. The WBI essentially is a collection of processes to change/alter/manipulate/enrich/route messages. The amount of ESQL needed to significantly change a message format is MUCH smaller then the amount of Java required to do the same exact thing. Why reinvent the wheel? (Other then job preservation...)
3. Like stated by the previous posters, WBI is not an application server, it really is just a message handler (a very complex message handler that can do almost anything to a message).
4. It makes sense to use WBI even if you don't have a bunch of different platforms, if you want to plan for platform indepence/application reuse & modularity in the future. Applications can be very granular if built with WBI as a backing service.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
| RINU |
| Posted: Thu Jul 22, 2004 7:06 am Post subject: |
|
|
Newbie
Joined: 21 Jul 2004
Posts: 6
|
Thank you all for your replies.
| Quote: |
RINU wrote:
1) JAVA vs ESQL. Our project started off as a completley open Java/J2EE project. We have lot of business/integration rules within each integration point. Is it a good idea to introduce and code those in a proprietary language like ESQL.
Well, ESQL is very much like SQL, so don't think that it as an aliean language!! Using ESQL it's very simple manipulate parsed tree and convert it to different format. A Java programmer can learn ESQL very easily.
|
I agree ESQL seems easy to learn. My concern is more from a code re-use perspective. As mentioned above, we have a lot of complex business/integration rules within each integration points that need to be used while we apply transformations to data. The project has a very clear separation between business and integration tier. But there is an opportunity to re-use lot of process/business rules from the business tier in the integration tier. My concern is whether we will end up in 2 implementation of the same rules, one in business tier in Java and the same in integration tier in ESQL for the benefit of WBI tool. My concern is also regarding the redundant maintenace in both places in future. 
| Quote: |
What type of processing are you going to use this Broker for? Can you explain?
|
The project - client/presentation/business tier will create sales data in
XML format. The plan is to use the broker in the integration tier
to pass this data to 30-40 enterprise systems (mix of mainframe, unix servers etc in both batch and realtime mode). All these systems require data in heavily custom formats and that is why we got to apply complex transformation rules while feeding them.
from the link mentioned above ...
| Quote: |
Enhancement included in CSD4
Support calling Java classes from ESQL.
|
This looks promising. Hope this means we can use ESQL for simple
re-formating type of work and java ffor the re-use of business/integratin rules.
Once again thank you all for your comments.
regards,
RINU |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 22, 2004 7:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| RINU wrote: |
| My concern is more from a code re-use perspective. As mentioned above, we have a lot of complex business/integration rules within each integration points that need to be used while we apply transformations to data. The project has a very clear separation between business and integration tier. But there is an opportunity to re-use lot of process/business rules from the business tier in the integration tier. My concern is whether we will end up in 2 implementation of the same rules, one in business tier in Java and the same in integration tier in ESQL for the benefit of WBI tool. My concern is also regarding the redundant maintenace in both places in future. |
I don't see what you're describing as having a clear separation between business and integration tiers.
If you're rewriting business logic, or using business logic (code) in the integration tier, then you don't have a separation of functions.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| MQGuy2000 |
| Posted: Thu Jul 22, 2004 7:37 am Post subject: |
|
|
Centurion
Joined: 20 Jul 2003
Posts: 131
|
In our previous application our J2EE appliation communicated with a C/C++ application. We designed our integration layer coded the data transformation rules ourselves. Ofcourse it was not a very big application.
Unless the J2EE application relies a lot on the mainframe app for either functionality or data, we can design the J2EE application to isolate and encapsulate the business rules in a set of classes.
It also depends on the budget and time.
WMQI is an expensive tool but its relatively quicker solution. Developing your own solution needs time to design/develop and test.
My 2 cents. |
|
| Back to top |
|
|
| RINU |
| Posted: Thu Jul 22, 2004 8:02 am Post subject: |
|
|
Newbie
Joined: 21 Jul 2004
Posts: 6
|
| Quote: |
If you're rewriting business logic, or using business logic (code) in the integration tier, then you don't have a separation of functions.
|
May be business rules is not the right term for the kind of code.. ..but there is a cetain code base that could be re-used in business tier and integration tier.
I will try to explain.
The system will be installed in each business location (client, presentation, business tier) and data from all business locations gathered and centrally processed (integration tier) to be fed to enterprise systems.
1) Validation/routing kind of
The front end (client/presentation/business tier) will use it for validation while user interactions and back end central integration engines will use it to route data processing while creating feeds to enterprise systems.
2) Derivatives
There are cetain calculation formula kind of code base (such as totals etc) which is used to display to user in front-end and same formulas applied at integration tier while feeding enterprise systems.
regards,
RINU |
|
| Back to top |
|
|
| JLRowe |
| Posted: Fri Jul 23, 2004 2:18 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
Have a look at the may announcements for WSAD integration edition 5.1 and WAS foundation. Business rules are catered for explicitly with business rule beans.
As for WAS/J2EE vs WBIMB, I am moving away from MB as it simply does not have the robustness and functionality of J2EE. The only thing I used MB for now is legacy formats, everything else is done in WAS. If message broker does not get on the J2EE bandwagon soon, it will quickly become an irrelevance. |
|
| Back to top |
|
|
| PGoodhart |
| Posted: Fri Jul 23, 2004 5:42 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
Reality:
Java/J2EE/WAS/JMS... will eventually be replaced by some other trendy, more-functional programming language, that's just the way it is... You can keep slapping specifications and implementations on top of it, but every piece of code is eventually headed for the scrap heap. Don't get me wrong I actually like Java, but you can't treat a programming language like a religion. (They have a tendency to colapse under their own weight. See C, C++, Cobol, Visual Basic, etc...)
Suggestion:
The message broker will allow your Java apps to be leveraged in a totally platform and programming language independent manner. Build a function (not an application) and use it as long as it continues to function. If next year something else comes up then you don't need to reinvent everything, just point the message to a new handler and use the message broker to format it and route it. That is what the broker was meant to do. This results in total seperation of business logic and messaging logic and is what people have been trying to get across. Build ALL of your business logic in Java in a modular approach and then use MQ and the broker to send messages between the various business modules.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jul 26, 2004 5:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jlrowe wrote: |
| As for WAS/J2EE vs WBIMB, I am moving away from MB as it simply does not have the robustness and functionality of J2EE. |
I can think of several ways to cause J2EE applications to have significantly less robustness than a broker.
Poor design is poor design, it doesn't matter what platform and language.
As for functionality, ESQL and Java are both Turing complete. Ergo, they have exactly the same functionality. Ease of implementation is a different criteria than functionality - and ease of implementation is solely a function of the skillset of the individual doing the implementation.
Java and J2EE are not magic bullets, nor do they really represent "best practices". If they did, there would not be nearly so much work being done to explain and prevent anti-patterns.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
