Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:
You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.
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.
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.
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.
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.
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.
Leave a comment: