B
Bill Wood
Guest
I am not a WebSphereMQ expert, but the last time I recall looking, there is no native WebSphereMQ endpoint for REST. That is the piece you need. You need some Web Server (or something acting like a Web Server) that exposes a public REST or SOAP Endpoint for receiving messages. If you have that, then you can use OpenEdge Web Services (for SOAP) or Sockets (for REST) to send messages to that endpoint. (The fact that the endpoint itself does a WebSphere "send" is not really visible to the SOAP or REST endpoint.) One issue that you may next ask is: "Is it possible to RECEIVE messages from WebSphere into OE?". The REST/SOAP won't work here (you can do a synchronous receive, but you can't do an async one.). You could, however, take WebSphere server and have a MDB (Message Driven Bean) that listens to WebSphereMQ destinations and then used OpenEdge Open Client to call back to OE AppServer. One more thought is this: There is an existing STOMP library for OpenEdge (courtesy of dotr technologies). See bitbucket.org/.../overview STOMP has a JMS Bridge (STOMP Connect) to talk to any generic JMS provider. See docs.codehaus.org/.../StompConnect You could use ABL/STOMP to STOMP Connect/JMS/WebSphere. The architecture does have the following points to consider: STOMP is NOT JMS, so the use of messaging in the ABL will need to change in small ways. (e.g. there are fewer message types, and there are limitations on message size and QOS that are different from JMS generally and SonicMQ in particular. The StompConnect service does need to be a running process that you connect to. While it does not need to be local on every machine, Iwould generally try to keep it co-located with each AVM.
Continue reading...
Continue reading...