You are equipped with a technical understanding of Web Services. You are a strong believer in the power of Service Oriented Architecture (SOA). Now you're eager to bring SOA to your enterprise. You want to get maximum benefit from SOA, so you propose to service-enable the key functions of your company's enterprise resource planning (ERP) and customer relationship management (CRM) applications and automate cross-application processes like order-to-cash.

Quickly, you realize that this means significant change to the organization. Unfortunately, most human beings and organizations resist change. Your CIO is doubtful. He doesn't want to spend any resources on anything that isn't absolutely necessary. He demands 100% proven return on investment. Functional users are limited to their functional silos. Having discussions about cross-application processes requires 20 people to be in one room and still nobody has ownership of the end-to-end process.

Don't be discouraged. There are many ways to get started with SOA. Rather than attacking the most complex cross-application business processes, you can, for example, apply SOA principles to traditional data integration challenges. You can also focus on hot topics such as Web self-service to demonstrate the power of Web Services. In this article, we'll show you another interesting approach to how you can get started with SOA in a less-daunting setting.

We'll show you how you can practice SOA and build up value step-by-step. The first is to service-enable small units of existing custom code. Second, we'll show how you can then reuse these Web Services as part of small process flows. Third, these smaller process flows become useful sub-processes of end-to-end business flows. That was your goal, right?

Let's reveal the secret: we believe IT operations are an interesting test bed for SOA, specifically for SOA-based process management. IT processes are what the CIO understands best. IT processes aren't as organizationally challenging as large end-to-end business processes. Yet, complex IT environments have created IT operations that are ready for process improvement. Today, system administrator salaries are the most prominent IT budget line item, and those highly paid resources are executing mundane, ad hoc, and unscalable tasks. It's no wonder then that ITIL (Information Technology Infrastructure Library), a widely accepted framework for IT Service Management, is today's "hot topic." Hence, it's likely your CIO will listen to your proposal to apply SOA to the IT operations challenge. The good news is that system administrators have written large amounts of custom code in the form of Perl code, Unix shell scripts, or Visual Basic (VB) scripts. These programmatic assets are ideal candidates to apply your skills of service-enabling IT assets.

USinternetworking, Inc. (USi), an AT&T company, made use of this favorable environment for its endeavor into SOA. Let's learn from USi's success. Concretely, we'll explain how you can quickly create a Web Service from an existing Perl script. Then, we'll reuse the service-enabled Perl script as part of a typical IT process and show how you can incorporate this IT process into a larger end-to-end business process. Finally, we'll dive into the world of IT processes to give you a better feel for the opportunity and how BPEL (Business Process Execution Language) is suited to this domain.

Service-Enabling a PERL Script
The first step in applying SOA in IT operations is to create a set of Web Services. On its quest to automate IT processes, USi made an important discovery: many of the tasks required already existed as Unix shell scripts, Perl code, and VB scripts. System administrators created such code components to simplify their job by automating repetitive tasks and generating the necessary documentation required for audit purposes. In the spirit of SOA, USi decided to reuse these pockets of custom code. By creating some basic "wrappers," these legacy code components were converted into Web Services. By standardizing this wrapper definition, it's possible to take disparate custom code created by a wide range of individuals and expose it as part of a SOA initiative with a common methodology for instantiation, security, and error reporting.

Let's take a look at how you can create such a wrapper for a legacy code component. If you come from the Unix/Linux world, you might be familiar with legacy scripts and code packages written using Perl. USi's Quadir Kareemullah demonstrates how easy it is to convert Perl code, in this case a script to create a Unix account for a given Linux server, into a Web Service. Listing 1 shows UserAdd.pm, the initial Perl script.

Let's create a wrapping package that will expose UserAdd.pm via SOAP (Simple Object Access Protocol). The "use UserAdd" statement tells the new module to use our legacy code in UserAdd.pm. The two SOAP lines that follow are what enable the module to be called as a Web Service. A "sub" section then follows for each function in the original Perl module. A separate wrapping module lets you add additional SOAP error handling to conform to a Web Services methodology as found in the "die" statement near the end of the script. This wrapping package, UserAddWS.pl, is shown in Listing 2.

The result is that the original code continues to exist without any change. A significant benefit is that no regression testing is required for adding the wrapper in this non-intrusive manner.

In addition, other features can be introduced to UserAddWS.pl to take care of security. Now that the code is exposed as a Web Service, traditional application security that restricts access to the functionality is no longer in effect. However, support for standards such as WS-Security (Web Services Security) to manage access at the wrapper and WSDL (Web Services Description Language) level can be added without impacting the original application code.

The final step is to create a WSDL definition for the new package so that it can be called by a BPEL process or via statically typed languages such as Java or VB. If you search the Comprehensive Perl Archive Network (www.cpan.org), you'll find Perl modules that help automate the creation of WSDL files. The WSDL for our example code, UserAddWS.wsdl, is shown in Listing 3.

In this WSDL, you can see a number of components relating to the UserAddWS.pl package, including the:

• Namespace definitions
• Request and response message types for each function defined in the package
• Port definition with an operation entry for each function in the package tied to the associated message types
• Binding definition with operation entries to tie all of the definitions together
• Service definition that defines the URL necessary to call the UserAddWS.pl package

Oracle's Enterprise Manager system management offering serves as another example how to make use of this technique to service-enable applications relevant to IT operations. The Enterprise Manager Command Line Interface (EM CLI) lets you access functionality from text-based consoles (shells and command windows) with custom scripts such as Perl, SQL*Plus, OS shell, or Tcl.