As Published In May/June 2005

Feature

Modern Design
By Alan Joch

Working as an executive for a large corporation in Hawaii is many people's idea of a dream job. But Soren Burkhart, CIO and senior vice president of Aloha Airlines, a leading air carrier in the vacation travel industry, understands that even in the tropics, life is not always, well, paradise. Cutthroat competition drives the airline business, and as a CIO with an MBA from Northwestern's prestigious Kellogg School of Management and a bachelors of science degree in computer engineering and electrical engineering from Purdue University, Burkhart knows that for Aloha Airlines to be successful, everyone there, even technology managers, must maintain a focus on the bottom line. "For me, technology either helps the business make money or causes it to lose money," he says.

Increasingly, CIOs such as Burkhart are maintaining their bottom-line vigilance by relying on service-oriented architecture (SOA), which offers a strategy for updating and optimizing business processes as quickly as market conditions change. Aiding the approach today are full-featured integrated development suites that make it easier for developers to create interoperable and reusable services that extend existing applications' capabilities and create new ones.

"We can expose components of our business processes as Web services that provide information to our business users, external partners, and customers and integrate them across the enterprise," Burkhart says. "In the past, software components used hard, brittle interfaces between different systems. Now we have more loosely coupled interfaces and things such as BPEL [Business Process Execution Language], so we can focus on the important business-process piece."

But SOA success isn't a given. Adhering to standards doesn't guarantee interoperability among tools and systems. Poorly designed services may be plagued with unnecessary overhead that saps runtime performance. And new development methods and terminology can be confusing at first to 4GL programmers.

"For developers who know what they're doing, SOA can reap many benefits," says Mark M. Davydov, a member of the IEEE Committee on Software Architecture and vice president and senior technical manager at a leading financial services company, where he is involved in an effort to create SOA-based consumer banking applications. "But those who think these benefits will magically materialize because of this new protocol or that set of new gadgets may find more trouble than ever."

It doesn't have to be that way. With the right development practices and tools, SOA experts say, SOA can achieve real business value.

Building Blocks

The beauty of SOA lies in its ability to provide new computing resources in a resource-constrained world. "Web services and SOA let you easily integrate your existing infrastructure and existing applications with new ones," notes Roel Stalman, Oracle's senior director of product management for development tools. "People can build new applications and tie them into their existing infrastructure."

The basic SOA building block for accomplishing this is the service, a code nugget that performs a specific job. To work effectively, services must provide the proper levels of "granularity" and "coupling" for each task. Granularity pertains to how fine or coarse the service's performance characteristics are. Does it, for example, retrieve the entire contents of a customer record or just a customer name? The best approach depends on the individual application's needs. Coupling determines how closely different services are bound together, ranging from tightly coupled, where individual services are highly dependent on each other to work properly, to loosely coupled, where services show a high degree of independence. SOA developers strive for loosely coupled services to promote maximum flexibility.

Services must also expose their interfaces, making them available for connecting with other service interfaces in platform-, language-, and operating-system-agnostic ways. Web standards, such as XML and SOAP, lie at the core of this interoperability. Once a service is created, its presence is noted in a services registry, such as a UDDI directory, that enables other services to discover its capabilities and perhaps use it for a business process.

All of this attention to service characteristics and interfaces can provide a big payoff. Developers don't have to rewrite code each time a new or revised application needs to perform a common task, such as locating a customer name. Instead, developers just call that capability from the pool of services already written and plug it into the new project. Process automation tools, such as a BPEL, simplify this process even more, by offering an open standards way to orchestrate services into new business processes.

The overriding goal is to make SOA a driver for achieving business goals, says Rob Kidd, research director for the marketing analysis and services group The Sageza Group. "To do that, you need to have a deep understanding of your core business processes and be able to build various services that serve those processes."

For some, the application integration, interoperability, and reusability SOA promises have been an elusive dream that finally is becoming reality. "We've actually gotten to the point where, conceptually and technologically, applications can be truly flexible," Davydov believes. "I think the industry has reached a plateau that was dreamed about but really not reachable with all of our previous technologies."

Maturing Tools

Helping bring SOA development to the mainstream are a mix of specialized Web services development and management technologies, application server and deployment platforms, and more-traditional IDEs supporting the latest standards. Because the SOA market and specifications continue to evolve, not all vendors have yet developed a complete package, analysts say. "Different vendors are at various stages of capabilities for specific aspects of the SOA platform," says Sandra Rogers, program director for SOA, Web services, and integration for technology research firm IDC. "While the larger platform providers are working on producing holistic SOA environments, some vendors are focused on enhancing business process and integration capabilities and others are concentrating on management and security or providing specific registry-based technologies and development tools."

SOA Lifecycle Download pdf

SOA developers say a good SOA development environment should provide automation without creating a "black box" effect. "If you find a bug in a service, you want full control over the process, so you understand step by step what is going on," says Edmon Begoli, a software architect with the U.S. Department of Energy who's using a services approach to expanding electronic processing in federal e-government applications.

Oracle has been developing a comprehensive set of SOA capabilities, integration and deployment services, and process orchestration, alongside its development and data management technologies. The Oracle JDeveloper interface provides a full view of both the primary services and subservices the SOA application provides. The latest version, Oracle JDeveloper 10.1.3, due out this summer, integrates Web services security standards within the toolkit.

"Developers get the advantage of having the same framework and infrastructure, regardless of whether they're wiring business processes, building back-end services, exposing their Web services, or mapping data between services," explains Ted Farrell, chief architect for application development at Oracle. "It's all the same tool, so you're not constantly trying to move data around to try to share it among different tool groups."

Companies can also create Web services with Oracle Application Development Framework, an SOA environment with prebuilt runtime libraries that implement J2EE design patterns to jump-start J2EE development for people unfamiliar with the platform. "What's interesting in the Oracle Application Development Framework is that it looks at SOA in layers—a model layer, a view layer, a controller layer," IDC's Rogers says. "A tool that 'thinks' about developing a solution in this way lends itself to a services orientation right at the outset."

After they create a service, developers can deploy it with Oracle Containers for J2EE (OC4J), Oracle Application Server's core J2EE runtime engine. The Oracle SOA offering also includes Oracle Application Server TopLink, an object-relational persistence architecture for mapping a schema or tables to Java objects. Oracle Application Server TopLink captures mappings in XML files and supports several persistence models, including Plain Old Java Objects and Enterprise JavaBeans.

Finally, to bring all of these services together into orchestrated business-process workflows, Oracle provides Oracle BPEL Process Manager. Based on the OASIS standard BPEL, Oracle BPEL Process Manager uses a graphical, model-driven approach to help developers integrate and connect the services they have.

No matter how good they are, development tools alone aren't the whole answer to SOA success. Effective services for the real world require a deft development hand. "Through my involvement in the IEEE SOA activities, I have seen a lot of projects using the SOA concept that were not cost-effective," Davydov observes. "Technologically, the projects were interesting, but they did not produce a single dime for the business." Subpar services may result when developers simply translate component-based CORBA IDL interfaces into SOA's Web Services Description Language (WSDL) interfaces, he says. "Developers sometimes use the CORBA mentality, where they create stringent interfaces and then expose them via Web services. But to match the performance of the legacy applications, they needed more-expensive hardware. It becomes a vicious cycle where you're losing money and not seeing benefits." Fortunately, this cycle can be broken with new thinking about how to approach SOA development. According to experts, six factors are key to SOA success.

1. Understand the Business

At Aloha Airlines, SOA-based services provide the foundation for a new generation of customer-centric applications. Burkhart's first SOA-development step is to define key business priorities, including how to better serve customers. To get SOA right, Burkhart confers with his CEO and the heads of various business divisions to hash out what they each need for growing their part of the business. "I make sure I'm involved in the budgeting process of each division, to understand its business needs and business drivers and what it is trying to accomplish," he says. "And from that, I look at what IT functionality we can provide to serve their needs." He then evaluates his technology infrastructure to find its strengths and limitations and creates a technology road map for achieving the organization's business goals.

The Aloha Airlines road map called for a wide-scale hardware upgrade from mainframe clients to Web-accessible PCs and a centralized data repository built on Oracle Database 10g. Those improvements created the foundation for a new services-based passenger booking application built with the help of Oracle JDeveloper. The new booking application uses Web services to integrate Aloha Airline's existing program with a back-end reservations system from EDS.

Burkhart estimates that the whole project eliminated about US$1 million of costs, with an investment of US$100,000, and the resulting efficiencies are saving the airline $1 million annually. "I look at the savings in terms of hard costs," Burkhart says. "It's always nice to paint a rosy picture of the sales and revenue upsides, but if I can take costs out of the operation, I know that those upsides are just gravy."

2. Look Top-Down and Bottom-Up

Before diving into creating services, SOA developers should choose how to make the most of two broad approaches to development. One, the so-called top-down approach, typically applies to building a service from scratch. The second, bottom-up approach works well for extending an existing application to an SOA environment.

SOA's Standards Foundation BPEL (Business Process Execution Language): a standard for assembling sets of discrete services into an end-to-end business process J2EE 1.4: the current version of Java 2 Platform, Enterprise Edition, with APIs for deploying and managing Web services JSR 168: standard for portal and portlet interoperability JSR 181: an API for Web services metadata annotation SOAP (Simple Object Access Protocol): a W3C-approved standard for exchanging information among applications UDDI (Universal Description, Discovery, and Integration): an OASIS-approved standard specification for defining Web service registries WS-I (Web Services Interoperability): an open industry organization promoting Web services interoperability across platforms, operating systems, and languages WS-Reliability (Web Services Reliability): a SOAP-based protocol for exchanging SOAP messages, with delivery and message-ordering guarantees WS-Security (Web Services Security): a SOAP-based protocol that addresses data integrity, confidentiality, and authentication in Web services WSDL (Web Service Description Language): a W3C-approved standard for using XML to define Web services WSIF (Web Services Invocation Framework): an open source standard for specifying, in WSDL, EJB implementations for the Web server WSRP (Web Services for Remote Portlets): an OASIS standard for integrating remote Web services into portals XML (Extensible Markup Language): a data markup language for Web services

The top-down method requires thorough analysis of business requirements, often through a close collaboration between the technical and business staff, to properly define what the service will do and then apply the necessary technical elements to it. By contrast, the initial emphasis in the bottom-up method focuses on a "discovery" phase that analyzes existing software assets to find those that would provide the highest potential benefit to a company if they became a widely available service.

Rather than rigidly adopting one approach or the other, Davydov argues, a mix-and-match strategy may be best for all types of services. "Success really requires taking a best-of-breed approach using both methods," even when exposing existing applications within an SOA, he says. "You can't just say, 'OK, I have a huge inventory of assets, so I'll go through the discovery phase and I'll have a new application.' That's like rummaging through your garage and saying, 'I've got so much junk here, I should be able to find something I can use.'"

The problem with blindly reusing legacy applications is that the code may not be sustainable as business conditions change. "You may need to isolate an existing service so that it is reusable. You may need to enrich it by adding new functionality that will make it usable in other projects," Davydov explains. Similarly, with the top-down method, developers should be constantly thinking about the new service's potential reusability.

3. Push for Quick Results

Although the interoperability and reusability possible with SOA-based services promise quick responses to changing business conditions, Burkhart points out that new applications won't magically appear unless the development process is managed correctly. Burkhart's answer is the 30-, 60-, 90-day approach to application development. "In 30 days, I like to do a proof of concept; after 60 days, I want to be able to look at a pilot; and at 90 days, be in production," he explains. "The market changes too quickly to go off on an 18- or 24-month strategy that's going to have a payoff in year 5. You could be dead by then."

4. Watch Out for Overhead

Once an SOA strategy is in place, it's time to build the services themselves. Today's services typically rely on open standards such as SOAP and WSDL. Adhering to Web services standards eases the development process and helps ensure that the service will run effectively whether the environment is Java or .NET. "Certain services have to be universal and available to very different platforms, and a SOAP-based Web service is probably the most generic choice for those situations," Begoli says.

However, creating a service based on SOAP and WSDL may not always be the only, or even the best, choice. Some situations require a developer to define not just a Web service interface but also a native one. "For example, within BPEL, I can invoke external Web services to get some data and then massage it, transform it, and expose the results to some external services," notes Guus Ramackers, Oracle principal product manager for Web services and UML. "Now, if in part of that process, I actually wanted to call some code I've developed-perhaps I've got an EJB [Enterprise JavaBean] that validates the customer data on my order. A typical approach is to turn the EJB into a Web service and call it from BPEL, which works fine."

Snapshot Aloha Airlines Inc. www.alohaairlines.com Tracing its roots to 1946, when it began business as Trans-Pacific Airlines, Aloha Airlines now offers 629 inter-island flights to five cities on the Hawaiian islands of Hawaii, Kauai, Maui, and Oahu. More than 140 flights a week connect the islands with U.S. cities in California and Nevada as well as with Vancouver, BC, Canada. The airline is one of Hawaii's top employers, with a workforce of more than 3,600 people. Location: Honolulu, Hawaii Industry: Airline Oracle products and services: Oracle Database 10g, Oracle Application Server 10g, Oracle Portal, Oracle JDeveloper, Oracle Application Development Framework, Oracle UIX

However, this approach creates processing overhead, because as the Web service call is made, the program creates an XML message that travels across the network. "When the message reaches the receiving end, you need to map again to bind to the implementation. In this case, if I have the implementation locally, I don't really want to go to Web services, because that gives me all that SOAP and XML processing. That just takes time," adds Ramackers. Instead, developers can use Web Services Invocation Framework (WSIF), an open source standard for specifying in WSDL that there are EJB implementations for the Web server. "And then at runtime, the service is going to invoke the Java class in EJB, but it's not going to create all the XML," Ramackers says. "Web services are a good thing and a good way of standardizing your contract, but sometimes through a WSIF binding, you can get faster performance."

5. Plan for the Future

One of SOA's strengths is that the Web services developers build aren't limited to a single project; the services can plug into multiple projects if people plan for interoperability at the start of the development cycle. But this requires developers to think ahead, even if initially they anticipate only limited use of the software. "You may believe that your application will be used by only, say, 10 concurrent users, so why worry about these things?" Davydov says. "The reality is that if you create a very attractive service, it may be used across the entire enterprise. So instead of 10 concurrent users, you may eventually see thousands. You always need to look at your services in a larger context."

Next Steps DOWNLOAD Oracle JDeveloper Oracle Application Server Oracle BPEL Process Manager

Some developers believe that if they build a Web service with SOAP and WSDL, it will become interoperable in any platform. But it's trickier than that. "The tendency of developers was to focus on the technology. There's a kind of myth that if you use a WSDL interface, the service itself becomes reusable," Davydov says. "Yes, there is a published API in the form of a WSDL interface. But how the interface is constructed; what data the service is looking for; and, accordingly, what data is returned to the service may not necessarily be viable for any other project."

Debu Panda, principal product manager for Oracle Application Server Containers for J2EE, advises developers to think about datatypes as they strive for interoperability. For example, some datatypes used in Java environments may be unavailable in other platforms, such as .NET. "You have to use a datatype that's supported by all platforms if interoperability is important to you," Panda explains. To avoid a problem, developers should adhere to the set of interoperability guidelines encompassed in the Web Services Interoperability Organization's WS-I Basic Profile. The open standards organization, created by Oracle and other SOA technology vendors, also offers a testing tool for gauging a Web service's cross-platform compatibility in Java, .NET, Linux, UNIX, or Windows environments.

6. Find Big Payoffs in Small Steps

Finally, enterprises that see the future in SOA should develop a long-term SOA strategy, and then work in incremental steps, advises Begoli. "I've seen some gigantic efforts by companies trying to apply Web services standards to every possible aspect of enterprise computing," he says.

In contrast, Begoli's approach is to identify key strategic services that have long-term importance and incorporate those applications into an SOA environment first, rather than trying to conquer every possible problem through Web services. "It's a two-pronged approach. First, have the enterprise mind-set and understand the global scope of SOA. And then, second, as you gain small victories, you can have a big gain by increasing the awareness of why the SOA approach is important."

"Grid-ifying" SOA SOA applications are a smooth fit with grid computing, because at a high level, both adhere to a common sensibility: Higher performance and flexibility come about when you split up computing resources into small, specialized components. "Individual applications, components, or services deployed onto a set of hardware boxes can scale individually according to your needs," says Mohamad Afshar, director of product management for Oracle Application Server. "Imagine you have one huge locomotive that pulls one huge passenger-carrying carriage. The huge carriage isn't always full, so lots of fuel is wasted. If you replace the large locomotive with three smaller ones, you can take one of those locomotives off the train when there aren't many people and still run your single carriage with two smaller locomotives. You could go further and design your train so that it consists of 10 small carriages for carrying people and 2 for carrying cargo loads. "This kind of flexibility, in which your locomotives (hardware) can be removed or added as required and your carriages (software services) can also be removed or added as required, is analogous to designing and deploying service-oriented apps on the grid," adds Asher. To help developers create services for grids, Oracle Application Development Framework extends the model/view/controller (MVC) architecture used in Java development, by adding a service layer that can pull services and data from any location, says Guus Ramackers, Oracle senior principal product manager for Web services and UML. The service layer accommodates a wide variety of development platforms, including Java, Enterprise JavaBeans (EJB), Oracle Business Components, Java Connector Architecture, and Web services. Using WSDL, developers can launch the resulting service as a grid service. If the service will not only run within an internal grid but also will extend through a connection to an external grid, developers can take advantage of the interoperability standards encompassed in the Open Grid Service Infrastructure (OGSI) protocol, from the Global Grid Forum. The OGSI offers a grid-optimized version of WSDL known as GWSDL. Once services are launched in a grid environment, administrators can use Oracle Grid Control, part of Oracle Application Server 10g, to centrally manage the software components. Oracle Grid Control aids computing-resource allocation by allowing for dynamic replication of services, depending on demand. "We are now in a flexible world of grid, where you can determine how much processing you want available for each application group, which is a set of services," Ramackers says. Future Efficiencies The interoperability and reusability of SOA services become easier to achieve each year, as standards organizations introduce extensions to their specifications, and 2005 should be no different. By year's end or early next year, the new J2EE 5.0 specification should arrive. Debu Panda, principal product manager for Oracle Application Server Containers for J2EE, says an aim of the standard is to simplify SQL development by using defaults and metadata annotations and drastically reducing deployment descriptors. This will include JSR 181, an API for Web services metadata annotation, which will hide many of the current complexities developers face when creating interfaces, deployment descriptors, and other Web services elements. J2EE 5.0 will also include the new Enterprise JavaBeans 3.0, which will apply a similar defaults and metadata-annotation strategy, for making EJB creation easier. "To build a simple EJB now, you'd need to specify two interfaces, one bean class, and one deployment descriptor," Panda says. "You have to use several EJB-specific APIs to do this." Version 3.0 will eliminate the need to implement any EJB-specific interfaces, such as a session bean or an entity bean. "So it will be a pure Java class," Panda says. "If you want it to be a stateless session bean, just add a 'stateless' annotation, and you won't need a deployment descriptor or many interfaces. The developer's life is going to be made much simpler." Blueprint for SOA Success SOA developers can jump-start the services-creation process with the help of a set of blueprints developed by The Middleware Company and a group of SOA technology vendors, including Oracle (see www.middlewareresearch.com/soa-blueprints/). The blueprints build services for a hypothetical company and take developers step by step through the application integration process. The examples provide guidance for a range of services environments, including J2EE, .Net, and Web services.