Menu

Thinking about Implementing a Web Services Strategy?

March 4, 2003

Brian Buehling

Make Sure You've Done Your Homework...

Due to the industry's intense promotional activities most IT professionals have been exposed to the concept of web services. They know that a web service is a distributed application that exposes its functionality using a set of XML standards, most likely including SOAP, UDDI, and WSDL. They've heard repeatedly that this model offers the opportunity to better leverage existing investment in Internet technology by allowing companies to orchestrate business applications using components from various platforms throughout their enterprise. However, one fact is commonly overlooked. As with any emerging technology, the web services model presents its own set of implementation, process, and organizational challenges. These limitations are too often underestimated when formulating a corporate web services strategy.

In response to the recent web services media blitz, many organizations have forged their way through the business justification process to analyze how implementing a web services architecture would benefit their company. In doing so, they've studied the technology building blocks by learning about various XML standards and distributed application architectures. Additionally, they've reviewed the ever growing number of software products that can expedite the web services development process. Unfortunately, more times than not, after budgets have been approved, resources have been allocated and deadlines have been promised, their project team realizes that there are important shortcomings to the web services model that have to be addressed to successfully achieve their project's goals.

There are many ways to mitigate the specific risks associated with implementing a large scale web services project. So before rolling up your sleeves and plunging into your pending project, make sure you've asked yourself the following questions:

How will I guarantee that my corporate security standards are enforced?

The web services model does not yet include a standard way to ensure that underlying data will be transported or stored in a secure fashion. Therefore, security requirements must be implemented in the lower level architectural components including the physical network, hardware, and operating system. Additionally, higher level application security still must be implemented by the development team according to their business requirements.

What areas of my system are at risk of being performance bottlenecks?

For all of the benefits that the underlying XML architecture provides, it does complicate scalability and performance issues. The very nature of XML data implies that a certain amount of redundancy is necessary to utilize the many available XML-compliant development tools. The trade-off is that XML messages are typically larger and more resource intensive to manipulate than other messaging formats. Storing large volumes of these XML documents in traditional relational databases or file systems places unexpected loads on the system. The solution to these transport, transformation, and storage bottlenecks is often third party products specifically designed to handle XML data in a web services environment.

How will I make sure the web services that I utilize meet the Quality of Service levels that I require?

The grand view of web services involves scouring the Internet for services that meet your business requirements, evaluating their offerings, negotiating terms with their providers, and then utilizing them with no manual intervention. Examples of automating airline ticket, mail service, or manufacturing part purchases have been used to demonstrate this long term vision for some time. However, if you are building an application that relies on these types of web services, you'll have to negotiate Quality of Service terms with the provider offline. How to deal with system outages, programming defects, or unacceptable performance are all out of scope for the current set of web services standards.

How can I ensure that my web services architecture is robust enough to handle my organization's complex business processes?

To date, most web services are designed to handle simple request-response processes. Unfortunately, few business processes follow such a rudimentary pattern. Even the most basic of business processes have several possible acceptable outcomes. Implementing all of the permutations of these acceptable service agreements can quickly turn a seemly simple web service into a programming nightmare. The keys are to avoid designing overly complex web services and to offload as much business logic to supporting applications as possible.

How will I monitor and archive web service activity?

As with any business application you'll need to track web service activity within your organization. This becomes an even more critical component of your overall system architecture if you intend to use your web service as a commercial offering. However, monitoring at the level of granularity necessary for most services often results in an unexpected system load as large volumes of hierarchical XML data have to be managed. The characteristics of this type of data places additional requirements on the system that will have to be accounted for when designing your architecture.

How much of my IT infrastructure should rely on web services?

Ultimately, this is the most important question that you'll have to ask and answer. More times than not, it will make sense to expose the functionality of newly developed distributed applications using the XML-based standards for web services. However, shifting your IT infrastructure to solely rely on these services is a more involved task. Although the long term cost savings and associated benefits of doing so are clear, you should thoroughly understand the possible pitfalls of implementing an enterprise web services strategy in order to minimize the risks associated with this type of architecture.

Summary

In conclusion, utilizing web services offers great potential to reduce development time and cost in a variety of IT areas including enterprise application integration (EAI), supply chain management (SCM), and customer relationship management (CRM). However, organizations will have to do their homework to understand what problems will be directly solved by adopting a web services model and what challenges will be left up to the implementation team to resolve themselves.