Tibco and Certificates

I've been messing around for the past two weeks with certificate chains, different certificate libraries, and keystores in Tibco with a third party provider. Man, what a mess. To come into a project where nothing is documented about which certs are used and have more than half a dozen of them (legacy) littered here there and everywhere around the module, along with another 7 or so new ones isn't happiness.
Interesting things I've learned through this experience are:

• It turns out that there are compatibility issues with .p12 certificates between java 1.4 and java 1.5. I had a pkcs12 certificate that I could read and sign fine in java 1.5, and yet java 1.4 could not find the alias in the same certificate at all. Apparently, there are a couple of ways around this issue - I only got one of them to work. One way is to convert the .p12 certificate into a .pem cert, and then convert it back to .p12 (all of this with openssl). The .p12 certificate is supposed to be readable after the conversion from .pem, but that didn't work for me. I got some kind of invalid tag error. What did work for me was to use openssl to convert the .p12 cert into a .pem cert and change my java 1.4 code to deal with the .pem file. To do this I had to use a couple of jars in the globus library. I remember something about a BouncyCastle class. :-) Also, here's a link I found helpful to discover what kind of certs you are actually dealing with.
• Getting those new external jars to work in Tibco Designer's Tester was a bit of a trick. First I added them in tibco's jre/1.4.2/lib/ext directory. That enabled me to compile the java code in the palette java item. But when I went to run the tester, it said I had code I needed to compile !?! I then I found I also had to add them into the path property in the tibco/designer/5.2/bin/designer.tra file so that Tibco's Tester would compile the code.
  
• Trying to load the module into production, I ran into two exceptions in the Tibco adminstrator tool. One was an OutOfMemoryError. This was resolved by doubling the java heap property found in the tibco/administrator/5.2/bin/tibcoadmin-.tra file, and also doubling the values for the min/max heap size for the module, found under the module itself in the administrator GUI. The second exception was a InputStream cut off IO error. This was because my module was too big. I was referencing java libraries that we already had referenced in a 'SharedResources' module we have. Getting rid of those drastically cut down the size of my module and it loaded fine after that.
  

A Different Perspective...

I've been working with Tibco for the last two months. Before that I was involved in a significant development effort building an automated build system for a large java development team. What a difference in projects.

Before this gig, I didn't have a lot of experience with big SOA (Service Oriented Architecture) solutions like Tibco. Approaching Tibco's 'solution' from a java perspective is a bit of a shock. Why? Isn't Tibco coded in Java? It certainly looks like it, however it's end users (I don't think) were supposed to be experience enterprise Java developers. It appears to be geared more towards business analysts and 'light' coders. ...Grab this component, drop it there, draw an arrow to it from that component.. etc. I was somewhat aware of that going into the project.

Probably the biggest surprise and 'Aha!' for me is Tibco's business model. What I see is Tibco markets their product to the big decision makers (read: people who sign the cheques). Generally, these people have a high level view of most things, including the development process and what actually happens behind the GUI of an application. Tibco very successfully markets their products to these people, telling them that Tibco applications will 'take your system from greedy (as in a money sink) to speedy'. It looks great on paper and running in a demonstration. It looks like a Godsend to businesses that are fed up with waiting a month for the release cycle to finish so they can get their little text change posted in production.

Who knows.. it might be. It seems to come down to who really owns the business. Who calls the shots about what the business direction is and what should be put into production? Who's responsible if revenue doesn't meet expected targets? Should the business be limited and reigned in by IT's processes because 'everything needs to be unit tested, smoke tested, functionally tested, regression tested, performance tested, and then tested in a staging environment'? Sometimes it's fun to wear a cowboy hat.

The Tibco tool we work with doesn't seem to have much in the way of a testing harness... at all. Please feel free to set me straight on this - I want to know how to do some QA against a Tibco app. Also, our Tibco application makes close to 2 dozen separate calls (between itself and over the wire with a significant amount of data) for 1 single request - it's VERY chatty. Apparently, Tibco's solution to increase performance and make chatty applications run faster... throw more hardware at it.

For me the jury is out. I don't have enough experience yet to make an informed decision either way: Java enterprise or Tibco SOA. You want granular control of how your application works at the lowest level and you don't need to turn production on a dime - I'd suggest Java. If you want quick turnaround and a business oriented IT application, and you're not concerned about what's happening underneath the covers, maybe Tibco is the option for you.

Oracle, Tibco, and tcpdump

I've started a new project recently that uses Tibco with an Oracle backend. It still amazes me the little nuances of domain knowledge that are so key to being a productive developer on some of these 'platforms'.
My issue today was a query I was trying to run using the jdbc 'component' in Tibco. It's pretty finicky about SQL syntax. I needed aliases for column names and it turned out the only way to get those to work is to use double quotes. Single quotes work if you want to hardcode what you're returning in your select statement. Double quotes (I was told) are effectively ignored by Oracle unless you're trying to alias a column. I'm starting this blog mainly so I can keep these little nuances documented somewhere - I hope it'll help me remember in the future.

I ran into a different configuration problem with Tibco last week which I had to use tcpdump to help me solve. I used the command something like this: tcpdump -nnXi eth0 -port 8080. This helped me realized that Tibco was responding to http GET and not http POST requests.