Time to Make Tracks for Web Services

During the dot.com craze, CIOs felt like they were under attack, but were not sure how to react. The recent state of the economy has allowed CIOs to take a breath, survey the lay of the land and assess the best way to proceed. But now the breather is over. CIOs have an opportunity and an obligation to take the battle to the enemy. Six months to a year from now, the CIO will need to have a good answer to the question "What are we doing about Web Services?" But wait, the CIO asks, "Is Web Services the latest buzz word? Is it another hot button designed to meet sales quotas?" An analogy helps us answer this question by understanding what is happening today, and consequently what strategy should be employed.

The most significant economic event of the 19th century was the invention of the steam locomotive. For the first time in history, goods could be transported efficiently on a large scale across land. However, a subsequent, and much less heralded event had enormous significance -- the agreement among railroad companies to standardize the gauge of railroad tracks. Until this was achieved, large-scale transportation of goods was not optimal. Goods had to be unloaded and reloaded as they passed from one carrier to another until a standard was achieved.

We are at a similar stage in the economic development of technology. For the first time, virtually every technology product provider is agreeing on a standard approach to interact with one another, (i.e. transport information) via Web Services standards. The significance of this cannot be overstated when you consider 1) the vast resources devoted to creating custom interfaces between computing systems and 2) the unsatisfied needs resulting from a high cost barrier to achieving integration.

The message is clear. Organizations must "make tracks" by preparing to participate in the global electronic commerce arena using Web Services. This standardization is as significant to conducting business in the future as the standardization of rail gauge was in the 1800s. It is essential that CIOs move their organization forward now. It takes time to develop the technical infrastructure and institutional knowledge required to build and use Web Services effectively, and the race has already started. Web Services technologies are available now and the total cost of ownership pendulum has swung in favor of the buyer.

So let's get started. The first step is to choose a construction method. The choices are Microsoft's .Net or the Java application server approach (J2EE standard) endorsed by the majority of influential technology providers.

Microsoft's .Net is a product that is proprietary internally but conforms to the Web Services standards externally. J2EE is a standard for internal processes that vendor products adhere to, and it also supports the Web Services standards externally. This leads to a lot of analysis and discussions regarding the pros and cons of each choice that are beyond the scope of this article. Suffice it to say that the end goal can be achieved using either method. Let's assume that you have made the choice to go with the more widely established J2EE approach. Excellent choice.

The next step is to put the infrastructure in place. Since the beginning of the dot com phase, the J2EE compliant approach has been dominant. Improvements have been made to both the standard and its adhering products in a relatively short period of time. The products have matured to support enterprise grade requirements. Issues related to performance, ease of development, methodologies, security, and scalability have been addressed and resolved to an acceptable degree. Unfortunately, the cost structure was and can still be extremely high. Hardware and operating system costs, relational database management systems, highly skilled labor, and Java application server middleware are the four primary components.

There are some opportunities to reduce costs in the first three components. Hardware costs can be reduced using private label "white box" solutions running Linux or Microsoft Win2K operating systems. Investments in relational databases can be also reduced or eliminated by using an open source database, such as PostgresSQL. Highly skilled Java programmers are available as a result of the economic turndown.

However, the fourth component, Java application server middleware, offers the biggest opportunity for savings. Market leaders are IBM's WebSphere and BEA's WebLogic, with Sun's iPlanet a distant third. The cost structure of these products may be deceiving. The initial cost is an entry point. Many features such as clustering, fail over, and wireless support are only offered as a high priced "add ons" to the original product. In addition to the acquisition cost are license fees for renewal calculated as a percentage of the initial software cost. This high cost structure has attracted competitors. As a result there are viable, reasonably priced Java application alternatives available now.

Lutris Technology's EAS Java application server offers the best value of these alternatives. This EAS server offers a rich feature set that compares favorably with the leading vendors' offerings at a much lower price. For a commercial grade application, a cost of ownership comparison of software acquisition costs and software maintenance fees show savings of over two hundred thousand dollars for the Lutris EAS solution compared to the "name brand" Java middleware solution. This represents savings of nearly 80% for the Lutris EAS solution.

For mission critical applications, saving costs in the core of the system can be a dicey proposition. Fortunately Lutris EAS is a high performing and highly reliable application server. The key to its success is its superior design, unencumbered by design flaws of older generation products. This design allows the server to perform like an operating system, where all services are plug and play -- allowing for more flexibility, improved modularity, and a less complex operating environment.

Some of EAS's key advantages are:

  • Enterprise grade commercial software -- able to handle high uptime and high performance needs.
  • Comprehensive product -- includes clustering, session level fail-over, wireless support.
  • Built in support for Web Services -- including Simple Object Access Protocol (SOAP), Web Services Descriptor Language (WSDL), and Universal Description, Discovery, and Integration (UDDI).
  • Reduced complexity -- easy to build and easy to operate using a sophisticated management console.
  • Small footprint -- software modules are fast loading and efficient, services can be added or removed as needed

The train is leaving the station. CIO's must focus on building the organization's infrastructure now to support Web Services tomorrow. This undertaking is not as sexy as a dot com project, but it will position the organization to optimize its ability to conduct business. In addition, the job can be done within today's "reality check" budget constraints, particularly when Lutris EAS is used as the core Java application server middleware technology.