Management, as it relates to computing environments, is a multifaceted discipline. It pertains to systems/server management, client management, applications management, database management, storage management, network management, and much more.
Management in the Web services world is just as complex, and it relates to:
- The management of Web services-based applications (ensuring that Web services requestor and service applications can communicate with each other and provide services for one and other).
- Performance (ensuring that Web services applications can meet prescribed performance expectations).
- Availability (ensuring that Web services applications can find their application service partners-and if not, take the appropriate action).
The most pressing need today in the Web services world is for software that allows systems administrators (or management applications acting on their behalf) to determine if applications can communicate successfully and act within policy guidelines (such as security), while performing in a reliable "available" fashion. Web services administrators need "monitor and control" assistance.
In this article we examine the complex world of managing Web services applications with focus on:
- Issues related to Web services management (what it takes to manage Web services applications).
- The evolution of Web services management standards and products (where we are now, and where Web services management is heading).
Web Services Management Issues
The primary issue related to Web services management is ensuring that Web services applications can communicate with (and perform services for) "requestor" applications. This implies that "service" applications are able to:
- Receive a request for an application service.
- Perform that service (retrieve data, perform a calculation, or some other function).
- Close the session (once the service has been provided).
At first glance, this list of functions seems simple and straightforward. But what would happen if:
- A "requestor" application could not locate the service application (for instance, the server on which that application resides could be down; or the application could have been replaced by another application).
- A receiving service application cannot perform the requested function (because the data is not available or the user is not authorized to view the data).
- Secure data was made available while completing a database or information request.
- The service fails to complete (for instance, a transaction could fail, or a system could hang), so a particular service application fails to execute.
In short, for service applications to provide services, they must be able to coordinate activities; they must be capable of transactional roll-back should an application fail; and they must be able to observe policies (such as security). And all of these application-processing elements must be able to be managed by administrators or programs actin g on their behalf. Information Systems (IS) professionals (or their programmatic proxies) must be able to figure out what's happening when an application fails and be able to take corrective actions. This form of management is often referred to as monitor and control.
Without rudimentary monitor and control facilities, Web services architecture has difficulty as it attempts to gain acceptance for run-the-business applications within the enterprise firewall. And, without more sophisticated monitor and control management facilities, Web services architecture runs into resistance when being used for complex transaction processing beyond the enterprise firewall (between business partners).
Beyond basic monitor and control, there are dozens of other elements that need to be managed to ensure the reliability, availability, security, and performance of Web services. Those elements include:
- Operations management (job scheduling, workload balancing, and so forth).
- Software distribution (updating Web services applications and coordinating changes).
- Reporting (information gathering, reporting).
- Systems management (ensuring that the systems that run Web services are operational).
- Network management (ensuring network quality of service).
- Data management (ensuring that data that is exchanged can be read by the requestor).
- Asset management.
- Service level management.
- Self-management (scripts that contain preset procedures to deal with application, system, or network problems; software that can assist in providing self-healing; and so on).
In other words, managing Web services applications involves much more than simply monitoring and controlling message-passing between application service requestors and corresponding service applications. But, addressing the monitor and control aspect of Web services management will go a long way toward making Web services more palatable to enterprise executives looking to use Web services as a means to facilitate intra-organizational program-to-program communications.
It will take years to add sophisticated operations, data, asset, and applications management features to Web services architecture. Meanwhile, my research shows that today's efforts are concentrated on monitor and control functions, leading me to suspect that in the longer term, efforts will be concentrated on Web services self-management.
Activity to Date
If you search the Internet for Web services management, you'll find very little. The manageability features described previously are actually parts of other specifications or recommendations. For instance, the management elements for Web services security show up in the WS-Security recommendation that is being put forward to the OASIS* standards committee by Microsoft, IBM, and Verisign.
The manageability elements needed to coordinate application activities and to ensure transactional integrity or roll-back show up in new recommendations from Microsoft, IBM, and BEA called WS-Coordination and WS-Transaction.
Further manageability standards can be found in program ming specifications themselves such as the Java* language JMX extensions (these extensions enable programmers to report management characteristics to overarching management applications that could then take corrective action based upon the information reported).
And some of today's existing manageability products from IBM (with its Tivoli* management architecture), Computer Associates (with its Unicenter*), and Microsoft (with products such as its Client Manager* and Server Manager*) also contain system, application, and network elements that can help manage Web services applications.
The bottom line of Web services management is that bits and pieces of technologies needed to monitor and control (and ensure the integrity of) Web services applications can be found in the program languages used for writing Web services applications; in existing management products; as well as in several new recommendations that have been put forward by the vendor community.
Beyond Monitor and Control
Much of the Web services management activity to date has been geared toward enabling better monitoring and control. But, as discussed previously, there's a lot more to Web services management than program-to-program communications.
As Web services management matures, Information Systems executives will find more and more tools and utilities on the market to address operations management, software distribution/upgrades/rev cycles, systems management, network management, applications, management, and so on. These applications will be able to capitalize on the loosely coupled nature of Web services architecture and act in an automated fashion to manage Web services applications, infrastructure, systems, and networks. In short, expect to see a new generation of sophisticated self-management applications come to market for managing Web services applications over time.
To illustrate the concept of self-managing systems and applications I like to use Unisys' Sentinel* systems management product as an example. Unisys took the basic Microsoft Windows* platform and wrote code and scripts that make it possible for their ES7000* servers to take preemptive and corrective actions in case of a system, application, database, storage or other information systems failure. What is fascinating about the Unisys approach is that the company offers "extensions" to the Windows environment that provide:
- System Health Monitoring
- System Health Advisor
- Unattended Operations
- Anytime/Anywhere Remote Management
- Hardware and Software Inventory
- Call Home
- Configuration Management and Setup
Windows operating environments occasionally require an operating system reboot to flush memory or to restart certain applications. Under certain circumstances, as dictated in a script (either provided by Unisys or written by an administrator), Sentinel can automatically reboot the Windows operating system. Sentinel diagnoses a problem; follows a script; takes corrective action; and brings a failing system back into operational order in far less time than it usually would take a human operator to perform such tasks.
Other self-management functions provided by Sentinel include:
- Auto-recovery of hardware failures, memory, and cache errors
- Automated OS reboot
- Automatic end and restart of processes
- Dynamic processor affinity management
- System alerts
- Operational events
- View or modify deliver schedule
- Call home
- Collect support information
- Create or delete memory unit
- Create or delete partitions
- Change partition settings
- Activate start, stop, or deactivate a partition
- Change partition heartbeat attributes
- Add computer systems to be monitored.
Adding to its extensive list of systems/operating system extensions, Unisys also offers database resource management features such as:
- Virtual storage pools
- Heterogeneous storage and server attach
- Unified storage management and applications
- Storage independent snapshots and mirrors
- Tape virtualization
What does Unisys' self-management software environment have to do with Web services? It represents the start of a trend. Other vendors have similar products written for Unix. IBM has dozens of similar products available for its four processor lines and storage subsystems. These and other vendors are integrating systems/application self-management features into their management strategies. And they're integrating self-management and Web services as integral parts of their ongoing product strategies. (Self-management is an integral part of Hewlett-Packard's manageability strategy, as well as IBM's "autonomic computing" management strategy.)
The challenge will be to develop standards that allow Web services self-management to take place in a uniform manner across heterogeneous systems and application environments. Such standards are just starting to evolve in the Web services world.
A major obstacle to building reliable and manageable Web services applications is getting developers to write the programming necessary to provide management information to overarching Web services management packages. Or getting developers to write programs that specify security levels. Or getting developers to write programs that include specifications for coordination and transaction handling. In many cases, developers view these tasks as "overhead" that takes time away from writing useful program-to-program applications.
This situation is similar to the age-old question: which came first, the chicken or the egg? Without the tools and specifications for writing secure and reliable Web services applications, programmers have either been forced to write non-standard security or transaction-handling code into Web services applications, or skip them altogether. Now developers have specifications that provide guidance and applications designed to help manage Web services environments, so they can write Web services applications that can be effectively managed.
The ability to monitor and control Web services applications is the most pressing issue pertaining to Web services manageability. Systems/applications administrator s must be able to find out when errors occur during Web services program-to-program communications and then be able to take corrective action to remedy such failures.
The tools and specifications for effectively monitoring and controlling Web services environments are starting to come to market. They cannot easily be found under the heading "Web services manageability." Instead, they can often be found within the program language environment itself (such as the Java JMX extensions), or within vendor standards recommendations such as WS-Security, WS-Coordination, and WS-Transaction.
Over time, expect Web services applications to be managed using self-management products and procedures. But for now, Web services manageability will concentrate mostly on monitor and control functionality.
Business requirements will drive programmers to make use of the tools, utilities, extensions, and applications needed to ensure reliable and secure Web services transactions. Their skill sets will ramp up accordingly (probably within the next two years).
About the Author
Joe Clabby is the former VP of Platforms and Services at the Aberdeen Group (a Boston-based research and analysis firm), and is now president of Bloor Research-North America. (Bloor Research is one of Europe's top five research/analysis firms. Mr. Clabby is in charge of building Bloor's North America operation.) After twenty-five years in the Information Technology field, he is now a technology author (Visualize This, Prentice Hall), and will soon publish Web Services Explained (again, Prentice Hall) based on market research related to Web services.