| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQSeries vs. SOAP |
« View previous topic :: View next topic » |
| Author |
Message
|
| BigT |
 Posted: Mon Aug 08, 2005 1:17 pm Post subject: MQSeries vs. SOAP |
 |
|
Newbie
Joined: 08 Aug 2005
Posts: 2
|
| My company is trying to replace an MQSeries application with SOAP ,saying its more cost effective(expensive license fee) and MQSeries is not scalable?! I am not sure if I can agree with that. I am an MQSeries developer but do not have the knowlege of SOAP technology. Can someone shed some light what are the pros and cons of replacing MQSeries with SOAP? |
|
| Back to top |
|
 |
| vennela |
| Posted: Mon Aug 08, 2005 1:37 pm Post subject: Re: MQSeries vs. SOAP |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| BigT wrote: |
| MQSeries is not scalable?! |
I guess who cannot pay for licence are not supposed to talk about scalability. Definitely MQ is scalabale.
Without knowing what your application does it is hard to tell what the pros and cons are.
Also SOAP needs a transportation, which can be HTTP or JMS. If they use JMS, they still need MQ. If they use HTTP, then they will still need some app server (or IIS) or something like that and they still have to pay. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 08, 2005 1:48 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
SOAP is not good for larger messages.
I wouldn't personally try and run anything bigger than about 20mb.
It's also synchronous, which means that the server has to be up all the time.
It's also request/reply which means the network has to be solid, or the request has to be retried.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| BigT |
| Posted: Mon Aug 08, 2005 3:34 pm Post subject: |
|
|
Newbie
Joined: 08 Aug 2005
Posts: 2
|
Thank you all for the prompt response 
In response to vennela question about what the application does? Here is an excerpt from the current specifications....
| Quote: |
| Our in-house web service application consists of a .NET-based Web service component that allows user to access our system via a Web service protocol (XML, SOAP, WSDL, DISCO). This allows remote applications to submit EDI transactions to our system via SOAP-protocol requests. The in-house web services receive SOAP messages via its Web server. The Application Server responds with a SOAP Message over HTTP. This allows easy interactions between application programs on different platforms |
Is that fair/correct to say SOAP is more scalable than MQSeries?
One thing I like MQSeries is that MQ applications can utilize the message id features to ensure the integrity of the communications(request/response). How does SOAP handle it in this area? |
|
| Back to top |
|
|
| ashoon |
| Posted: Mon Aug 08, 2005 4:15 pm Post subject: MQ is more scalable |
|
|
Master
Joined: 26 Oct 2004
Posts: 235
|
for a couple reasons ...
HTTP is a synchronous call - which means your application code has to wait for a response before it can continue processing whereas asynchronous applications put a message and continue processing - this is great for paced applications where one server is alot quicker than the other i.e. a zOS server can create requests quicker than a WINTEL box can handle them... therefore in this scenario you don't tie up the zOS app. waiting for the WINTEL to process.
Also MQ channels are very effecient at moving data compared to HTTP with a much higher reliability... performance reports are here
http://www-306.ibm.com/software/integration/support/supportpacs/product.html#wmq
Finally you should look at the benefits of asynch. with a big one being that the application need not be alive for processing - this loose coupling means that you can take apps. offline for maintenance etc... without having to worry about the overall process going down (and not have to notify other applications/partners).
Hope this helps... |
|
| Back to top |
|
|
| csmith28 |
| Posted: Mon Aug 08, 2005 4:48 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
I've never really heard of SOAP but here's a list of most of the other Messsaging application that have over the years been identified as the software that will replace MQSeries:
AMQ – Open source message queueing system that provides the same functionality as IBM’s WMQSeries compatible with C, C++, C# and Java that supports Pub/Sub. Researched by Sun, RedHat and Novell it’s supposed to be a Kernal add on.
JbossMQ - free implementation of the Java Messaging Service (TM) (JMS)
specification. Based on the 1.0.2 JMS specification, JBossMQ is a clean
room, pure java implementation. A synchronous and asynchronus messaging that supports Publish/Subscribe model for collaboration between the various participants of a distributed, e-business application. JMS, through JBossMQ component, plays a central role in the J2EE-based "Web operating system" provided by the JBoss.
OSMQ - Open Source Message Queue is an advanced, pure Java, asynchronous message router, message broker and message middleware framework developed by MQue Systems. OSMQ was designed for high performance, high reliability, and ease of use, with an interface that is less complex than JMS. OSMQ supports a publish-subscribe and point-to-point message architecture, employing a queue-based store-and-forward model of message distribution.
ActiveMQ - ActiveMQ is an open source high performance Messaging Fabric consisting of a scalable cluster of Message Brokers and a complete JMS 1.1 provider which integrates seamlessly into J2EE containers, light weight containers and any Java application.
Proteus - Proteus is a framework for creating messaging applications, and a message broker built upon that framework. Proteus has adapters that allow databases, message queues, ftp servers, email and other message sources and sinks to be addressed in a simple, uniform fashion. (GPL)
OpenEAI - The purpose of the OpenEAI Project is to discover and document the controlling dynamics, principles, and practices of enterprise application integration and to present, implement, and promote those findings. The OpenEAI Project presents findings in the form of the OpenEAI methodology and OpenEAI software for implementing integrations. (LGPL)
BIE - Business Integration Engine (BIE) is designed to help organizations exchange data created in different applications on various platforms with partners, suppliers, and customers in order to streamline processes and improve efficiency. Includes a map builder and dashboard, supports multiple protocols SOAP, EDI X12, HIPAA etc. (GPL)
OpenAdaptor - openadaptor is a Java/XML-based software platform which allows for rapid business system integration with little or no custom programming. It is highly extensible and provides many ready-built interface components for JMS, LDAP, Mail, MQ Series, Oracle, Sybase and MSSQL Server as well as data exchange formats such as XML. New components are regularly added. (BSD based?)
Tambora - Tambora a leading edge Enterprise Application Integration (EAI) tool specifically created for the printing and publishing industries. Tambora can adapt to any organization's internal processes and requirements. At the heart of Tambora is a world class workflow engine which will allow Tambora to seemlessly integrate into any existing enterprise. (Mozilla based license)
XMLBlaster - XmlBlaster is a publish/subscribe and point to point MOM server which exchanges messages between publishers and subscribers. The message is described with XML-encoded meta information. Messages may contain everything, GIF images, Java objects, Python scripts, XML data, a word document, plain text. Communication with the server is based on CORBA (using JacORB) or RMI or XmlRpc, clients are free to choose their preferred protocol. Other protocols like email, socket or SOAP may be plugged in. (LGPL)
OpenQueue - OpenQueue is an open protocol for publish-and-subscribe message queuing. This enables language-independent, loosely-coupled, asynchronous communications between applications running on different machines.
Elemenope -elemenope llows one to easily create a large scale multi-platform application to do messaging or transaction processing. It abstracts away all of the connectivity issues when dealing with or designing such a project. It uses Java Message Service [JMS] for messaging, and currently utilizes IBM MQSeries [WebSphereMQ] for a Message Oriented Middleware [MOM]. It also has built-in mainframe connectivity classes for use when connecting to a mainframe running IBM MQSeries with the IMS Adapter or IMS Bridge. elemenope has been in development for over three years. It and some of its precursors are currently in production use within several companies large and small. (GPL)
MessageForge - The framework was conceived and created during the development of an online trading system for a major bank on Wall Street. The project made heavy use of TIBCO/RV. Features include transparent message definitions, automatic generation of JAVA classes from XML definitions, a type-safe messaging JAVA API, run-time message validation, services to marshal/unmarshal messages, uniform message definitions across all tiers and high performance. (BSD)
SolAce - Secure Transport of Transactions across any network. Reliable delivery, tamperproof and encrypted messages, and signed receipts proving message delivery to the originator of the message. Never lose an e-mail message or FTP transaction again. Integrates seamlessly with almost all FTP servers, EDI gateways, and claims adjudication systems. Transports any type of file securely and reliably, not limited to HIPAA or EDI transactions. Secure (SSL) web-based administration and remote mailbox access. Security features to foil hacker reconnaissance and attacks. (GPL)
it.gim - it.gim is an Enterprise Application Integration tool, which includes reliability, scalability, security, error tolerance, availability and platform independence. (BSD based?)
jEngine - JEngine uses JBoss’ core for database persistence, transaction support, messaging and integration of components based on Java Management Extensions (JMX) specification. JEngine’s JMX components currently include TCP/IP HL7 2.x client and server components. Due to the adoption of the HL7 2.x standard within healthcare organizations and the singular focus of the HL7 organization on the interface requirements of the entire health care industry, these components were the first to be developed. Internal JEngine messaging uses the Java Message Service (JMS), which provides a reliable means for the asynchronous exchange of data within the healthcare enterprise. The JEngine core utilizes standards-based XML/XSLT transformations for message structure manipulation. (LGPL)
S-integrator - A service-oriented integration server that hosts Service Stores which authorize, monitor, manage and run services while making them available through web services, HTTP and other protocols. Included listeners and inbound adapters support address banning, content filtering and a virus detection filter. Included outbound adapters integrate databases, mainframes (APPC), web servers, FTP, mail and other technologies. Administration is performed using a web browser or cell phone that accesses the embedded web server. Service Flows provide process automation and hot deployment is supported. S-integrator is single-source, small footprint and only requires JRE 1.2 and a database with JDBC driver.
Mule - Mule is a simple yet robust and highly scalable component broker and services framework. Mule is a light-weight, event-driven component technology; it is highly scalable, using ideas from SEDA; designed around the ESB (Enterprise Service Bus); components managed by mule can be Beans, EJBs, IoC3 compatible components, Servlets, POJOs, etc; Mule builds on existing best-of-breed lightweight containers and gives you the option to pick an choose which framework components you wish to use and connectors for JMS, HTTP, TCP, SMTP, POP3, FILE, XML-RPC and VM.
JyRetic - Retic was initially developped in Python, but an EAI server means a connectivity with as many protocols and products as possible. Python, lacks connectivity with databases and MOMs. That is why Retic was translated to Jython : JyRetic, giving it JDBC and JMS connectivity.
NaradaBrokering - NaradaBrokering is a distributed messaging infrastructure and provides two closely related capabilities. First, it provides a message oriented middleware (MoM) which facilitates communications between entities (which includes clients, resources, services and proxies thereto) through the exchange of messages. Second, it provides a notification framework by efficiently routing messages from the originators to only the registered consumers of the message in question. NaradaBrokering aims to provide a unified messaging environment that integrates grid services, web services, peer-to-peer interactions and traditional middleware operations.
xBus - The xBus is a central EAI (Enterprise Application Integration) system that emphasizes Routing and Transformation.
Orbeon Integration Suite - The Orbeon Integration Suite is modular XML middleware for SOA-based business integration. It includes an XML Server for industrial strength XSLT processing, a Presentation Server for composite web apps using XForms, BPEL server and a Eclipse-based Studio.
1060 NetKernel - NetKernel is an XML Application Server built on a Microkernel with a functionality set including Web-service SOAP1.1, SOAP1.2 and REST infrastructure, XML language runtimes, powerful libraries of XML technologies, developer tools, documentation and a web management interface.
Conductor DocSOAP XDK - Commerce One Conductor DocSOAP XML Development Kit (XDK). This Open-Source Java Web Services SOAP, and XML Development Kit provides an effective and efficient way of developing Web services solutions where the emphasis is on making it easy to do document Style SOAP. Commerce One tests show that the DocSOAP XDK supports more features of the XML schema and processes larger XML documents over twice as fast as any other solution available.
connectorWorks - an open-source framework for implementing XML document-centric interactions with an enterprise information system (EIS). Works with JAXM, JAXP, SAX, DOM, JAXB, XSLT, XML filters/pipeline, and JMS messaging (Interoperability. Leverages JMX-based management and monitoring capabilities for EIS interactions. Supports the transformation to/from a canonical business markup language like OAGIS BOD using XSLT and SAX filter chains to/from internal EIS data structures/APIs such as an SAP R/3 IDoc
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| klamerus |
| Posted: Sat Aug 13, 2005 7:41 pm Post subject: Huh? |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
It sounds to me like a question of requirements.
MQ supports messaging and queuing. It is extraordinarily scalable.
SOAP is for messaging only and is really for request/response. It's only a specification and a framework in which to run (like a web server or application server as you said, but also the code behind that).
It sounds to me like their real driver is the licensing, and that's fair. MQ is expensive if you don't need all the things it provides. If you do, it'll cost you several times as much as the license in devl/test time.
SOAP is synchronous, which is good. One issue we have here with the applications sending our server messages over MQ is data validation.
SOAP is "big". It's best designed for text, which is usually sent around in UTF-8, but you can send encoded binary (then it gets really "big").
SOAP (and HTTP) are pretty broadly supported with a variety of cheap to expensive tools. It's also "open".
I thought that with MQ 6 there was a SOAP API, but I haven't downloaded it yet to see.
SOAP works over HTTP (port 80) or HTTPS (443), so it can tunnel well.
There are very, very few examples of SOAP being used for complex data upload/exchange though. Although we're working on replacing an MQ-based client library with a SOAP API (well augmenting it), it is really more oriented towards simple request/response messing.
The biggest differentiator is the queueing. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Aug 14, 2005 6:20 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Finally there is the performance aspect ?
Most (I did not say all) SOAP message payloads are XML.
This can be a problem for performance if you do not have a dedicated XML processor in your environment.
Just think of the cost of parsing a DOM vs simple record new line delimiter with record identifier in 1st x positions....
Enjoy |
|
| Back to top |
|
|
| klamerus |
| Posted: Sun Aug 14, 2005 7:26 am Post subject: Size does matter |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
As fjb just indicated, there's not only the aspect of handling the data in DOM (which requires a full parse), but the size of binary data.
We were researching this a bit as we need to pass around some files of .5 - 1 MB in some uploads via SOAP and the general into seemed to be that if you base64 encode the data (which is what you need to do to include a binary document in XML for SOAP) it expands the size by 1.33 as an average and sometimes as much as 2 times.
That could get pretty painful quickly. On the other hand, the emerging standards for passing around binary SOAP (DIME, WS_ATTACHMENT) aren't really soup yet. So, you have to make your choices.
Documentation on handling binary data in SOAP (uploading) is very, very sparce as well. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sun Aug 14, 2005 8:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In fact, in general if you are concerned about message size and performance, XML is the exact wrong choice.
The very thing that makes XML pretty darn useful - that data is "self describing" - makes it carry a significant overhead in message size. Byte for byte, tags almost always outweigh data in an XML message. And by a large factor, too. I'm not in a mathematical mood, so I won't make any specific claims.
And from a business to business communications mode, HTTP is almost (but not quite) the exact wrong choice as well. It is stateless, it is not built ground up for security, it is not built from ground up for large or long-running communications, etc. etc. etc...
All of this is why some people got together and designed BEEP.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| klamerus |
| Posted: Sun Aug 14, 2005 9:55 am Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
Ah BEEP. Now there's a name I haven't heard in a long, long time.
Ahem.
Anyway, Jeff is right regarding size. The best use for SOAP is a request/response architecture, where what you want is a synchronous hand-shake. It makes a nice alternative, open frame for an API (so to speak). |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Aug 14, 2005 3:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
I would even go further ..... but this is just my own private opinion... and implicates in no way any fitness for use... use at your own risks...:
The best use for SOAP is in a scenario where you need automatic discovery of a specific service and a way to invoke it given a known service registry.
If your service endpoints are known in advance there are many possibilities that might come easier than SOAP. |
|
| Back to top |
|
|
| klamerus |
| Posted: Mon Aug 15, 2005 3:29 pm Post subject: |
|
|
Disciple
Joined: 05 Jul 2004
Posts: 199
Location: Detroit, MI
|
Ah, well I wouldn't go that far.
Our exprience is that discovery (ala UDDI) is greatly oversold - and not automatic. The sales point for us is not needing vendor proprietary libraries (= cost) on service consumers and fewer technologies to need to train people on the use of (= cost and time).
There are other benefits, but those are the biggest for us at this time. |
|
| Back to top |
|
|
| RebeccaBarnes |
| Posted: Mon Apr 01, 2024 2:42 pm Post subject: Re: MQSeries vs. SOAP |
|
|
Newbie
Joined: 13 Jun 2022
Posts: 3
|
| BigT wrote: |
| My company is trying to replace an MQSeries application with SOAP ,saying its more cost effective(expensive license fee) and MQSeries is not scalable?! I am not sure if I can agree with that. I am an MQSeries developer but do not have the knowlege of SOAP technology. Can someone shed some light what are the pros and cons of replacing MQSeries with SOAP? Or there is a third option - contact the professionals from the Cogniteq team who will help me develop new software for myself, to suit my needs. |
Replacing an MQSeries application with SOAP requires a number of considerations, each with its own pros and cons. Here's a breakdown to help you evaluate the solution:
Pros of replacing MQSeries with SOAP:
Cost-effective: SOAP is often considered more cost-effective due to its open source code compared to MQSeries, which can require expensive licensing fees.
Compatibility. SOAP is widely supported across platforms and languages, making it easy to integrate with various systems and technologies.
Internet Communication: SOAP uses the HTTP/SOAP protocols commonly used for Internet communication, allowing for easier integration with web services and APIs.
Standardization: SOAP follows standardized protocols and formats, making it easier to understand and implement compatible solutions across different systems.
Disadvantages of replacing MQSeries with SOAP:
Scalability. While SOAP can handle large volumes of data and queries, MQSeries is known for its robust scalability and reliability, especially in high-performance and mission-critical environments.
Performance: MQSeries is known for its high-performance messaging capabilities, providing low latency and high throughput, which cannot be achieved using SOAP in certain scenarios.
Complexity. SOAP-based solutions may require additional development effort and complexity compared to MQSeries, especially if the existing application relies heavily on MQSeries features and capabilities.
Integration of legacy systems. If your existing infrastructure and systems rely heavily on MQSeries, migrating to SOAP may require significant changes and integration efforts, leading to potential compatibility issues and failures.
Ultimately, the decision to replace MQSeries with SOAP depends on various factors such as budget, performance requirements, existing infrastructure and long-term strategic goals. It is important to carefully evaluate these factors and consult with MQSeries and SOAP technology experts to make an informed decision that best suits your organization's needs and goals. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Apr 01, 2024 2:55 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2497
Location: Melbourne, Australia
|
I'm not sure how MQ and SOAP can be directly compared. SOAP is a message protocol using enveloped XML. MQ is a general purpose data queueing and transport method.
Usually SOAP is done over HTTP, but its quite valid to do SOAP over MQ, to take advantage of the additional QoS and capabilities MQ.
_________________
Glenn |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
