Hi there. We are currently using I.S. 4.6, ES 5.0.1. and WebSphere for Java/J2EE applications. We are planning an upgrade/migration to v6…eventually.
What are the recommendations on messaging between a J2EE app server and webMethods ? We have considered the following options:

1. Use the Broker Client API to publish/wait webMethods docs, and have ES subscribe to these docs, gather data, and return response doc.
2. Create xml request msg and send to I.S. via Http(s) post, IS receives xml, gathers data, returns xml reply.
3. Pass messages via queues (eg. Mq Series, JMS).

I’m thinking option #2 fits better with the v6 architecture. We have some new projects starting up and we want to make our recommendation. I know that either approach will work in v6 but is anyone doing this now ? Any comments ?

Regards,

Wayne

1. Don’t do this one. More coding than it’s worth and ties you to wM Broker.

2. A couple of projects I’ve worked on do this. This fits with the IS approach regardless of IS version–e.g. this isn’t a thing that is new to 6.

3. A couple of other projects I’ve worked on did it this way with MQSeries. Use this if you’ve got a queuing infrastructure in place and have the support staff/skills. The messages should be XML.

My two bits.

Hi Rob, thanks for the comments. Last year when we started solution design, we were debating whether we should go with option #1 or #2, and decided to go with option #1 for the following reasons:

1. We are using ES adapters to gather data from our legacy systems and if we used option #2 then we would be impacted by the (slow) IS/ES bridge. Since the requesting client is a web app, performance is very mportant.

2. The webMethods PS consultants we had on-site were part of this debate and also recommended option #2.

For the new projects just starting up we will likely go with option #2 since it fits better in the v6 architecture.

Live and learn I guess.

Note: the project we started last year is not in production yet so we may be able to go back and use option #2 instead of #1.

Thanks again for responding to my posts…

Regards,

Wayne

…sorry…I meant to say “The webMethods PS consultants we had on-site were part of this debate and also recommended option #1”…

Wayne

I would offer that unless you specifically need the pub/sub facilities of the Broker, or an adapter that is only supported by the Broker, then use only IS.

The skeptic in me would say of course the PS guys recommended using the Enterprise API–it locks you into their platform.

Another option for your WAS apps would be to use the XML adapter of the Broker instead of using the API. This decouples your WAS apps from the broker, enabling the switch to IS (or some other tool) in the future. Or the EJB adapter. There are a few options you can explore before dropping to the API.

Thanks Rob for the additional thoughts.

Regards,

Wayne

Option #4 will be to run the WmJBoss package with IS 6.0.1 and load your EJBs into an IS package. They will be hot deployed into JBoss and communication with the EJBs will be in-JVM.

A preview of WmJBoss is being organized now. Stay tuned for details.

For communication from your J2EE app to the broker, create a Session EJB which internally makes use of the broker API. Regardless of what the future holds in store you can change the Session EJB. The broker API is really easy to implement so it shouldn’t take much time at all.

For communication from wM to your J2EE app, use the EJB adapter.

Just a thought.

Rgs,
Andreas

using broker API inside ejb is usually considered not the best practice in j2ee since broker API is not thread safe. in one instance i saw the weblogic server got brought down because of the thread created by the broker API.

LS, can you elaborate? AFAIK the broker API is indeed thread-safe (all the adapters that use the API are multi-threaded). Which thread to you speak of?

amundin mentioned to use broker API inside ejb. when using broker API, one needs to create a new broker client. when a broker client is created, a new thread is created. if you use a thread monitor, you will see that. j2ee spec strongly discourages ejb managed thread. all thread should be managed by the j2ee server.

in one case, an ejb used broker API to exchange doc with a broker and it managed to bring down the weblogic server. but in other cases this worked perfectly fine. after that crashed, it was mandated not to use broker API inside ejb after all.

Thanks for the info. That’s the thread I thought you might be referring to but wanted to make sure. Thanks for sharing some good experienced-based info.

If one wants to use EJB to connect to Enterprise, then the EJB adapter would be the way to go.

Guys,
We have used SOAP-RPC to communicate between the IS and the JBoss 3.0.4 server. The JAVA app server contains session beans with published methods, can take in parameters or xml docs to transact on.
We are using Axis on the Jboss server to enable the webservice and a web service connector on the webMethods end. to facilitate connections.
Its working great!!!
Note :
The XML docs we use for the relay of information are not very big and this architecture inside the corp firewall.