SOA and Web Services Soup to Nuts @ SOA WEB SERVICES JOURNAL

The article link above is to an article on SOA Web Services Journal. The article is about visual design and web services. The author is a product manager for Altova . I use Altova XMLSpy a lot for schema checking and validation. The author is suggesting that contract driven design using a visual editor is best. Build the WSDL and schemas first before creating the service. I must confess that most web services I have created have been from existing services or I have created the service from scratch then generated the WSDL. But the idea of creating the contract first makes a lot sense. Using a house analogy, you create a set of blueprints before you start the house.

I have talked with a few folks at other companies that are taking this design approach. Usually they say the WSDL generation tools from services are to limiting in their capability. Anybody out there using Altova to do this? Anybody creating WSDL's from hand?

Building Reliable Infrastructure

Here are some quick tips I've used in the past when building out infrastructure and applications. Most of these are common sense and are well known. First I'll give you my quote that I also provide the customer when going over availability options. "There are two types of systems, those that have failed, those that are waiting to fail". Simply put, almost all systems no matter how well architected will crash and burn and some point. How fast you recover from that is what high availability(HA) is all about.

The quote is very important when communicating with a customer. It is important to set realistic expectations for systems. Along as humans are writing the code and building the infrastructure, then mistakes will happen. Minimizing and recovering from those mistakes are what make you HA plan. Here are the tips:

-Document, Document, Document. Every aspect of the system needs to be well documented. Concentrate on "what to do if this piece fails scenarios". Make it simple and concise. Make sure everyone has it and it has been exercised. This is the single most important step when building HA systems. The best architected system in the world means nothing if the folks doing the support don't understand it.

-Buy at least the second node. Clustering your hardware even in a passive mode can save you lots of down time. Convince your client its in their best interest. If you can't, make sure there is similar hardware on site available for parts. Trying to acquire parts while your server is down is not very fun.

-If you can, buy Veritas cluster software. It's the best. If you get it, practice, practice, practice. Go over as many what if situations as possible. Do this before the application goes live.

-Make sure you have a good change management process. Changes in the environment are responsible for a lot of application failures. Developers tend to want to throw code over the wall without a lot of testing. They are under a lot of pressure to meet deadlines and will take shortcuts. Make sure they don't if you want your systems to be stable. Always have build and test systems and make sure the code is exercised there before it goes live. Your test systems should be just like production.

-Application Architecture also has to be designed with HA in mind. The construction of your applications should take into account network failures, hardware failures, database failures etc. The way you handle errors with in the application can also affect availability. More on this in another post.

-Network Infrastructure is a key component to most applications. You can have the best architecture in the world but if your network is down then your application is down as far as the clients are concerned. Make sure you work with the network guys to understand the infrastructure and where the failure points are.

These are just a few tips I've learned over the years. Once you have a good handle on your what if scenarios and how you recover from them, then you will be able to give your clients a good idea on availability and potential down time. 5 nines is very difficult to achieve and almost no one does it. Make sure you are honest with the client and set realistic expectations. And remember, just because your application has not failed does not mean it won't. It just means you are lucky. Make sure you plan for when the luck runs out.

» Salesforce.com: Blame the database vendor | Between the Lines | ZDNet.com

The recent outage at Salesforce.com has created a buzz. Being responsible for the webMethods architecture and infrastructure at my company, I know all to well about unplanned outages and the affects on the customer. Blaming the software vendor for your outage? Well it depends. Somewhere around 99.999% of all outages are caused by human error. Either not installing correctly, failing to test the architecture and its cluster capabilities, introducing change into the environment, not following procedures, operating in an un-supported format and the list goes on. I have seen cases where the vendors software was to blame but it is pretty rare.

One important lesson I have learned over the years. Architecture your application and infrastructure with high availability in mind from the start. Most of your clients will not be willing to pay for it and will swear they don't need it. Then the first time it crashes all hell breaks lose. Sometimes you have to think for them. If a business application is worth doing in the first place(somebody is paying for it), chances are people are doing to need it most of the time, which means even small outages will cause you grief.

There are a lot of different ways to accomplish this. Your available budget will help guide you. More on this topic to come.

Ajax

I've been playing around with Ajax a bit. The book "Ajax in Action" is very good by the way. A very in depth treatment of the subject. The authors are Dave Crane, Eric Pascarello and Darren James. This a very detailed book. The authors not only go into detail about the technology behind Ajax but give a pretty good treatment on some common design patterns and how Ajax fits.

Here comes the but part. Although the book is very good, I not sure Ajax is quite ready for prime time. There is a lot involved with coding a simple client. A more complex client, which is the promise of Ajax, would be difficult at best. I think it will eventually come along but tooling is going to be needed for widespread adoption. I think that will be coming in 2006 but until then get ready to get in the trenches if you want to do Ajax.

What's on tap for 2006?

2006 is shaping up to be a big year in technology. The Sun announcement ripple effect will start to be felt. I suspect we will get a lot of those types of announcements from other companies. Open source will continue to put pressure on everyone. Ajax buzz is probably going to continue to grow. I would look for efforts to make the process easier via some better tooling in the popular IDEs.

Computing power will continue to go crazy. Sun's 8 core chip that consumes about the same amount of power as a light bulb is just the beginning. All of the chip makers are going that way. More and more horsepower in smaller and smaller places.

What do we need it for? SOA of course. I expect non IT technology vendors to get into the SOA business in 2006. Refrigerators are the next big SOA thing. Just imagine your home with multiple refrigerators. Of course you don't know that they are refrigerators. All you know is you have left over pizza that needs to be kept cool. You just dynamically discover the keep cool service after you eaten all you can eat. It finds the optimal refrigerator based upon your SLA and stores your pizza at is optimal goodness. No stealing that idea, its all mine.

elemental links: Open Source Considerations

Another very good article from Brenda Michelson on evaluating open source as a potential fit within your enterprise. There are a lot of good questions to ask when evaluating open source and its potential within the enterprise and Brenda really does a good job of laying them out. I especially like the question she asks "Could you Survive Alone?". I think that should be the very first question you should ask yourself. If you cannot get past that one, then open source is probably not for you unless you are going after a pretty safe product ie Linux or Apache etc.

Greg Wdowiak » Blog Archive » Application Integration and Agility (1): Understanding Agility

I've always thought that a more waterfall oriented approach to software development was in order for integration projects. My logic was real time integrations to tend to be complex, lots of time needs to be spent with abstracting, common data formats, and very strong understanding of up front requirements. Scope change needs to be kept to a minimum because of some of the inherent complexity.

After reading Greg Wdowiak's article, I'm suddenly a lot less sure. What do you think about an Agile methodology for integration solutions? Does it make sense?

Jacob Hookom: Is Sun as good for open source coders as Apache?

A couple of good explanations of the open source licenses in this article. It got me to thinking about business and their approach to software and specifically support of the software. My question was this: Would it better from an IT and cost perspective to have a few strong tech resources and use open source software or is it better to use well established vendors like Microsoft, Oracle, IBM etc and pay heavy for maintenance and support.

I think the answer is, it probably varies. We tend to pay for the security blanket called support because we think they will bail us out in a bind. But in reality how often does that really happen? If you had the source and the strong tech resources, could you turn around the solution faster and cheaper? My personal experience with tech support from various companies is that all but the simplest problems are beyond their ability to help. And the turn around time is usually slow. I think a lot of times tech support agreements are like insurance. You feel scared enough that you have to have it but when you need it, you find out that it does not really cover what you thought.

I think at the end of the day having a strong core team is better than a large tech support contract whether you use open source software or not. But if you are using open source, then its an absolute requirement. Time will tell if the financial benefits are there as well.

SOA Pipeline | Services-Oriented Architectures

Once again another vendor trying to tell the customer, SOA is really a product and looky here, we have one. Check out the price.

elemental links: InfoWorld SOA Exec Forum: Key Takeaways from Enterprise (Real) SOA Practitioners

This a good start on some lessons learned (high level) for SOA adoption and strategy. Two key points I liked: 1) Leverage mediation between your services and 2) No one is dynamically discovering and invoking services at run time. I've always thought the mediation was key to a successful integration architecture. The idea that each application would just talk to each other using standards without some mediation just seems a little far flung in the real world. And boy if you work for an IT shop that is rolling out integration services that are dynamically discovering and invoking each other at run time, wow.

UPA

Want to impress your co-workers? Toss out the UPA acronym in a conversation. UPA stands for Unique Particle Attribution. No this is not a physics class. Its a rule imposed on XSD validation. Here is a good explanation of UPA. I had no idea what it was. I stumbled on it while doing some interoperability test with webMethods and the new version of Axis2 ver 0.93. The WSDL I was using had not properly defined the namespace so one element could not be resolved correctly. Axis1.3, .Net and webMethods apparently have a looser validation engine than the new Axis2. So if you get a "Content model violates the unique particle attribution rule" error, now you know what the heck it means. Who says XML is complicated?

Jonathan Schwartz's Weblog

Jonathan's entry on Sun's decision to open up its enterprise suite of products is very good. I think the key point he made is this, "Betting against FOSS is like betting against gravity". My take, the train is here and it is moving fast. Like it or not, open-source is changing the software industry at a rapid pace.

Sun makes JES, developer tools free and open source

More on the Sun announcement. I particular thought the comments by Marc Fleury were interesting, especially about SeeBeyond.

Sun Gives Away Java Enterprise System, Other Software - Yahoo! News

Sun is giving away a whole lot of software. You still have to pay if you want support but... What does this move say about the open-source movement and the pressure it is creating for the major vendors? I think it is a reasonable question to ask your software vendor, how do you plan to react to the open-source movement? If they say huh, then you probably have an issue.