Hussain Fakhruddin, India Weblog

I’ve been getting a lot of hits and requests to post something about Webmethod to Tibco migration. As discussed in many of my previous posts, Tibco is highly marketing is products and particularly asking organizations to migrate from WebMethods!  You should see the way Tibco sales guys talk! They are technically convincing!

SO lets try to discuss if its really a good decision to migrate from Webmethods to TIBCO

Reason

You must have a reason to migrate. Don’t migrate just because someone told you. Or you are getting good Tibco resource available. There are plenty of resources for Webmethods too.

You must migrate because you find something missing in WebMethods. Or something which takes a lot of time in Webmethods than Tibco.

You must migrate if supporting an application in Webmethods is more difficult than webmethods.

Problems & Strategy

So lets say you have found your big reason to actually migrate from Webmethods to TIBCO. So what are the next steps:

1. Study the architecture. There is a huge change from Hub and Spoke architecture to Bus architecture. Webmethods runs an integration server. You can run each packages / services in the single server. But Tibco is Bus Architecture. Each package/service will run as a separate BWEngine. That means you’ll end up having a lot of system level processes on the server.

2. There will be no centralised management. In webmethods, you can share a lot of common services and call them from inside. But in Tibco you need to include the utility services as part of your EAR. Please note, while running things from Tibco designer, this is not the case.

This results in usage of extra memory. Lets say you have a lot of common business services, Its absolutely impossible to include each one of them as a library in your final EAR. Hence people tend to deploy these libraries as a separate BWEngine. Again a bigger problem is to do interprocess communication. For this EMS is used. A typical example is the TIBCO CUF(Common Utility framework ). All this becomes too complex for something simple.

Tibco Administrator is again single point of management for all TIBCO BWEngines and its again a good one but not quite complex as WebMethods’ Admin panel.

What TIBCO doesn’t give you: The JMS doesn’t even have a web based EMS Queue viewer… (I plan to write it someday! Or Tibco Guys should pay me for that! !)

Tibco Admion also doesn’t give you statistics about how much CPU is consumed or how much memory is being used.

However there is a workaround for that by using Tibco HAWK. Again another product that you may have to buy.

Supporting

While supporting Tibco applications, one cannot debug it unless the code is taken from the repository or installed on your system.
You will have to manage your Tibco code through your own repository. Applying patches in Tibco is also not very matured as Webmethods.

My Choice

I would still be reluctant to migrate to TIBCO. Not because I know Webmethods More than I know TIBCO, but because I feel webmethods is quite a good product. Tibco is more of a hype(I’m sure Tibco guys will hate me for saying this). But facts are facts. I get more stuff working and in an easy way in webmethods than TIBCO!

Reader’s Choice:

I would request the readers to post their own comments.

Many of you have wondered how to kill a WebMethods service while its running on the Integration Server.

Its become a Pet Interview Question for many but the interviewer also expects one of the following facts which is not the most recommended method to kill a running service.

Here are some facts:

1. If you are running the service on debug mode, the service will get killed if you kill your developer.
2. If you are running the service on RUN mode, the service runs on the Integration Server and will not get killed.
3. If your client has activated the service but terminated the session, the service will still run on the IS.
4. If your webmethod service is hung, You will try to Reload the entire package. But this will NOT help.
5. You will also try to unload the package but this will NOT help too.

What you need to do is on a Thread Level. The idea is quite simple: Just get the list of all the current running threads and kill the service which you need.

I will try to explain this in a step by step manner. Developers please do try it out on your dev boxes as well.

Step 1:
Create a Flow service like this:

Step 2:
Lets create a Flow service which will get ALL running threads. This should take NO input but lets output a String containing all running threads on that Integration Server.

Step 3:

Insert the following Java Code in your WebMethods Flow Service that you just created. The code is commented well enough.

//—BEGIN CODE—–
// Author: Hussain Fakhruddin (hussulinux@gmail.com)
// Date: 20090128
//Get the Current Thread
Thread currentThread = Thread.currentThread();
//Get all Thread Groups.
ThreadGroup rootThreadGroup = currentThread.getThreadGroup();
//Traverse to the Top Thread Level
while (rootThreadGroup.getParent() != null) {
rootThreadGroup  = rootThreadGroup.getParent();
}
//Getting all Threads
Thread [] threads = new Thread[1000];
int threadCount = rootThreadGroup.enumerate(threads, true);
String threadList = “”;
// Now traverse through all the Threads and use the ServerThread API from webmethods to get all the thread detail.
int i=0;
for (; i<threadCount ; ++i){
if (threads[i] instanceof com.wm.app.b2b.server.ServerThread) {
//Casting a raw thread into ServerThread type
com.wm.app.b2b.server.ServerThread serverThread = (com.wm.app.b2b.server.ServerThread) threads[i];
//Getting the service Name for which the thread belongs to
if (serverThread.getState().getService() != null){
threadList = threadList + serverThread.getState().toString() ;
java.util.Stack threadStack = (java.util.Stack) serverThread.getState().getCallStack();
for (Iterator iter=threadStack.iterator(); iter.hasNext();) {
Object threadObj = iter.next();
threadList = threadList + “\n ” + threadObj.getClass().getName();
threadList = threadList + “, ” + threadObj.toString();
}
}
}
}
IDataCursor cursor = pipeline.getCursor();
cursor.insertAfter(“threads”, threadList);
cursor.destroy();

//—–END OF CODE—–

Step 4: Now lets create another flow service “killThread” with the following inputs and outputs

Step 5: Now copy paste the following code. We’re going to traverse through the entire list and call the .interrupt() method to kill the process. Note: you need to provide FULL path of the service which you want to kill. You can get the full path from the webmethods admin panel (under package management).

//—BEGIN CODE—–
// Author: Hussain Fakhruddin(hussulinux@gmail.com)
// Date: 20090128
IDataCursor cursor = pipeline.getCursor ();
if (cursor.first (“serviceName”)) {
String serviceName = (String) cursor.getValue ();
Thread current = Thread.currentThread ();
ThreadGroup root = current.getThreadGroup ();
while (root.getParent () != null) {
root = root.getParent ();
}
Thread [] threads = new Thread [1000];
int count = root.enumerate (threads, true);
String sb = “Not Found”;
StringBuffer killedList = new StringBuffer ();
for (int i=0; i<count; i++) {
if (threads[i] instanceof com.wm.app.b2b.server.ServerThread) {
com.wm.app.b2b.server.ServerThread serverThread = (com.wm.app.b2b.server.ServerThread) threads[i];
if (serverThread.getState ().getService () != null) {
java.util.Stack stack = (java.util.Stack) serverThread.getState ().getCallStack ();
for (Iterator iter=stack.iterator (); iter.hasNext ();) {
Object obj = iter.next ();
String name = obj.toString ();
if (name.trim().equals (serviceName)) {
threads[i].interrupt ();
sb = “Interrupted”;
killedList.append (stack.toString ()).append (“\n”);
}
}
}
}
}
cursor.insertAfter (“status”, sb);
cursor.insertAfter (“killedList”, killedList.toString ());
cursor.destroy ();
}
//—–END OF CODE—–

That’s it folks! Save and run it.. Come back to me if you face problems..