MQ/Soap question

[Moscow Mule]

The premise;

Software firm have several versions of core banking app.

One, which is old and AS400 (i series/i5/whatever its called this week) based and has it's APIs exposed via MQ (send the correct string, the APIServer picks it up and inserts into database (assuming valid transaction etc).

Two, which is new and Websphere based (with an i5 back end) and has it's APIs exposed via SOAP (apparently it's a cleaner way of doing things ) - old MQ APIs are not available.

The problem;
Bank do not want to re-develop satellite systems to use new SOAP architecture.

The question;
How hard would it be to create a process that reads a new MQ queue (probably on the same server that hosts the SOAP interface) and converts the format to a SOAP message (assuming you know the format of the MQ based message)?

Not being a C, java (or anything else useful these days) programmer I'm a bit clueless as to how long this would take or how effective this would be.

 

[TheFaQQer]

IIRC there are a range of integration hubs that can do this as standard.

Oracle Interconnect can do it, so I would expect there to be plenty of alternatives out there

 

[DimPrawn]

BizTalk 2006 can do this for you. It has a MQ Series Adapter in the box and speaks SOAP like a native. Cheap as chips too.

 

[Moscow Mule]

TVM gents.

 

[basshead]

Its not hard - to do it on WebSphere in J2EE you would set up a Message Driven Bean hanging off the new MQ Queue and then build a new SOAP request using Axis. This would be able to be done transactionally.

Proof of concept would take no more than a couple of days for an experienced Websphere/J2EE bod. Full implementation would depend on how many services, intricacies, non-functional requirements, performance required etc etc.

HTH

 

[themistry]

BizTalk 2006 can do this for you. It has a MQ Series Adapter in the box and speaks SOAP like a native. Cheap as chips too.

BizTalk is overkill for this, and not cheap...

If all you need to do is read from a queue and convert to a SOAP request, a simple java/c# message bridge ought to be the answer. That is surely 1 weeks work with testing for any c#/java developer.

If there are security considerations (i.e. masquerading the credentials from the queue into the SOAP interface) or that the queue is Asyncronous while the SOAP interface is more than likely Syncronous, some more work would be needed.

Hope that helps,
TM

 

[DimPrawn]

BizTalk is overkill for this, and not cheap...

If all you need to do is read from a queue and convert to a SOAP request, a simple java/c# message bridge ought to be the answer. That is surely 1 weeks work with testing for any c#/java developer.

If there are security considerations (i.e. masquerading the credentials from the queue into the SOAP interface) or that the queue is Asyncronous while the SOAP interface is more than likely Syncronous, some more work would be needed.

Hope that helps,
TM

If the messages are important you'll want a solution that is resilient. If your C#/Java code crashes or the power goes after reading the queue, you've lost messages. With BizTalk, you get guaranteed delivery, transactional control and retries etc.

Any BizTalk implementation can be replaced with some adhoc C#/Java but it will not be resilient.

PS. BizTalk 2006 R2 Branch Edition: $1,800

 

[basshead]

If the messages are important you'll want a solution that is resilient. If your C#/Java code crashes or the power goes after reading the queue, you've lost messages.

Any coder who can't make that interface transactional wants shooting.

 

[Moscow Mule]

Any coder who can't make that interface transactional wants shooting.

There's going to be a lot of dead coders in the city.

Cheers for the help guys