Tuesday, May 30, 2006


I finally got Solaris 10 (Intel version) installed in a Parallels VM. I had a bit of a mouse problem that was holding me up. Just for the pure geekdom I had Solaris 10, Windows XP (Base System) and Fedora Core 5 (complete with running webMethods Integration Server Instance) running at the same time. It taxed my laptop pretty hard but it was pretty cool. It struck me as funny that I was doing this as I was writing up our company's Integration\SOA\Web Services strategy. On the surface two very unrelated tasks to say the least.

I have found in my role that effective Integration Architecture requires a wide range of skills. It goes well beyond pure development, touching things like Networking, OS's, Databases, MOM systems, Servers, Systems Management and more. It may seem obvious or it may not. But I find a lot of the things I read failing to take these things into account. What do you think? What skills have you found make a good integration architect?

Wednesday, May 24, 2006

It's up, it's down, it's up

From time to time you may notice that this site becomes unavailable for brief periods of time(once every two or three months). Yes I know you are crushed. If you have read the site note, you will know that this server is hosted in a closet in my house. It is connected to the Internet via a wireless Ethernet bridge. The bridge is pretty reliable but it does have its moments from time to time. Today was one of them.

Tuesday, May 23, 2006

It's Easy!

Underestimate the complexity of implementing Web Services, SOA, or EAI and you will likely pay a steep price. Vendors and some industry analysts like to tout this as the easy part. Just use standards and this stuff is pretty easy. All you need is the 850 standards and their toolset.

I'm sure the getTemperature("Insert your zip code here")they tried once was pretty easy. In reality Integration work is pretty complex. There are a lot of contributing factors to the complexity that no one really addresses when hyping it up. Some of these factors include: Complex Business Rules, Data Enrichment, Infrastructure dependencies, Interoperability, Standards Interpretation, Distributed or Silo oriented Development teams.

Integration Architects have their hands full trying to make all of this stuff work. When you consider that some of the biggest reasons for adopting EAI, Web Services, and SOA is reuse and agility, these are in fact some of the hardest benefits to obtain. My advice from hard earned experience, do your homework before you go down these paths. Nobody wants to explain to their business units why its not possible to reuse any of the services you just deployed for several quadrillion dollars. Not to mention they aren't reliable and they don't interoperate with any of your other technologies or platforms.

The bright side is that is possible to achieve these benefits. But did I mention the homework part? Oh and when the vendor says it's easy, Run Away!

Thursday, May 18, 2006

Business-Driven Architect - ebizQ

Brenda Michelson has a new blog. How she has time to write in it, I have no idea but it should be good. I'm personally on my second major production issue for the week, I believe I'm starting to hallucinate. Does everyone see guys in orange bunny suits standing in the corner?

Sunday, May 14, 2006

Web Service Skills

Skill sets needed to consume web services is a frequent topic of conversation. I often hear from vendors and analyst that the consumer of a web services doesn't need to know anything about WSDL, SOAP or XML. I think many of them say that because a lot of the tools out there help abstract away that complexity from the consumer. For example in .Net when you consume a web service, the XML is marshaled and unmarshaled for you. The user ends up with a series of classes to work with instead of XML.

This is great assuming everything works correctly. The reality though is things don't always work correctly. More often than not, a developer with have to trace the messages being sent and returned from the web service. This means using something tcptrace to inspect the messages. Once the messages are being capture, comparing them to the WSDL is usually required. Understanding XML Schema, SOAP message structure and WSDL structure is required in order to do this. Things like namespace issues, type incompatibilities or improperly formatted SOAP messages are the usual suspects. But you have to know what you are looking at.

So does the developer need to be a XML expert? No, but a base level of skill is required. At a minimum, the developer should be able to read a WSDL and understand how to construct a proper SOAP message against it. The developer should also be able to tell when the SOAP message is constructed incorrectly. Without this minimum set of skills, developers will struggle to consume web services.

Monday, May 08, 2006

Iona launches open source ESB - Yahoo! News

Iona is launching a new open source ESB. It begs the question, do all software vendors need to open source at least a partial part of their offering? Does it really help drive market adoption faster by having a version developers can get their hands on?

Friday, May 05, 2006

Parallels Virtualization Software

I just started using Parallels Workstation 2.1. Do yourself a favor if you need this capability, try out Parallels product. They have a free trial. The product could not be any easier to use. I have Fedora Core 5 and Windows XP running side by side as we speak. I'm adding Solaris 10 this weekend. They support almost every OS in the known universe including OS/2 (remember that one). Okay they don't support AIX or HPUX but who really cares. ;) They don't have all the features that the higher priced VMWare product has but it is still pretty well featured.

Wednesday, May 03, 2006

Great Support

Don't know if any of you have or are using Eclipse for anything. I'm using it to do some interoperability testing with their WTP module. I've talked about their WSDL support in a earlier post, its pretty good for free. I wanted to mention their support/development community. It's staffed by a lot of folks at IBM. There are others but a whole lot come from Big Blue. I recently found what I thought was bug. I got a response back the same day I entered it. And it was resolved by the next day. Turns out it was not a bug but a desired ableit somewhat quirky behavior.

My point about all this is of course the Open Source support fear that a lot of companies still have. I find that in general Open Source software support is better than paid support. I think there are a couple of reasons for this. 1 - Pride of ownership in a much smaller company or community. Most of the time you are dealing with the people who wrote the software or are very close to it. 2 - You are dealing most of the time with the people who wrote the software or are very close to it. You are not going through some 1st level support help desk that has questionable training let alone any in depth knowledge of the product. The answers are quick and usually very accurate. Of course a lot of Open Source companies offer the support contract if you are so inclined.