The Business Forum

"It is impossible for ideas to compete in the marketplace if no forum for
  their presentation is provided or available."           Thomas Mann, 1896


Is Web Service Technology a Good Fit for My Organization?

Author: Jay Lee
Contributed by eBI Solutions LLC

 

 

Overview

“Web Services” is a term that can be defined in many ways and from many perspectives. The following are but a few of the possible definitions.

From the perspective of…

...we might define web services as…

the development process of Web Services

the development and deployment tools used to create web services

the network infrastructure of Web Services

the network, server, and security requirements for hosting web services

the maturing standards by which to adopt, implement, and support Web Services

WS-Security, WS-Trust, WS-Policy

an acronym junkie

XML, HTTP, SOAP, DSIG, WSDL, UDDI, XLANG, WSFL, SWA, USML, DIME.

Acronyms and varying perspectives aside, one very important question remains:

What can Web Services do for my business?

Unfortunately, there is no complete correct answer to this question. Though the growth and adoption of Web Services in business hinges upon the convergence of a “generally accepted” set of industry standards, today’s myriad of overlapping, and sometimes divergent, standards do not help this cause.

The following pages will outline some basic concepts, and entertain a few simple questions, to help you form a more coherent view of Web Services.  The goal of this paper will be to help place your organization at the beginning of a roadmap to successful adoption of Web Services as part of your application integration strategy.

What are Web Services?

The “executive elevator pitch”

“Web Services” technology defines a new strategy of application integration which uses the tried and true transport technology, HTTP, and widely accepted data formatting standard (XML) with which to:

a)      Build self-contained business functions and services

b)      Access business functions within existing enterprise systems, and in within partner organizations.

There exist today a powerful, yet “organic” grassroots movement to construct open standards in an effort to forge a common language with which organizations can communicate and interact with each other.

Beyond the hype of the technology itself, “Web Services” is a mix of standards and processes with which to employ already widely adopted technologies (HTTP, XML) as a means for translating and transporting business data while leveraging the investments in business functionality that exist within internal business systems. The standards-based nature of Web Services provides the investment protection to mitigate the risks inherent to adopting new technologies.

The Reach of Web Services

Figure 1: Web Services foundation and its potential reach.

Though its concept remains simple, Web Services will be an enabler of many new and existing business and computing concepts such as Grid Computing, EAI, and Business Process Management/Integration. Business value from such services, which require a distributed computing architecture, can more easily be realized within and between enterprises.

The “layers” of Web Services standards

 

 

Figure 2: The Web Services Stack.

This model is often referenced when identifying the
"layer" in which a protocol or standard operates.

The sheer number of Web Services standards and protocols in use today can make it difficult to understand where they all fit into the big picture. It is easiest to classify Web Services standards into one of five “layers” of the protocol stack (for those of you with backgrounds in network management, this is similar to the OSI 7-layer reference model)

Discovery protocols facilitate the location of the appropriate Web Service for the purpose intended, or the functionality sought by a client. Available Web Services are listed in well-known global directories.

Description of Web Services is done using languages such as WSDL (Web Service Description Language) to expose the Service’s public interface.

Packaging SOAP (Simple Object Access Protocol) is today’s most commonly adopted standard for packaging Web Services data. Several extensions to SOAP also exist to address security, message routing, and binary or MIME attachments.

Transport This layer describes the protocol used to transport data of Web Service between client and server. HTTP (Hypertext Transport Protocol) is the most commonly used protocol, with extensions available, which address security (HTTPS) and reliability (HTTPR).

Network This layer describes the protocol used by the end computers to move the data. This is usually done over the Internet (using TCP/IP).

Web Services - Definition

For the sake of keeping this document focused on the question, “Is Web Service technology a good fit for my organization?” we will refrain from providing any detailed technical definition of Web Services. WebServices.Org (http://www.webservices.org) provides excellent resources and white papers to describe Web Services technologies, protocols, standards, and current challenges.

WS-I (Web Services Interoperability - http://www.ws-i.org) provides resources to address interoperability between the myriad of Web Services standards currently being proposed.

What are the limitations of First Generation Web Services?

Competing standards

There are both “Top-Down” efforts to standardize Web Services protocols, the frameworks of which are governed by large organizations, and “Bottom-Up efforts which are “grassroots” movements to standardize Web Services. There are advantages to both, and it will take years  before standards converge to a universally accepted set.

If your organization can benefit from the capabilities of Web Services, don’t wait for a convergence, or a perfect set, of standards. Even with standards in flux, there’s much to gain in leveraging Web Services within your organization. Be sure to understand the implications of being locked into a standard.  Example; Your largest partners impose different Web Services standards on their partners, leaving you with no choice but to conform to theirs. If possible, design or select Web Services solutions, which are flexible enough to accommodate multiple standards, or are open enough to grow with changing requirements in the foreseeable future.

Few, if any, “complete packages of products” are available today

In order to ensure that your organization’s web services infrastructure provides a complete solution, you must ensure that each of the following factors are addressed in selection process of each piece of your Web Services strategy:

Technical Infrastructure. Your IT organization must be able to support the network, servers, and operating systems required to communicate using the Internet and the World Wide Web within your enterprise and with your partner(s).

Development Tools. As with most systems, you will need the proper development tools to ensure proper technical implementation of Web Services. The proper coding, version control, and deployment tools will be critical to managing Web Services development cycles.

Management Tools. Though individual Web Services are not difficult to create, when they become large in number, they can become unwieldy to manage. You will need ways to manage Partner relations (and the variations between standards used by different partners), monitor activity, and comprehensively address security issues. Due to the youth of Web Services and its yet-to-be widespread deployment, very few packages on the market today offer proper management tools. Be cautious in selecting the products or and solution packages that you choose to implement and eventually manage your web services.

Security. When evaluating Web Services, or any technology for this matter, and to ensure due diligence to the security of your business systems and data, you must ensure that the following simple questions are addressed  each step of the way, by each component implemented:

         Authentication: Has the partner (a system, organization, or person) been explicitly allowed to access my web service?

         Authorization: What is this partner, once authenticated, allowed to do?

         Confidentiality: Will knowledge, and details, of interactions with my partner(s) be kept private from outside parties?

         Integrity: Can I ensure that the data, which is exchanged with my partner(s), is not corrupted during the transport and exchange of data?

         Availability: Can I guarantee to my partner(s) 100% uptime during critical business hours? What contingencies are in place to act, as a substitute for the services provided by the web service(s), should the systems they are hosted on be compromised?

         Non-Repudiation: Can I guarantee that interactions with this partner cannot be impersonated by any outside party, allowing for full accountability of all transactions

         Audit: Will reliable records and audit-trails of the transactions with my partner(s), and details the transactions, be available should the need arise?

Where will Web Services fit into my organization’s IT strategy?

Most businesses today use computers and software in one or more forms to manage their daily operations. They often end up with several disparate, isolated business applications, which cannot easily communicate with each other or exchange data efficiently and reliably.

 

 

Figure 3: Using Web Services for Enterprise Application Integration (EAI)
and Business-to-Business (B2B) interactions.  


EAI (Enterprise Application Integration) tools of the past have addressed this problem with proprietary connectors and adapters which require additional coding using each particular vendor’s API’s. This leads to code, which may not be readily reused by other systems you wish to integrate. Many e-business products and solutions employ EAI tools, while also providing the tools to facilitate communication with partner organizations (B2B - “Business-to-business” interactions).

Web Services provides a more open interface with which you can expose the functionality of your isolated applications to applications used in other departments within your organization or to select partners with whom B2B automation would make sense.

 

 

Figure 4: A Self-Contained Web Service
providing service, data, or intangible products to customers.  

Web Services technology can also be used as a foundation for “self-contained” business functions (rather than as just a means to integrate functionality of pre-existing systems).  

You may choose to build such a service from the ground up as an intangible product, service, or data offering. Open standards ensure that prospective customers can easily communicate with your Web Service without acquisition of proprietary Application Programming Interfaces (APIs) or Software Development Kits (SDKs).

Why adopt Web Services?

Leverage value of existing systems. As with any integration solution, Web Services will allow you to use functionality, which was once locked into your business systems externally.

Investment protection. By investing resources in a technology, which is based on widely adopted protocols (such as HTTP, XML) you will not be stuck with any proprietary integration technologies as you once may have been with proprietary connectors and adapters of the past.

Flexibility, Agility, Scalability. Again, due to the standards-based nature of Web Services, you can scale horizontally to account for growing numbers of applications across the enterprise, which can access value delivered by a Web Services solution. You can also easily scale vertically to account for transaction volume.  

How should my organization adopt Web Services?

Define a Vision

When evaluating a new technology, product, or service, it is always important to first envision how your organization will best benefit from it. Which departments can benefit the most from automation and integration of processes? Which systems hold data, which can be leveraged by external applications or by your business partners, suppliers, or customers?

Build a Roadmap

Start small, with a pilot. Explore your organization’s IT resources and search for a unit of work that can be consumed by client applications as a Web Service. The value of implementing a Web Service for this unit of work should be quantifiable. This value may come from the elimination having to manually perform a repetitive task, reduction of human errors and omissions, or in the service’s ability to scale to multiple disparate clients without additional investment.

Measure your returns. Determine the returns on your initial investment, taking into account how the cost of ownership will scale as the number of Web Services scales.

Review and, if necessary, revise your roadmap. Determine whether the returns resulting from your Web Services investment can justify a large-scale deployment. You may find that the timing is not right for your organization to adopt Web Services technology, or that your IT organization is not ready to support it. If you decide that Web Services makes sense for you, revise your roadmap, adjusting for what you’ve learned in your pilot be ready to act

Plan for scale. Use what you’ve learned from your previous experience to determine what criteria to use when selecting products and services to help you scale, manage, and protect your Web Services investments.

Act!

In the early stages of any new technology’s adoption lifecycle, we must accept that changes will happen. Build enough flexibility into your system to account for these changes. Don’t wait for the “perfect moment” to enter the Web Services playing field. As with any system with high potential returns on investment, time lost is money lost.

Commonly used Web Services acronyms  

 

Web Services Layer

Term /Acronym

Definition

Network

TCP/IP

Transmission Control Protocol / Internet Protocol

The Communications protocol used on the Internet.

Transport

HTTP
HTTPS
HTTPR

Hypertext Transport Protocol

Secure Hypertext Transport Protocol

Reliable Hypertext Transport Protocol

DIME

Direct Internet Message Transport

Packaging

SOAP

Simple Object Access Protocol

SOAP-DSIG

SOAP Digital Signatures (Security Extension of SOAP)

SWA

SOAP messages With Attachments

WS-License

Web Services License Language

WS-Referral

Web Services Referral Protocol - enables routing strategies for SOAP message paths

WS-Routing

Web Services Routing Protocol

WS-Security

Web Services Security Language - enables secure Web Services interaction, facilitating credential exchange, message integrity, and message confidentiality

Description

WSDL

Web Services Description Language

WSCL

Web Services Conversation Language

WSCM

Web Services Component Model

WSEL

Web Services Endpoint Language

WSFL

Web Services Flow Language

WSML

Web Services Meta Language

WSXL

Web Services Experience Language

WSUI

Web Services User Interface

XLANG

Web Services for Business Process Design

Discovery

UDDI

Universal Description, Discovery, and Integration

USML

USSI Search Markup Language

WS-Inspection

Web Services Inspection Language

 

 

 

 

 

 

 

 

 

 

 

 

 

About eBI Solutions LLC

eBI Solutions specializes in providing e-Business Integration solutions.

eBI Solutions provides eAI and B2B integration solutions to companies in the mid-market as well as Fortune 500 clients. Experience helps us to appreciate the challenges mid-size companies face, and to select relevant solutions for today and tomorrow, with an ROI and a budget that make sense.

While the primary focus is integration technology, an integration project is only successful when the team running it has an intrinsic understanding of the systems and business processes impacted by an integration project. Our approach to integration and selecting professionals for our projects clearly reflect that reality.


The Business Forum
Beverly Hills, California, United States of America

Email:  [email protected]
Graphics by DawsonDesign
Webmaster:  bruceclay.com


 ©  Copyright The Business Forum Institute - 1982 - 2015  ** All rights reserved.
 The Business Forum Institute is not responsible for  the content of external sites.

Read more