CBDI Forum CBDI Web Services Roadmap. Guiding the transition to Web Services and SOA
 
CBDI Knowledgebase

Assembling the Web Service Infrastructure cont'd...

Introduction

With each technology shift, organizations need to re-examine their infrastructure to determine how it will support the new requirements. With regard to Web Services, organizations need to consider such issues as,

  • What elements of their existing infrastructure need upgrading to provide specific support for Web Service protocols? Is XML capability enough? Or does it need specific support for Web Service protocols?
  • To what extent will their existing infrastructure built to support the Internet suffice?
  • Are there new classes of tools required?
  • Is the same infrastructure capable of supporting both internal and external Web Services?
  • How far into the infrastructure do Web Services need to penetrate? Will a new layer or façade on the existing infrastructure suffice, or must the whole infrastructure be upgraded?

There are several elements to the Web Services infrastructure, as listed in table 1. The requirements for this Infrastructure may be served by more than one type of software component/product and organizations need to carefully examine how their full needs are going to be addressed. For example, a web/application server may contain some measure of all these requirements, but at the same time may not be as comprehensive as a dedicated product (perhaps from an ISV rather than a platform vendor) in any one of these domains.

At one extreme, some organizations with a small number of straightforward Web Services may feel their requirements are addressed by little more than a Web Service capable web server such as Apache AXIS and a few well chosen scripts. Whereas larger organizations, delivering numerous business critical Web Services with demanding SLAs, will see an overall benefit from adopting several dedicated infrastructure components.

Infrastructure Requirement
Likely Source Component
Comments
Deployment
Run time handling of Web Service protocols		 Web/Application Server Built into Servers such as Microsoft .NET, J2EE1.4, Apache AXIS, BEA WebLogic
Management
Run time management of services, messages, users, etc		 Web/Application Server
Web Service Management (WSM)
Systems Management		 Elements of both passive and active management will be contained in the underlying platform and the web/application server. However dedicated WSM products allow you to abstract and centralise management away from the multiple (heterogeneous) applications.
Security
Identification and authentication of participants, protection against cyber attack 		Web Services Firewall
Identification Services
Web Service Management		 Though elements of security will be built into other components, there is merit in addressing security via separate, stand-alone components
Orchestration
Run time workflow/process control		 Web/Application Server
Development Tools		 Look for products based on emerging Web Service protocols such as BPEL4WS, WS-Choreography
Protocol Creation
Delivery and description of Web Service in terms of Web Service protocols		 Workflow/Orchestration engine .NET and J2EE 1.4 will automatically create the necessary protocols
Development
Build/assemble implementation of above		 Development Tools
Workflow/Orchestration Tools		 Development tools will become less focused on the creation of Web Service protocols, and more focused on service design, and solution assembly
Publication and Discovery UDDI Directory Public and Private directories can support both external and internal use respectively

Table 1 - Essential Infrastructure Components

As with other technology shifts, many start ups or existing ISVs are delivering new products dedicated to Web Services. At the same time, the major platform vendors are also delivering useful Web Service capability as upgrades to their platform and middleware products. In table 2 we examine the support for Web Service protocols in infrastructure products.

Existing Infrastructure
WS Protocols support in current Infrastructure
Use of new WS aware products
Outlook
Routers and Firewalls × Little or limited Supplement with new XML and WS Firewalls and routers Longer term expect WS support embedded in hardware routers and firmware
Implementation of WS-Addressing for SOAP routing
Directory and Security Servers × Little or limited Supplement with private UDDI directory UDDI layered on LDAP
Application and Web Servers √√ Already upgraded   Some WS infrastructure in other categories will be increasingly embedded in the Web/app servers
OLTP, ORB, and MOM √ Being upgraded   Though SOAP aware, these products will need some further upgrading to support emerging standards such as WS-Transactions, etc
EAI Tools √ Being upgraded Could supplement with broker capabilities in some WS Management tools WS will reduce need for EAI adaptor capability.
EAI remains useful to wrap existing systems as WS
Orchestration Engines × Only technology previews currently   Products based on emerging BPEL and/or WS-Choreography protocols
Systems Management × Little, or limited Supplement with dedicated WS Management Traditional SM tools will add WS capability
WSDM standards emerge in 2004
Development Tools √√ Already upgraded   Although upgraded to support basic WS Protocols, few support SOA principals

Table 2 - Infrastructure Support for Web Service Protocols

Web Service Infrastructure Architecture

There are a number of deployment options for Web Services Infrastructure.

As with other infrastructure deployment, for larger organizations we believe the ideal would be to put a comprehensive Web Services infrastructure in place that can for example,

  1. Be reused by any application or service developers across the organizations, so they don't have to reinvent the wheel in each project
  2. Ensure consistency of approach, management, and security across the organization
  3. Where relevant operate at the business service level, abstracted away from the (multiple) back end implementations

Like the collaborative SOA approach that organizations are encouraged to implement in their applications using Web Services, then the Web Service infrastructure itself will also follow suit. This will remove some the need for a centralised implementation or to funnel Web Services through specific infrastructure server as components of the infrastructure can themselves collaborate via Web Service protocols.

Figure 1 - Web Services and Physical Pipeline

One key architectural question is how far should Web Services 'penetrate' into the typical enterprise infrastructure. Now that vendors are Web Service enabling a diverse range of products, as illustrated in figure 1 a SOAP message might pass through, or be directed to, several physical server types and across multiple networks within the enterprise before reaching its final destination.

At a minimum, an organization could halt the SOAP message at the Web Server, and convert it to existing infrastructure protocols to forward the message on to the appropriate internal system. However, besides obvious benefits of platform independence and the ability for the SOAP message to more easily navigate a heterogeneous environment there would be a number of other benefits in using Web Service protocols across the wider infrastructure for end-to-end message flow. These, together with some of the downsides of adopting this approach are considered in table 3.

Pros
Cons
Provides platform and transport independent messaging infrastructure Need to upgrade each of the infrastructure elements listed in tables 1 and 2 with support for Web Service protocols. And eventually every instance.
Use WS-Security to maintain the integrity of a message right until its ultimate destination, keeping it secure inside the firewall, not just outside. Support for emerging (and more complex) Web Service protocols will take longer to apply to existing infrastructure elements than basic SOAP/WSDL support. Some might not be upgraded by vendors
Use WS-Addressing to route messages to specific servers and applications.  
Development and assembly of Internal applications and components can benefit from protocols such as WSDL, and publication via a private UDDI registry Fragmentation of development assets that target each of the infrastructure elements. Needs careful co-ordination
Remove need for overhead of transformation to existing protocols - and potential errors Performance of XML based infrastructure may not be as optimised as existing protocols.

Table 3 - Pros and Cons of Deploying Web Services Infrastructure Enterprise-Wide

Web Service Management

One new category of infrastructure introduced is that of Web Services Management (WSM). WSM complements existing systems management software by operating at the Service level. This also raises an opportunity to monitor and manage at a level meaningful to the business instead of the low level operations, providing Web Services are delivered at the appropriate level of granularity and abstraction.

In the near and mid term organizations should adopt tools on offer from a number of ISVs. Ultimately we expect existing systems management tools to provide WSM capabilities, though this does not mean leading WSM vendors will not endure.

We will look at the roadmap for WSM in a later report. In the meantime, the capabilities that organizations should be looking for in WSM tools are considered in our Business Services Server report1

References

  1. Business Services Service, CBDI Report (FOC),
    http://www.cbdiforum.com/bus_services.php3

Previous Page Next Page
CBDI Knowledgebase

  © Everware-CBDI Inc 1999-2008