ViewPoints

SOA: Integrating XML and Web Services

A primer in Web Services and XML (Extensible Markup Language)
By Peter Classon, Principal Consultant Jatinder Prem, Technology Manager

LiquidHub, Inc.

500 East Swedesford Road

Suite 300

Wayne, PA 19087

484.654.1400

www.liquidhub.com

ViewPoints
Topics covered in this paper include:
Defining Web Services Web Services Architecture and Characteristics XML as a Foundation for Web Services Standard Protocols of Web Services Value Proposition of Web Services Challenges facing Web Services Action Steps

1. Executive Overview
As discussed in previous Horizons White Papers, Service Oriented Architecture (SOA) is becoming the IT architecture of the future. While not groundbreaking technology in and of itself, SOA fundamentally shifts how businesses and IT organizations attack business problems and the technology architecture that is constructed to solve these problems. Service Oriented Architecture can be thought of as a collection of applications, or services, that are connected via a communications network that can be either inter- or intra-company. While this architecture framework is not new, emergence of applications called Web services in SOA is truly exciting. Figure 1 below demonstrates how business logic is exposed via a business service layer.

Figure 1: 3-Tier vs. Service Oriented Implementation (Adapted from Microsoft)

2

ViewPoints
Previous attempts at a service oriented architecture where hampered by several factors. A lack of commonly accepted interface definitions, the inability of applications to dynamically portray their functionality and communication methods, and a multitude of data and transport mechanisms, made true service architectures unattainable. The emergence of a class of applications called Web services over the last two to three years, addresses these hurdles by providing standards around the transportation, messaging/data of services, and the description of services. In addition, Web services capitalizes on the reuse of applications/code. The transportation of services relies on Internet technologies such as HTTP and HTTPS, which allows for exchange of information between services. The actual data being passed between services are encoded in a format known as Extensible Markup Language (XML). Each Web service also contains descriptive text that other services utilize to interpret the functions the service is capable of, based on messages the service can send and/or receive. In addition, Web service descriptive text can include software that makes the service definition available in a searchable format. Many IT organizations are striving for stronger governance, common architectures, and uniformed development platforms. SOA and Web services, however, should not be thought of as simply an IT initiative. Rather, business drivers such as the power of consumers (customers ability to access data and the volume of data that is available), a need for more efficient value-chains, and an ever increasing need for speed to market is really what is at the root of the SOA and Web services initiative. Leading business and IT research concedes that true SOA and end-to-end Web services architectures that span both application-to-application (A2A) and business-to-business (B2B) integration are still three to five years from reality. This, however, should not be seen as a reason for a wait-and-see approach. Rather, leading businesses and IT organizations are currently defining their Service Oriented Architectures, inventorying their list of applications, and identifying business processes or existing systems that can be used to prototype a Web service applications. The balance of this document presents a more detailed discussion on Web services and the components that make up Web services. A more detailed discussion of XML is included to highlight the importance of this encoding standard to the emergence of Web services. Finally, the value proposition of Web services, current challenges, and some suggested action steps are provided.

2. Web Services Defined 2.1. Hype vs. Reality

Web services are poised to either transform the Internet or be the next over-hyped failure. These services have been met with both enthusiasm and skepticism by the business and technology communities; enthusiasm based on the hope that Web services will greatly reduce application integration and development costs and understandable skepticism when presented as a panacea. However there is a growing role for Web services that balances the enthusiasm and skepticism. To realize that role, it is necessary for an organization to understand the strengths and weaknesses of Web services prior to its inclusion in any Enterprise Architecture solution. Web services do not make the claim to be all things to all people. Rather, it follows the Simple is Better theory that has made the Internet a success with flexibility and the open standards model. With this thin

ViewPoints
approach and inherent simplicity, Web services are positioned to make a significant impact on Enterprise Architectures. Web services are not revolutionary, but evolutionary, providing an incremental step in future implementation of Internet technologies. As IT organizations continue to evolve their Internet and IT infrastructures, there is an increased realization of the growing need for sharing applications and data across and outside of the enterprise. Todays software development metrics are mostly concerned with speed-to-market of new or extended applications. Evolving metrics used to measure the success of software development are developing. These include how quickly and seamlessly business processes, data, information and knowledge can be leveraged across the enterprise, regardless of the source, in order to make real-time decisions. This new paradigm has been coined the Time-to-Share objective. It measures how quickly business process, data, information and knowledge can be shared (inter or intra organizationally) as opposed to time-to-market, which measure how quick an application could be made available. The realization that many organizations today have a strong foundation of applications and data stores is driving the idea of accessibility being more critical than availability.

2.2. Web Services Definition

Web services can be thought of as a technology approach that is well-suited for bridging information systems. Web services can enable this integration even if systems are implemented on disparate platforms or through differing technologies. Organizations that are looking to enhance their value propositions by revealing their core competencies through a suite of interoperable software solutions, which may exist internally or externally to the enterprise, are turning to Web services as a solution. To facilitate this approach, one can picture a Web service as a self-contained, coarse-grained (meets a specific business need by combining available components, interfaces, and data access), self-describing, loosely coupled programmable component that can be exposed as a service-oriented system on a network and invoked (utilized/) across the Web (Intranet, Extranet, or Internet). Web service functionality is made possible by one or more methods that handle incoming messages and can be document or procedure oriented. A Web service can be a stand-along service/application or work in concert with other services to provide an entire solution or suite of services. Web services architecture differs from traditional object-oriented components in that it is a network-centric, services-oriented architecture versus traditional interface architectures that use object-oriented technology and rely on object-specific protocols (e.g., CORBA over IIOP, COM over DCOM, and Java over RMI). Web services architecture is governed by a World Wide Web Consortium (W3C) Working and Interest Group appropriately named the Web Services Specification Working Group When defining Web services, it helps to think of a Web service in terms of four key characteristics. All Web services, by definition, must contain these four characteristics: A Web service must expose and describe itself in terms of functionality and attributes, in order for other Web services and applications to determine how interactions with the service are enabled. A Web service must be registered in a public or private access directory service that allows for discovery of the service in a network (or Internet) environment A Web service can be invoked through a declared API (method) over a network using ubiquitous Web protocols, for example HTTP. A Web service always returns a response to an invoking entity (e.g., another service or an application).

ViewPoints
2.3. Architecture Overview
The Web services framework is categorized into three typical systems or runtime environment components that have been identified in prior A2A protocols. XML is the common component by which the environment components communicate. The promise of the Web services architecture framework is that each environment layer is defined through W3C standards and made accessible through mature Internet-transport technologies. The layers of the Web services framework environment are:

Figure 2: Web Services Layers Service Transport Network protocols that include, but are not limited to HTTP and HTTPS that enable Service Requester and Provider components to exchange Service Messages. Service Messaging Mechanism for encoding and decoding Web services messages to be transported between Service Providers and Requesters. Messages are encoded via XML in accordance with the Simple Object Access Protocol (SOAP) specification. Service Description Mechanism that allows a Web Service to define the actions it is capable of performing via messages it can receive and/or send. This information is readily available to Service Requesters and is defined in accordance with the Web Services Description Language (WSDL). The Service Description layer may also include Universal Description and Discovery Interface (UDDI) software that makes Web Service and Service Provider WSDL information available in a published and searchable format. The Service Description layer is not a required layer in a Web services environment. Service Provider - Software that hosts access to a service such as an Application Server. Service Requester Any application that requires specific data or functionality offered by a Service Provider and ultimately presents the results to the consumer such as a portal, for example. Note that, while not a requirement of a functional Web Service, the Service Description layer provides functionality to detect and inspect a service prior to its use. Since service requester and provider specifications were built at the same time by the same W3C group, Web services promises to offer more service connectivity without prior service knowledge.

ViewPoints
It is also important to understand that while the W3C Web Services Working groups publish the specifications, vendor implementations provide extensions to distinguish their software in the market place bringing additional value to their customers implementations. Examples of these extensions can be seen in enhancements that IBM, Microsoft, and other vendors have provided making Web services more secure, more reliable, and more transaction-centric. Often, such enhancements are added to the W3C specifications. Typically, the base functionality described in the W3C specifications is supported along with vendor-specific extensions that support interoperability across vendor implementations.

Figure 3: Web services Operation & Flow In the scenario described in Figure 3, the interactions between the roles and operations are defined as follows: A Service Provider host defines a service description for a Web service and then publishes it to a service requestor or service registry (registry can be private or public depending on the intended usage of the service). The Service Requestor is an organization that requires certain functions to be satisfied or an application that is looking for and invoking or initiating an interaction with a Web service. A Service Requestor seeks to find the service description (also known as meta data) of Web services via the Service Registry. The Registry contains enough information for a Requestor to bind to a Provider. The bind operation is the process that allows an application to connect to a Web Service at a particular network address and start interacting with it. The Service Registry is accessible and searchable by Requestors and contains service descriptions published by Providers. Requestors use the Registry to find the service descriptions of Web services. The descriptions provide the information necessary for Providers and Requestors to bind.

2.4. Types of Web Services

The types of Web services differ in the mode of communication employed: synchronous (real-time) or asynchronous (batch mode).

ViewPoints
Synchronous Web Services Also known as simple Web services, synchronous Web services implement a call-and-response Remote Procedure Call (RPC) mode of interaction. In this mode, the caller invokes the Web service, and the business logic behind the Web service executes its behavior while the caller waits for the business logic to complete its operation and return a response or result before proceeding. This is known as a synchronous mode of communication. When the business logic is complete, the Web service will return the results to the calling program or the Web services consumer. During the time that the Web services business logic is executing, the Web services consumer thread is blocked and cannot do any other work. Synchronous processing is appropriate for simple coarse-grained business processes, like tax rate calculations. In other more complicated situations, such as inventory management, document routing (e.g., EDI or industry specific XML formats), or resource intensive transactions that span multiple applications, the blocking time for the Web services consumer could be unacceptable. In these situations, releasing threads (i.e., freeing up connections to services and applications) is important as many processes/services are running concurrently within one large system. Figure 4 below illustrates a simple (synchronous) Web service for tax rate calculations.

Figure 4: A simple RPC Web service invocation

Asynchronous Web Services

Complex business logic or resource intensive processes require an asynchronous communications mechanism rather than the simple synchronous mechanism currently implemented by most Web service producers. In an asynchronous model, the Web service request is handed to the Provider, which allows the Web service client (Requestor) to continue other processing while the producer (Provider) processes
7

ViewPoints
the request. The client in this case does not need the result of the service call, not even an error response, to continue. The Web service Requestor can be instructed to check back with the Provider after an elapsed amount of time, to determine if processing is complete. For certain processing, where the duration is unknown or variable, the Web service can be configured as a listener, meaning the Requestor listens for a completion message or sends callbacks to the producer until processing has completed. Some examples where asynchronous, also known as complex Web services, are appropriate include: Settling payments; Obtaining a credit score or rating; Performing intensive computing tasks; or Responding to data mining requests Figure 5 illustrates an asynchronous Web service using a message-driven bean (provides for asynchronous message processing) for executing business logic and JMS (Java Messaging Service) to effect acceptance and delivery of client arguments or data.

Figure 5: Asynchronous Web service

3. XML as a Foundation of Web Services 3.1. Introduction

Extensible Markup Language (XML) is a text-based universal format for data exchange. It provides the ability to structure, optionally validate, and transform data thus allowing it to be used across various applications in a platform independent manner. The term Extensible refers to the capability of being able to add or change components of a message while the phrase Markup Language refers to the set of conventions used for encoding textual information. A markup language specifies what markup is allowed, what is required, how the markup language is distinguished from textual data, and the meaning associated with the markup. XML and its associated technologies provide the mechanism to generate robust, exchangeable, and meaningful data structures.

ViewPoints
3.2. XML Model
XML is a text-based markup language, a subset of Standard Generalized Markup Language (SGML) and is similar in appearance to HTML. XML (as with HTML) has its base functionality controlled and maintained by World Wide Web Consortium (W3C) working groups. XML as a flexible text-base markup language does not contain a fixed tag set and allows tags to be defined by the application thus emphasizing the meaning of data. XML describes the structure of data where as HTML describes how data should be displayed. Data defined through XML documents can optionally use a component known as a Data Type Definition (DTD), Extensible-Data Reduction or an XML Schema Definition (XSD) to describe the data and provide meaning by describing and enforcing the data tag structure for an XML document. Following this thought process, there exists the concept of a document type within XML. Further, a component known as Extensible Stylesheet Language (XSL) can be applied to an XML document to transform documents to HTML or other output formats for presentation or transformation to other XML formats. Figure 6 presents an overview of the XML model components.

Figure 6: XML Components Model The structure of the document creates the concept of a document type that is effectively defined by the data structure it contains. XML documents of known document types can be processed by special purpose programs that can programmatically check the data structure of a given document type. Such special purpose programs are referred to as parsers and are used to ensure XML documents conform to the structure of the document type as well as to ensure the existence of elements, attributes and that the order in which they appear is valid. These XML document structures are comprised of a simple and consistent identification of XML textual structure.

Elements
XML, like HTML is comprised of elements, or textual units that are structural components. Like HTML, XML is comprised of different types of elements using different names. Unlike HTML, an XML author can select names for different types of elements. However there is no way to express the meaning associated with an element name other than its relationship to other elements within the document. XML is not concerned with the semantics of elements, as these are completely application dependent. Elements are used to describe fragments of content that comprise the document, typically more than a few words in length. It is up to the authors of the XML document and its associated vocabularies to choose meaningful

ViewPoints
names for the elements they identify and to define their proper use in text markup. As will be described later, less significant information or behavioural attributes are described using attributes. Within an XML Document, each element needs to be marked (or tagged) in some manner similar to HTML. XML elements are made up of a start tag, an end tag, and information, or content, between them. The example in Figure 7, below, is a simple structure representing a collection of DVDs. Within the collection we identify DVDs, their titles, genre, rating, and runtime information. XML terminology defines the document type as digitalversatiledisks consisting of a number of digitalversatiledisk element occurrences having embedded title, genre, rating, and runtime elements. <?xml version=1.0?> <digitalversatiledisks> <digitalversatiledisk> <title released=2002>Pirates of the Caribbean</title> <genre>Action/Adventure</genre> <rating>PG-13</rating> <runtime>143</runtime> </digitalversatiledisk> <digitalversatiledisk> <title released=2003>The School of Rock</title> <rating>PG-13</rating> <runtime>108</runtime> </digitalversatiledisk> </digitalversatiledisks> Figure 7: DVD Collection Example The DVD Collection example is considered to be a well-formed XML document based on the following list of rules: An XML document has one or more elements with a single element containing all other elements nested within it and in which each element is completely contained by its parent element. Tags marking the start and end of an element must be present except for special cases in which they are combined (e.g., when the tag contains no other tags an empty tag).

Attributes
It is often necessary to describe details regarding an element that the name and content is unable to convey. Attributes are used to provide this functionality as a string of text following the element opening tag text and a space. The attribute is then followed by an equal sign, single or double quotes and the associated attribute value. In the example, the title element contains an attribute named released that provides the year the movie title was released. Typically, attributes are used when the need exists to restrict the potential values. Attributes may also be useful when the value modifies the associated element in a fashion that would effect processing, yet is not part of the element content.

3.3. Importance to Web Services

XML is an accepted standard by industry market leaders making it a viable enterprise-to-enterprise strategy. XML technologies enable enterprises to define cross-application information exchange standards
10

ViewPoints
through standardized XML Elements and Attributes. This standard use should include mechanisms that enable applications to alter functionality based upon the information. XML will lead HTML to XHTML that contains elements of HTML and conforms to the rules of XML. In addition to syntax, XHTML explicitly provides meaning to its defined tags. XML is useful for a variety of data exchange applications and is a foundation technology for such enterprise strategies as Web services and likely has a future in your enterprise.

4. Web Services Protocols

Web services are a platform-independent, standards-based means for achieving asynchronous access to applications in a heterogeneous distributed environment. To facilitate this model for connectivity and interoperability, Web services leverage the industry standard protocols described in the following sections (figure 8 provides an overview of the three main protocols).

Figure 8: Web Services Standard Protocols

4.1. Web Services Descriptive Language (WSDL)

As discussed above, one of the characteristics of Web services is the definition and publication of descriptive information. Each Web service defines and publishes its interfaces (APIs) and other capabilities such as the network protocol for access, the accepted message formats, and how to reach the service. The standard protocol for this process is known as the Web Services Description Language (WSDL). The WSDL is an XML-based standard specification schema. A WSDL document is generally comprised of the following elements that describe the Web service.

11

ViewPoints
Types: XML types corresponding to the various arguments and return types. Message: An abstract typed definition of the data being communicated. Operation: An abstract description of an operation provided by the Web service. Port Type: A collection of operations supported by one or more endpoints. Binding: A concrete protocol and data format specification for a particular port type. Port: A single endpoint defined as a combination of a binding and network address. Service: A collection of related endpoints.

4.2. Universal Discovery Description and Integration (UDDI)

Web services are loosely couple autonomous services that can be dynamically created independent of other applications or other Web services with which they may interact. Therefore, a mechanism for registering Web services is required for Providers to publish their existence and for Requestors to locate services in a network environment. The network in this context is either internal to an organization or may span beyond the boundaries of an enterprise. The standard protocol that meets this publishing and discovery aspect of Web services is known as the Universal Discovery Description and Integration (UDDI). The UDDI is an XML-based protocol for distributed, Web-based information of Web services. The UDDI provides a means to publish information about Web services, as well as a discovery mechanism to locate Web Services and the nature of services they provide. For developers creating Web services, the UDDI serves the following functions: Allows the developer to locate WSDL information about already created services. The developer can access the technical details necessary for interaction with a specific Web service. Permits access to UDDI and allows developers to determine functions of existing services, thus avoiding creation of duplicate or similar Web services. The developer can publish and describe newly created services in UDDI for consumption by other developers, applications, or services. External to an organization, a UDDI Business Registry can be used to locate companies in a given industry with a given type of service, or locate information about how a partner or intended partner has exposed a required Web service.

4.3. Simple Object Access Protocol (SOAP)

One of the main benefits of Web services is the ability to exist in any heterogeneous computing environment and be programming language-independent. Organizations pursuing Web services solutions are taking the consistency builds competency approach. The programming language of choice for creating Web services must be decided upon by each organization. From a practical and efficiency perspective, a programming language should not limit the deployment environment within an organization. Both Java and the .NET framework allow for efficient Web services development and also give developers the benefits of infrastructure components such as security, distributed transaction management, and connection pool management, thus enabling Web Services to be deployed in a very scalable, secure, and robust manner.

12

ViewPoints
Current applications often support a network-object interaction model where objects of strictly defined types are transferred between components using a request-response interaction pattern. Such object interactions require an understanding of the object model within which they live. For this reason, object interaction methods are not suited for multi-application interoperability or cross-organizational interactions that must be long lived. XML permits data to be very portable and, therefore, Web services can leverage the lightweight XMLbased protocol named the Simple Object Access Protocol (currently SOAP version1.2) for invoking services across the Internet and exchanging information in a decentralized and distributed environment. The transport mechanism for SOAP is provided by ubiquitous Web protocols such as HTTP/HTTPS, which enables negotiation of Internet firewalls much better than existing protocols such as RMI, IIOP, or DCOM. The usage of SOAP does not dictate a programming or implementation model. Rather, it defines the modular packaging model and the mechanisms used for encoding data within these modules. The four parts of a SOAP message are as follows: The envelope defines a framework used to describe the contents of a message how it should be processed. A set of encoding rules that is used to express instances of data types defined by various applications. A convention for representing remote procedure calls and responses (e.g., parameters passed to and from services). A binding convention for exchanging messages using an underlying protocol such as HTTP/HTTPS and SMTP.

5. The Value Proposition of Web Services

By their nature, Web services have a more far-reaching impact on businesses and IT organizations than previous integration technologies. To enthusiasts, Web services are second-generation use of the Web. In its first generation, the Web linked people to applications. The second-generation of the Web links application to application. Some see the second-generation web as a revolutionary new age in computing and business management. Others the more skeptical see Web services merely as an interesting development beset with problems that will prove difficult to overcome. The computing industry recognizes very clearly the failure rate of application development efforts, which is currently running at approximately 70%. Because every IT project has its own nuances of challenges, technology itself is not the only factor for such a dismal failure rate. However, the consequences of adopting a specific technology can very easily contribute to the success or failure of an IT project. The impacts of new technologies sometimes do not immediately present themselves, but rather appear as limiters or inhibitors in subsequent development efforts. To avoid being just another statistic, both business and IT leaders are beginning to think about issues differently and are asking themselves what is nirvana for business solutions when considered from an overall enterprise standpoint. Traditionally, the mentality has been to deliver functionality/applications that meet requirements in the quickest manner possible. Taking a holistic view of the situation highlights that applications developed under the old paradigm are susceptible to becoming legacy in the near future.

13

ViewPoints
In an effort to avoid creating the rigid legacy applications of the future, organizations must consider the longevity and sustained growth of proposed business solutions. They will need to clearly define solutions that are flexible and capable of scaling with the current, the future, and even the unanticipated demands of business. Organizations must also consider how proposed business solutions fit in an enterprise Time-to-Share model. Business processes and associated domains of data, information, and knowledge may need to be leverageable, that is, shared and accessible, to the organization not today, but sometime in the life of the business solution. Creating solutions that facilitate this kind of information openness extends the useful life of business solutions. It is extremely rare to see computing heavyweights such as IBM, Microsoft, Sun, BEA, Oracle, HP, and others agree on anything yet, in this case, they all concur. Web services will be the native language of the next generation of Internet-based applications. Web services promises to simplify integration across many aspects of the enterprise by providing interoperability among distributed business systems that span diverse hardware and software platforms. Also, the accessibility of applications through organizations firewalls is made possible by leveraging ubiquitous Web protocols (HTTP/HTTPS). Finally, the usage of the XML data model will enable crossplatform and cross-language integration between heterogeneous distributed applications. By leveraging these attributes, Web services offer the following value propositions to organizations considering this architecture: Organizations can reduce the costs associated with component and cross-system integrations. Software development costs and the resource costs will both decrease as complexities are removed. Longer-term, an organizations technical training needs will decrease as Web services becomes an enterprise wide standard. The facilitation of less complex interaction in B2C and B2B interactions and thus increase an organizations capacity for building and sustaining relationships with customers and partners. Improvement of organizational efficiencies by the delivery of more timely services created with less resources. More flexibility in organizations as they pursue new business models, new markets, or new partnerships. A business services model may even expose untapped revenue streams in the legacy business value chain. Foundation services for a portal framework that needs to encompass content, business systems, and internal or external (non-) syndicated services. Web services technology is very new. In order for organizations to participate in the Web services landscape, an investment in terms of time and money will be required to drive the adoption of Web services technologies and to conduct the initial training required for long-term success. Web services are in an evolutionary phase and, therefore, organizations must first prove the fundamental principles of Web services to skeptics both within IT and on the business side. A tangible method for displaying the benefits of Web services, is to incorporate them into upcoming development efforts.

14

ViewPoints
By demonstrating the value of reusability, abstraction of business logic from the integration layer, and exposing existing business processes via services, IT organizations can make the case for Web services. After successful pilot development efforts, IT organizations can begin to provide standards for designing, developing, and deploying Web services for future development efforts. IT organizations should also focus on governance to ensure the adoption of proven standards being driven by the various standard boards. Complying with industry standards mitigates the risk of misapplying this technology and incurring extra cost in both development and execution of software systems.

6. Challenges facing Web Services Initiatives

All new technologies and infrastructures bring with them a set of unique challenges. Web services are no different. It is important to remember that Web services are building blocks of your overall Services Oriented Architecture and, as such, each additional service that is developed will shape your overall architecture. Following are some common challenges currently faced by organizations considering the implementation of Web services.

Compatibility
One of the promises of Web services as described above is the ability for a Web service to describe its functionality and interface points to other services. In reality, however, will this descriptive text truly reflect the inner workings of a Web service application? Developers seeking to join one or more Web services may discover incompatibility issues when attempting to link Web services from various applications or providers. Strong IT governance is needed to ensure consistent Web services descriptive text. The bigger challenge facing Web services development will be intra- organizational integration in which the IT leaders of several organizations have to enforce standards for Web services compatibility.

Changing Nature of Business Relationships

A fundamental promise of Web services is the ability to join disparate applications from within an organization, or from other businesses in a companys value or supply chain. Business and IT leaders know that, typically, the more constituents involved in a development effort, the longer and more complicated the effort. Exposing the inner workings of an organization via Web services introduces additional interested parties who act as outside businesses and potential subscribers/providers of Web services. The introduction of a SOA and Web services layer forces businesses to consider their trading partner relationships and how to best manage Web services providers and subscribers.

Intellectual Property Disputes

Several of the larger application server and integration platform vendors such as IBM, Microsoft, Oracle, and BEA are currently debating intellectual property disputes. At first glance, this could scare away IT organizations that are in the midst of determining a SOA and Web services strategy. Rather than waiting for these disputes to resolve themselves, business and IT organizations should instead take a skills and software inventory. Whether a .NET or J2EE organization, it is much more important to determine your SOA and Web services strategy than it is to pick the most appropriate software platform.

7. Summary and Action Steps

Web services technology originated on the Internet as a way to solve particular problems, such as passing through firewalls and dealing with loosely versus tightly coupled system issues. It will be important

15

ViewPoints
for organizations to recognize the merits of Web services and their application within their associated business environment. Web services have the ability to be embedded in existing applications thus introducing Web services architecture and benefits can prove to be a significant benefit for organizations when carefully implemented. The following six suggested action steps are based on the actions currently undertaken by leading businesses and IT organizations.

Action Steps
Define your organizations Services Oriented Architecture. To maximize the benefit of Web services, leading IT organizations are setting a strategy in place rather than letting business units or developers develop Web services on an as- needed basis. Initial strategy for identifying Web services candidates should focus on identifying processes or applications with a high probability for reuse. While the overall strategy is being developed, identify a business need or current initiative that can be solved via Web services exposure of an existing application, or a newly created Web service. To avoid introducing new types of defects, enforce existing development standards in terms of security architecture, testing/quality assurance, and on-going applications management. It is important to consider Web services applications and to treat them as such during the development life cycle. Evaluate your current integration framework and contrast it to an emerging trend known as the Enterprise Service Bus (ESB). The concept of an ESB, which utilizes standards-based interfaces for secure and reliable integration, is complementary to an overall Web services strategy. In the areas of services discovery (discussed above), an ESB allows for an enterprise wide accessible solution for services registration and discovery. The ESB combines messaging, web services, data transformation, and intelligent routings. The powerful combination of these components lays the foundation for loosely coupled application integration across distributed networks, see figure 9 below.

Figure 9: The Enterprise Service Bus Connects entire Enterprise (Adapted from IBM) Get involved in the Web services standards development efforts in your industry. Staying abreast of on-going standards development can minimize costly rework to adhere to late developing standards and also makes your company a more attractive trading partner to other organizations. Determine your integration platform based on your in-house skills and software already in use (do not expect immediate resolution of IP disputes discussed above). Create a change management plan for addressing the inevitable role changes of both your business and IT resources. Business leaders will have to become more involved in industry trends regarding cooperation among trading partners while IT leaders must stay current on the latest technical developments in Web services.
16

ViewPoints
Adopting an SOA is a long-term commitment but unlike big-bang implementations of the past, there is incremental return on investment as organizations adopt an SOA and begin service enabling their organizations. The level of returns and adoption of an SOA does not grow linearly over time, but rather has the capacity of exponential growth as more and more areas of an enterprises business and IT organizations adopt the SOA concepts and Web services are created in higher volumes. Web services is not a silver bullet to solve all of ITs current dilemmas but used correctly and in conjunction with widely accepted standards such as XML, they can provide tremendous benefits to IT organizations and the businesses they support. References: W3C Web services: Definition http://www.w3.org/2003/Talks/0317-ws-intro/slide27-0.html IBM Web services Glossary http://www-306.ibm.com/software/solutions/webservices/glossary.html The Stencil Group, Defining Web services http://www.stencilgroup.com/ideas_scope_200106wsdefined.html Secure, Reliable, Transacted Web services: Architecture and Composition http://msdn.Microsoft.com/library/en-us/dnwebsrv/html/wsoverview.asp Web services Conceptual Architecture (WSCA 1.0) http://www-306.ibm.com/software/solutions/webservices/pdf/WSCA.pdf Microsoft XML 3.0 XML Microsoft XML 3.0 XML Developers Guide, XML Glossary http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk30/htm/xmgloxmlglossary.asp Violleau,Thierry, Java Technology and XML - Part 1, An Introduction to APIs for XML Processing http://java.sun.com/developer/technicalArticles/xml/JavaTechandXML/ (November 2001) Text Encoding Initiative: A Gentle Introduction to XML http://www.tei-c.org/Guidelines2/gentleintro.html XML Beginners Guide http://www.xml.org/xml/resources_focus_beginnerguide.shtml Understanding XML http://java.sun.com/webservices/docs/1.0/tutorial/doc/IntroXML.html BEA Weblogic Platform 7, by Jatinder Prem (SAMS 2004)

About the Strategic Technology & Advancement Research (STAR) Team

The Strategic Technology & Advancement Research Team serves as the proving ground for our ideas. STAR brings together the best and brightest of LiquidHub to encourage new thinking and develop through leadership around technology. Breakthrough ideas emerge and are exercised by the Team, to strengthen client engagements and educate industry leaders.

17