Home | Business News | Browse by Publication | X | XML Journal

Building manageable Web services from the ground up: the management criteria developers must consider.

Article Excerpt
Life is full of compromises, and application development is no exception to the rule. So, when that project deadline is looming (and it always is) you are faced with three options:

1. Finish the functional application

2. Ensure that the application is manageable

3. Ask your manager for more time so you can accomplish both

**********

Since number #3 might be career limiting, it's usually a choice between #1 and #2. And no one gets extra points for manageability if the application doesn't function as advertised. Clearly, creating a fully functional application wins every time--When timeframes are tight, management functionality is often the first thing cut.

Good tools are available to automate the management of traditional applications built on application servers--you can find them in systems management suites like HP OpenView, Tivoli, and Unicenter. Great news if you are building a traditional monolithic application, but what if you're building an application using Web services? How do you build management capabilities into an application that is not stand-alone, but rather composed of a collection of services from multiple sources?

While Web services applications are more flexible, quicker to build, and quicker to adapt than their monolithic counterparts, they are inherently more complex because there are many more moving parts and myriad interdependencies. A problem with a single Web service has the potential to bring down the whole network of Web services. This complexity makes effective management even more critical for Web services applications than for traditional applications. Unfortunately; traditional management systems were never designed to manage applications composed of multiple separate yet interdependent parts.

Webs Services Management

This article explores four management criteria that developers must consider when building applications based on Web services: security, monitoring, service location, and versioning. It also examines the specific challenges associated with each criterion.

Security

With traditional applications, managing access control typically means "check IDs at the front door." With Web services applications, there are two additional considerations:

* Web pages are typically protected by URLs; each URL can be assigned different access rights. A complete Web service, however, is represented by a single URL. For example, a Customer Web service may have operations for querying, creating, deleting, and updating customer records, yet it would have only one ORE for all four operations. As a result, it's difficult it control access to read-only query operation separately from the operations that change data.

* The "front door" approach to security does not work with an application built from multiple services. You need...