MQSeries.net :: View topic - Troubles Implementing the Service Gateway Pattern in WMB 6.1

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Troubles Implementing the Service Gateway Pattern in WMB 6.1

Goto page Previous 1, 2

Troubles Implementing the Service Gateway Pattern in WMB 6.1

« View previous topic :: View next topic »

Author

Message

mqjeff

Posted: Wed Oct 13, 2010 7:03 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

WSDL-Less SOAP is not SOAP. SOAP requires the WSDL to define the interface that the Consumer and Provider are tightly coupled to.

ccrandall

Posted: Wed Oct 13, 2010 7:37 am Post subject:

Acolyte

Joined: 23 Oct 2008
Posts: 52

Requiring a Message Set based off a WSDL in broker, however, is unnecessary if DataPower is already performing the validation. This is what I mean by a WSDL-less SOAP node.

While HTTP nodes can satisfy this need, there are other features of the SOAP nodes that provide advantages and convenience.

mqjeff

Posted: Wed Oct 13, 2010 7:38 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Best bet is to file a requirement detailing the advantages you'd like to see added to the HTTP nodes.

lancelotlinc

Posted: Wed Oct 13, 2010 7:39 am Post subject:

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

vmcgloin wrote:

Hi,

I am not qualified to comment on the previous post, but I am curious about your correlation problems with the Http Input node.

I use the HTTP.RequestIdentifier in a similar scenario. When you say that you perform some additional logic on the SOAP ReplyIdentifier (that does not work in the Http case) I get the impression that you are making things more complicated than they need to be. What 'additional logic' and how do you use it for correlation?
You should be able to store and reinstate the value (in a header/utility field or if necessary out to a queue). to get this working with an Http node.

Vicky

Edited to add: Actually, I do disagree with the previous post - I have and do use broker in high TPS, high variance conditions (by your definitions) and think that broker is more than capable of being used as a web services gateway itself... I am just waiting for someone with better skills to reason with you

Hi Vicky,

Thanks for your comments. Actually, the architecture I am advocating is precisely what was advocated by IBM Global Services in this document:

ftp://ftp.software.ibm.com/software/dw/wes/hipods/JPMC_report_26Oct.pdf

Quote:

...sending data to the WebSphere BI message broker for transformation through the WebSphere BI jText adapter over WebSphere MQ. The customerâ€™s main concerns were the performance of the adapter, scalability of the solution, and target transaction rate â€“ 25 million transactions per day.

In this case, the jText adapter would be replaced by a Web Services Gateway. fjb_saper's suggestion that the gateway could be within an Execution group is a valid one, although the separation of concerns advantage would be partially negated with this implementation.

Quote:

The jText adapter consists of a data handler and an adapter. Data handlers are a generic mechanism for converting an incoming bit stream into a WebSphere BI business object. Data handlers must be implemented in Java; the WebSphere BI Adapterâ€™s data handlerâ€™s framework interface dictates the methods that must be implemented by the data handler developer. Data handlers can be developed using any Java 2 compliant development environment, including WebSphere Studio Application Developer.

In my suggestion, I was promoting a generic Web Services Gateway implementation using Tomcat and mod_jk. The SOAP output would be connected through Java to ESB using MQ and the request-response EAI pattern.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER

mqjeff

Posted: Wed Oct 13, 2010 7:45 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

lancelotlinc wrote:

vmcgloin wrote:

Quote:

In this case, the jText adapter would be replaced by a Web Services Gateway.

Yes. A WebServices Gateway implemented in Message Broker, and not implemented in Crossworlds or on the non-performant and non-scalable JText Adapter.

More than one reason it's no longer supported!

lancelotlinc

Posted: Wed Oct 13, 2010 7:52 am Post subject:

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

Excellent point, mqjeff, which brings us full circle to the original problem.

I believe everyone commenting on this post, including me, would prefer an all-in-one solution with few moving parts.

The challenge faced by ccrandall for the last 15 months, and yet to be solved, is how to do with scalability of 70 patterns.

Shall we elevate the discussion to address ccrandall's root issue:

Code:

Web Services Gateway in WMB with 70 patterns scalable to many transactions per second.

If my customer had a problem for going on two years, and he reached out to me, I would suggest a workable solution and see it through to fruition.

_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER

ccrandall

Posted: Wed Oct 13, 2010 7:55 am Post subject:

Acolyte

Joined: 23 Oct 2008
Posts: 52

mqjeff wrote:

Best bet is to file a requirement detailing the advantages you'd like to see added to the HTTP nodes.

Yes, we've been in contact with IBM about what we'd like to see. Not sure if this will end up as a SOAP or HTTP node enhancement or if it'll make it at all.

When we worked with a consultant from IBM we tried to make a super-generic WSDL that would work for all well-formed SOAP messages and then create the Message Set from that. We were tantalizingly close with that solution, but we just couldn't get it to work 100%.

With the HTTP node, it was very easy to put a compute node behind the HTTP Input and convert to SOAP. However, we were already supporting regular HTTP traffic in our framework, so we wanted to use the Reply Protocol to differentiate. Unfortunately, even when explicitly setting the Reply Protocol from SOAP_HTTP to SOAP_AXIS2 (?) the change wouldn't take.

So, from our standpoint just being able to tell the SOAP Input node to not require a Message Set would be the easiest route as using HTTP would require a lot of code changes or the ability to change the Reply Protocol.

Is that the right way to do it for everyone, I'm not sure... I can only speak to what would be the easiest solution for us.

mqjeff

Posted: Wed Oct 13, 2010 8:02 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

lancelotlinc wrote:

If my customer had a problem for going on two years, and he reached out to me, I would suggest a workable solution and see it through to fruition.

I agree.

There just hasn't been a solid description of the actual issue as yet with a non-SOAP node solution. The comments just made about Reply-Protocol are new, and have bearing.

And I don't have a solution off the top of my head.

fjb_saper

Posted: Wed Oct 13, 2010 9:26 am Post subject:

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

ccrandall wrote:

With the HTTP node, it was very easy to put a compute node behind the HTTP Input and convert to SOAP. However, we were already supporting regular HTTP traffic in our framework, so we wanted to use the Reply Protocol to differentiate. Unfortunately, even when explicitly setting the Reply Protocol from SOAP_HTTP to SOAP_AXIS2 (?) the change wouldn't take.

So, from our standpoint just being able to tell the SOAP Input node to not require a Message Set would be the easiest route as using HTTP would require a lot of code changes or the ability to change the Reply Protocol.

Is that the right way to do it for everyone, I'm not sure... I can only speak to what would be the easiest solution for us.

Have you tried SOAP over JMS with AXIS? Usually fired from a J2EE appserver using the JNDI defined JMS connection?

You might need to look into how to define your (JMS) endpoints but it should have distinct advantages, including the fact that you can parse directly the SOAP content of the messages using XMLNSC without ever using a message set. Reply Protocol is MQ...

Have fun

_________________
MQ & Broker admin

ccrandall

Posted: Wed Oct 13, 2010 10:24 am Post subject:

Acolyte

Joined: 23 Oct 2008
Posts: 52

lancelotlinc wrote:

If my customer had a problem for going on two years, and he reached out to me, I would suggest a workable solution and see it through to fruition.

Actually, IBM has been actively working with us on this and our lab advocate and the MB engineers have given us outstanding support on this and other issues. I believe they are looking at an easy solution to this sort of problem as I believe I'm not the only customer that's requested a similar feature. So, since this need at this time is low priority, we are able to get by with building N number of Message Sets and SOAP Nodes.

Another thing I should note is that while we had an onsite engineer from IBM helping us, his engagement was only for a couple of weeks and we had a lot of ground to cover with Message Broker + DataPower + WPS... the latter 2 technologies being fairly new to our organization and there's big demand for it.

ccrandall

Posted: Wed Oct 13, 2010 10:29 am Post subject:

Acolyte

Joined: 23 Oct 2008
Posts: 52

fjb_saper wrote:

We are evaluating SOAP over JMS, but deep diving into that subject probably won't happen for a while. Our company is relatively conservative, technology-wise, and we have a small staff working on our overall messaging strategy that includes MB, DP, WPS, iLog, WAS, etc.

In the meantime, the use of MB to create a SOAP facade for existing MQ services is a tactical solution that allows teams to get a web service set up quickly. I think we'd prefer groups right a native web service, but with hundreds of services scattered on UNIX and z/OS, that's a lot of code to rewrite!

All great suggestions. I'm glad this subject has come back up because I think a lot of people are going to go through similar issues that we've identified and there's probably multiple ways to solve this problem.

If and when I get back to tackling the web services gateway pattern again, I'll be sure to share what solution we've cooked up.

vmcgloin

Posted: Wed Oct 13, 2010 11:47 am Post subject:

Knight

Joined: 04 Apr 2002
Posts: 560
Location: Scotland

ccrandall wrote:

To get our MQ correlation ID from the SOAP Reply ID, we don't do a whole lot of additional logic. We basically take that SOAP Reply ID, determine it's length, which is 4 bytes, and then pad it with spaces to get a length of 24 (i.e. X'2020202020202020202020202020202020202020fe4567ab).

I tried the same thing with the HTTP Request ID, but I received errors. Since this exercise was timeboxed to just 2 days, I didn't do a lot of debugging and unfortunately I do not have the exact error anymore to share.

I realise that this is slightly off topic now but I do not understand why you generate the MQ correlation ID at all. Why not let MQ generate the message id in the request to the legacy system, and store the HTTP request id/SOAP reply id either in a header or if not feasible due to restrictions at the back-end, in some other temporary data store (queue or DB) then reinstate it in the decoupled reply flow, using normal message id, correl id processing? That would get the HTTP version working.
Anyway, it sounds like you have things well in hand with IBM - please let us know how you progressed when you return to it in due course.

ccrandall

Posted: Wed Oct 13, 2010 12:24 pm Post subject:

Acolyte

Joined: 23 Oct 2008
Posts: 52

vmcgloin wrote:

It's been a while and I did not write this part, but from what I recall we had to do it this way in order to maintain affinity between the SOAP request/reply. So, by using the SOAP Reply ID in the MQ correlation ID, on the reply flow we'd just take the last 4 bytes to get our SOAP Reply ID back.

I think we could've stored it in our routing data, but b/c we are converting from SOAP to MQ and then using the same logic as a regular MQ message, we would've had to do some more creative coding to know when and when not to store an additional SOAP Reply ID field. I think the way we did it was just out of convenience.

Are framework is rather complicated, so when introducing new features or changing existing ones, we try to minimize the amount of changes to the framework where possible. There may be times, such as with trying to implement the web services gateway, that we might need to make more code changes than we'd like in order to implement the feature correctly.

On a side note, one of the other architects I work with is deep into WPS and WID/WESB. Apparently WPS and WESB have a wizard for setting up service gateways... both static and dynamic. I don't think we'd switch to using WESB for this, but it's interesting that one of the 3 main ESB tools from IBM is already implementing this. Gives me hope that we'll see something similar in WMB soon.

Display posts from previous:

Goto page Previous 1, 2

Page 2 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Troubles Implementing the Service Gateway Pattern in WMB 6.1

Jump to:

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

Protected by Anti-Spam ACP