Imagine, if you will, the following exchange:
CIO: You know, I've been reading a lot about this whole service-oriented architecture thing.
WebLogic Developer: And...?
CIO: It sounds pretty cool, I really think we need one.
WebLogic Developer: OK...sure, we'll get right on that.

There is no question that service-oriented architecture (SOA) is quickly becoming one of the hottest trends in enterprise computing. IT departments are inundated weekly, if not daily, with the claims and marketing messages of vendors announcing myriad technology and service offerings that will magically transform the way business gets done.

At the same time, the growing acceptance of service orientation and SOA as enterprise computing methodologies is driving a profound shift in how organizations view their IT infrastructures. Replacing complex, monolithic applications with nimble applications built from exposed services promises increased developer productivity, greater flexibility, and ultimately, reduced cost. The adoption of Web services and SOA can also remove a significant level of complexity and integration problems from enterprise application development projects.

But, as with any large-scale project with the potential for significant impact, IT departments must have the right plan and the right resources in place to ensure a successful transformation of their computing infrastructure. The biggest stumbling block facing most IT organizations is not whether to move toward an SOA, but determining the best approach and appropriate level of investment for doing so.

Defining the Service-Oriented Architecture
A service-oriented architecture (SOA) is a blueprint that guides all aspects of creating and using business services throughout their life cycle (from conception to retirement), as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes regardless of the operating systems or programming languages underlying those applications. With the advent of Web services, it has become easier to accomplish this without becoming tied to any one specific approach (data-oriented, message-oriented, object-oriented, procedure-oriented, etc.)

The primary goal of any SOA is to help align IT capabilities with business goals. Migrating to an SOA helps organizations streamline the design and development of solutions, makes it easier for remote teams to collaborate, and enables reuse through module reconfiguration and repurposing.

Above all, SOA is an approach to building IT systems; it is not a single technology or a silver bullet solution. SOA is a methodology whereby business services (i.e., the services that an organization provides to clients, customers, citizens, partners, and other organizations) are the key organizing principles that help align IT systems with business services. Most importantly, the services are defined in a manner that is independent of the underlying technology. In contrast, earlier approaches to building IT systems that relied on approaches such as object orientation, procedure orientation, and message orientation resulted in systems that were tightly coupled to the capabilities of a particular technology such as CICS, IMS, CORBA, J2EE, COM/DCOM among others, and were therefore less generic to the business. Development following these methodologies and approaches often resulted in the monolithic, stove-piped applications found in the majority of today's IT systems.

Service orientation with Web services reduces enterprise integration project cost and improves project success rates by adapting technology more naturally to the people who need to use it, rather than focusing (as previous generations of IT systems have) on the technology itself, which forces people to adapt to the technology. The major difference between service-oriented integration and the other approaches is that service orientation lets you focus more on the description of the business problem, while the other approaches require you to focus more on the use of a specific technology to solve a particular integration problem.

Technology-oriented approaches are limited, by definition, to the capability of a single product or technology. The service-oriented approach with Web services is not based on the capabilities of a single technology, technology type, or product, but on designing and deploying services capable of executing on any technology type. Developers of service-oriented integration projects, therefore, can focus more on the business problem than on the technological problems, since Web services are widely available as interfaces to nearly every technology type. The right technology can still be chosen for the execution environment, but to the service consumer, the execution environment technology is irrelevant since they are dealing with the Web service description rather than the execution environment.

As illustrated in Figure 1, the eventual goal of designing, developing, and implementing an SOA is to provide new and better ways for applications to talk to each other, and to integrate with a business process engine, and multiple client types. The diamonds on a stick represent the Web service interfaces, which are either developed from scratch with, for example, new Java code, or retrofitted using a Web services infrastructure product. Once developed, the Web services are accessible using the common SOA service transport. Any new application or new client wishing to use the service obtains the description from the service repository. A business process engine (often called an orchestration engine) can also access the Web services after they are designed and developed to automate flows.

Businesses that successfully implement a service-oriented integration approach using Web services to obtain these benefits are likely to have a competitive advantage over those who do not, since those who have services aligned with strategic IT business goals can react more quickly to changing business requirements than those who have IT systems aligned to a particular technology orientation.

The concept of SOA isn't new, but what is new with Web services is the ability to mix and match execution environments, separating the service interface from the execution technology, allowing IT departments to choose the best execution environment for each job (whether it's a new or existing application), and tying them together using a consistent architectural approach.

Implementing the SOA
Once you have decided that service orientation and SOA with Web services is the direction in which you want to move your IT systems, you need to determine the best way to accomplish this. Even if you are a dedicated WebLogic/J2EE shop, Web services are still the best means for implementing an SOA because they are based on a set of technology standards that are independent of any particular software domain, development process, or design method. Web services, therefore, have the potential to significantly extend the reach of the WebLogic platform.

BEA WebLogic can easily be used as the design center and for the development of new code where it's needed. It can also be used to tie together a wide variety of existing systems using Web services. When existing systems are exposed through Web service interfaces, they can easily be combined into powerful business process flows and new applications.

Web services can be applied in a variety of ways to address a number of problems. SOA brings architectural vision, development guidelines, and design methods that increase the likelihood that Web services will be applied in a strategic manner to add long-term value to the organization though agility and reuse.

Figure 2 illustrates the distinct benefit of using SOA with Web services for multi-channel access to the same application. In this example, an existing customer service application is Web service enabled using an infrastructure product, and accessed as a reusable service from the account manager's cell phone, the customer's mobile device, the customer service manager's laptop, the call center operator's PC, and the reseller's service application. Using WebLogic in conjunction with a Web service enabler such as Artix extends the reach of existing applications to new applications and devices. Web services contribute to agility because they can be designed and reused across multiple business processes so that any user can access them at anytime from anywhere and using any device. Web services are reusable when they are designed and implemented according to enduring business themes rather than being tightly coupled to a particular implementation.

Long-Term Value
The real value of SOA comes from the later stages of deployment, when new applications can be developed entirely, or almost entirely, by composing existing services. When new applications can be assembled out of a collection of existing, reusable services, the best value for effort can be realized (that is, the lowest cost and fastest time to results). But it takes some time to reach this point, and significant investment in service development.

It's more likely that new applications will be constructed out of some number of reusable business services (such as order item, check credit card authorization, process invoice, etc.) and some number (hopefully smaller) of custom services developed specifically for the application (such as helping the customer decide on a purchase of remaindered books). <y company's customer field experience using SOA with CORBA indicates that a reuse level of about 70% is achievable, and the industry could expect the same, or possibly better, with Web services.

In general, it is easy to understand the benefit of reusing common business services such as customer name lookup, ZIP code validation, or credit check. In what you could call the pre-service-oriented development environment, these functions might be performed by reusable code libraries or objects loaded/linked into new applications and thus reused (although duplicated). In SOA-based applications, common functions such as these, as well as typical system functions such as security checks, transaction coordination, and auditing are instead implemented using external services. Using services external to the application not only reduces the amount of deployed code; it also reduces the management, maintenance, and support burden by centralizing the deployed code and managing access to it.

A New Development Approach
As many readers are aware, the software industry has widely adopted the paradigm of service-oriented development as the way in which to best take advantage of the power of Web services for application integration. However, it needs to be clear that service-oriented development truly implies a new, complementary approach to the object-oriented, procedure-oriented, message-oriented, and database-oriented paradigms that preceded it. While service-oriented architecture isn't new, its availability as an abstract Web services layer to any executable software system is, and therefore, service orientation is emerging as an important new development model that needs to be understood and adopted as it applies to a uniform service abstraction mapped to any or all of these prior technologies.

Developing a service is different from developing an object. A service is defined by the data it shares using messages exchanged with other services, not by the definition of a common method/argument signature. A service must be defined at a higher level of abstraction (some might say at the lowest common denominator) than an object since service definitions are mapped to a procedure-oriented language such as COBOL or PL/I, or to a message-queuing system such as JMS or MSMQ, in addition to an object-oriented system. Because a Web service needs to be able to operate across all of these technology domains, its development requires some study and new thinking.

On the development side, it's necessary to understand the granularity at which the service is to be defined. Web services normally require a larger-grained interface that accepts more data in a single invocation than an object. With Web services, however, it's possible to create an aggregation of Web services such that the published Web service encapsulates multiple other Web services. This allows a coarse-grained interface to be decomposed into a number of finer-grained services. The coarse-grained service may make more sense to publish while the finer-grained services may make more sense as "private" Web services that can be invoked only by the coarse-grained Web service.

Figure 3 illustrates another major benefit of using Web services for an SOA: the ability to create a composite application. The WebLogic platform shown on the left side of the diagram can be used to access the Web services shown on the right side, which represent a mixture of services developed using new Java code and services enabled using other technologies. The customer record service exposes two services that are composed of other services.

On the project level, it's necessary for an architect to oversee the development of reusable services, and identify a means to store, manage, and retrieve service descriptions when and where they are needed. The reusable services layer insulates business operations such as "get customer" or "place an order" from variations in the underlying software platform implementations, just as Web servers and browsers insulate the World Wide Web from variations in operating systems and programming languages. The ability of reusable services to be composed into larger services easily and quickly provides the organization the benefits of process automation and agility to respond to changing conditions.

Developing the SOA
Two major phases of activity are required for developing a well-understood, managed, and deployed SOA project based on Web services. These phases center on identifying services that must be:

• Developed using new execution environments: Require the development of new application logic in Java classes and EJBs to run in WebLogic application server containers.
• Enabled from existing application logic: Require the use of a Web service-enabling toolkit adapted for use with the existing technology, and are integrated either directly with the new application code using Web services invocations, indirectly the WebLogic integration server, or both.

A combination of tools may be required to enable all the Web service endpoints to be included in the SOA. For example, IONA's Artix could be used to enable Web services for TIBCO, MQ Series, CICS, IMS, CORBA, and other existing systems, and integrated with new logic developed using WebLogic. Alternatively, Web services capabilities may exist in newer versions of these products, and it may make sense to expose or enable the existing applications by installing or upgrading the existing software to a newer version that supports Web services and use them, instead. However, this approach is vulnerable to potential incompatibilities among multiple Web services implementations, and the complexity of managing multiple Web services products.

A variety of Web service-enabling toolkits are available through independent vendors and open source projects. Therefore, one of the key decisions in your SOA implementation is dealing with the combination of technologies that will be involved. In an enterprise-wide SOA project, it's typical that several different, often widely varying, technologies will be involved, with varying qualities of service.

In developing services for an SOA, first you decide that you need a service, then design the service to be compatible with the other services you are developing. And finally, as illustrated in Figure 4, you decide among the possible additional quality of service requirements for reliability, security, and transactions you might need. It's necessary to check the Web service products you are using to ensure compatibility not only at the basic SOAP and WSDL level, but also at the level of these extended features.

The starting point for service-oriented development is to identify the data to be shared. That becomes the XML Schema representation of the data types and structures to be contained in the message. Web services provide two basic styles of interaction:

• Document oriented: The message is structured as a "plain" XML document (in other words, the data is just laid out in a way that makes sense for XML).
• RPC oriented: The message is structured as a series of arguments to be passed to an object or procedure method, typically matching the data types and structures.

In the first case, messages are typically used to carry business documents such as purchase orders, invoices, and bills of lading. This style of interaction is very compatible with asynchronous message queuing systems such as MQ Series, MSMQ, JMS, TIBCO, IMS, and others. It is often used for business-to-business transactions that depend upon the exchange of large amounts of data to be processed in an execution flow that might take hours or days to complete, resulting in an executed document or a new document to be passed back to the originator. This style is also the most abstract since it says nothing about the nature of the signature on which the message is to be mapped within the execution environment. The RPC-oriented style, on the other hand, assumes that the data in the message is to be executed by a procedure or object with a defined interface, and the RPC-oriented formatting of the XML in the message is designed to make it easier to map into and out of such existing constructions.

However, like everything else in computing, there is more than one way to accomplish the same task. Most of the interoperability issues arising from varying Web services toolkits and products stem from incompatibilities in mapping the complex data types and structures such as arrays, records, and structures. In other words, the more simple the data type, the more likely you are to achieve interoperability.

As a rule, Web services products are more compatible the more general their use - for example, the WS-Interoperability Basic Profile recommends using the doc literal encoding style (i.e., the plain XML schema data types and structures) rather than the SOAP encoding style (which basically defines new data types and structures that are more compatible with existing RPC-oriented technologies). The doc-oriented interaction style is more abstract than the RPC-oriented style, since the SOAP processor and XML parser pull out the data of interest to the application and pass it to the queue or object. When it's data formatted for an RPC, knowledge about the types in the arguments is necessary to be able to decode and understand the message.

A necessary step in the design and development of any SOA is the identification of requirements for extended technologies. WS-Security, WS-ReliableMessaging, and WS-Transactions, among other specifications, have been defined to address these requirements, but their availability in WebLogic and other Web services tools, and the Web services interfaces to existing products, is limited, as is the interoperability across the extended feature set. The more extended the features you use, the harder interoperability is to achieve.

Facing Challenges
SOA-based integration provides a consistent way to access all applications within a company, and potentially outside the company. The challenge represented by implementing an SOA is that some applications may need to be modified in order to participate in the SOA. In addition, the definition of a reusable service is very difficult to get right the first time.

The largest barriers to adoption of SOA tend to be ensuring adequate staff training and the fact that implementing an SOA requires a disciplined level of investment for the future. Any technology, no matter how promising, can be abused and improperly used. Services have to be developed, not simply for immediate benefit, but also for long-term benefit. Unlike objects or databases, a service is developed for use by its consumer, which may not be known at the time. To put it another way, the existence of an individual service isn't of much value unless it is part of a larger collection of services that can be consumed by multiple applications, and out of which multiple new applications can be assembled. Any collection of services needs control, design, and architectural purpose since they are typically not all developed at the same time.

The main challenge of moving to an SOA is managing short-term costs. Building an SOA isn't cheap; reengineering existing systems costs money, and the payback becomes larger over time. It requires including business analysts to define the business processes, systems architects to turn processes into specifications, software engineers to develop the new code, and project managers to track it all.

Of course, incrementally adopting SOA and leveraging it where it will have the greatest business impact can amortize these costs when services can be used to solve tactical problems first. Part of adopting Web services and SOA, therefore, is to identify those projects which return immediate value by solving an immediate problem (such as integrating J2EE and .NET Framework applications), but also lay the foundation for strategic value in the future through reuse, such as creating a new order entry application more quickly because it can reuse services for credit checking and billing.

Another challenge of realizing the SOA vision is that current applications are tightly coupled while the underlying SOA technology is loosely coupled. Therefore, it may not be possible - at least not in a cost-effective manner - to immediately achieve loosely coupled perfection given the existing environment of tightly coupled, business-critical applications. It may be necessary to start with fine-grained, tightly coupled Web services to meet immediate project requirements, but this should only be done within the context of an overall long-term plan to develop coarse-grained services that encapsulate the fine-grained services.

Conclusion
So, you want an SOA built on Web services in a WebLogic environment. If this is a task you and your IT department are facing, the good news is that it can be done. With the proper expectations, strategy, planning, and execution, you can start now to migrate your enterprise to take advantage of this computing methodology today and well into the future. It's important to take into account the difference between Web services that require new Java code, and those that expose the capabilities of existing applications. Using WebLogic in conjunction with enterprise Web services infrastructure products can help extend the reach of WebLogic-based SOA projects by more easily handling the Web services based on existing application code, whether on the mainframe, Unix, or an established middleware system.