14-12-2012, 06:48 PM
webMethods Vs TIBCO
webMethods Vs TIBCO.docx (Size: 192.59 KB / Downloads: 25)
Hub and Spoke Vs Bus Architecture
WebMethods is Hub and Spoke Architecture and Tibco is Bus architecture.
Hub and spoke is some thing where you have a centralized server, and all the data lines extending from it like spokes whereas
Bus architecture is like a data bus connecting and serving data to all the applications connected to it. One has to imagine many practical scenarios before one can perfectly avoid confusion between the two.
2. Broker Vs EMS
WebMethod has a product called Broker Server. This is their way of implementing JMS ‘kind of stuff’. I say ‘kind of’ because it can be used easily only with webMethods Integration server. Other data can be exchanged only through some extra wrappers/adapters.
On the other hand Tibco came out with a complete 100% JMS implementation which they say is written in C(and they also claim that because its written in C, its faster – I have doubts). The product is called EMS. One can create queues and publish and subscribe to it.
3. Document Vs XML
WebMethods internally stores each structure as a document. The broker can understand only documents. This means that if you have an XML, you’d first need to create a document out of it and then will be able to use it on their brokers(off course they provide API for conversion)
Tibco is quite good at these. You can send and receive just any XML or data by defining a schema. Hats off on that.
4. Packages Vs EARs
In Web methods, each module or project is represented as a package. Each package may have functions called flow services. These can be invoked by other packages residing on the same Integration server. A package can contain their own flow language code (which is in XML). This gets converted internally into Java code. A Java service will have pure Java code.
Tibco deployment is more like a Enterprise archive (EAR). You need to pack all your compiled code and then deploy to the server (called Business Works Engine).
This can sometimes be problematic because we have to have our own version control system, whereas web methods have it inbuilt.
5. Integration Server Vs Business Works
Webmethods has a centralized server where all the code is deployed. This is called an Integration Server. An integration server will also contain their built in services.
Tibco on the other hand has the product called BusinessWorks. EAR files are deployed on the BW engines to work out the trick.
At the end, I feel both are nothing but tweaked tomcat servers!!!
6. Services Vs Pallets.
A service in WebMethod, be it built-in or user built is a small function of a package (think of it as a class). There is a set of complete startup utilities which Web Methods provides. These are called Built-in Services.
Tibco has a concept of pallets. These pallets are also some small function. But the implementation is done in just one city!
7. Triggers Vs Queues
Whenever a data comes to the Broker from an Integration server or rather say, webmethods Broker receieves a Queue, then a Trigger is called. These triggers in WebMethods do nothing but call another service[built-in or custom built].
JMS implementation of TIBCO called EMS does a delivery of the message(JMS message -Remember it can be anything!) to all the clients who have subscribed to the Queue.