Horizons WSXML Primer v3

8/12/2019 Horizons WSXML Primer v3

1/17

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

ViewPoints

LiquidHub, Inc. l 500 East Swedesford Road l Suite 300 l Wayne, PA 19087 l 484.654.1400 l www.liquidhub.com


2/17

ViewPoints

2

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)


3/17

ViewPoints

3

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, madetrue 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 beused 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 serviceshave 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


4/17

ViewPoints

4

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 anetwork 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).


5/17

ViewPoints

5

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.


6/17

ViewPoints

6

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 servicesmore 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).


7/17

ViewPoints

7

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 thebusiness 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


8/17

ViewPoints

8

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 acompletion 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.


9/17

ViewPoints

9

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


10/17

ViewPoints

10

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 inFigure 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.

Pirates of the Caribbean

Action/Adventure

PG-13

143

The School of Rock

PG-13

108

Figure 7: DVD Collection Example

The DVD Collection example is considered to be a well-formed XML document based on the followinglist 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 openingtag 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


11/17

ViewPoints

11

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 isa 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.


12/17

ViewPoints

12

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, thusavoiding 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 servicessolutions 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.


13/17

ViewPoints

13

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-organizationalinteractions that must be long lived.

XML permits data to be very portable and, therefore, Web services can leverage the lightweight XML-

based 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.


14/17

ViewPoints

14

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 demandsof 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 cross-

platform 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, andinternal 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.


15/17

ViewPoints

15

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 focuson 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 RelationshipsA 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 ITorganizations 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


16/17

ViewPoints

16

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 currentlyundertaken 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.


17/17

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 ITorganizations 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.

Horizons WSXML Primer v3

Documents

Transcript of Horizons WSXML Primer v3