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

Web Services Roadmap Planning cont'd...

Infrastructure Stream

Topic Area
Deliverables
WS Maturity Phase Applicability
1
EL		 2
INT		 3
RE		 4
MAT
Provider Host environment WS Developer environment
Hosting environment for WS facades
Hosting environment for WS applications
On Demand Operating Environment		 Y

Y
Y		  
Y
Y
Y


Y		  
Consumer environment Internal
External		 Y Y    
Middleware Middleware and Communications technology
Broking and Routing
Transformation		 Y Y    
Integration and Assembly EAI use of Web Services
Workflow and BP standards
Aggregation and composition mechanism		 Y Y
Y
Y
Y		  
Development environment Tools policies   Y Y  
Asset Management Asset management environment supporting supplier/consumer environment Y Y    
UDDI Directory Static usage support
Dynamic usage
Publishing process
- manual process
- more automation, integrated with asset management		 Y Y
Y
Y		  
Service Level Management WS Management environment
SLA management
- Provided
- Consumed		   Y
Y		    
Security Infrastructure - XML Firewall
- Message level security		   Y Y
Y		  
Monitoring & Measurement Mechanisms to provide
- SLA compliance
- Service level logging
- Business monitoring services		   Y Y  
Diagnostics, failover Fault management
Diagnostics and Alerts
- Infrastructure
- Business Service		   Y    
Consumer/Subscriber Management Access control
Subscription
Accounting
Common billing system		   Y Y  
Web Service Protocols Standards adoption and compliance   Y Y  

Table 3 - The CBDI Roadmap Framework - Infrastructure Stream

Web Services and SOA require new and modified infrastructure support. The Infrastructure stream provides a clustering of topics and deliverables required to establish these.

Provider Host environment

Hosting requirements will be more easily managed if there are clear policies set on service levels (see Planning & Management Stream). Service level classes may distinguish between broad classes of requirement, for example development, pre-production, low volume-low criticality production, mission critical production. However these could equally be application specific.

In the early stages of Web Service usage the primary requirement will be to provide a platform that makes it easy for developers to publish services. Requirements over time are almost certain to vary. A common approach to early learning stage hosting is to support a Web Service facade deployment with remote access to function and data. However as and when Web Services become integral to business critical functionality, with high volumes etc, it may become necessary to implement a management infrastructure which has greater visibility of the supporting functionality.

Longer term there will be a shift towards an 'On Demand' operating environment, where not only will the physical location of the service implementation become increasingly remote from the business service provider, but will evolve to become dynamically locatable.

Consumer environment

Though we expect the consumer environment to be a mirror of the provider's in terms of the logical capability, we make the distinction between them because in some situations such as small mobile devices the requirement for purely consumption will drive a different set of service characteristics

Middleware

Many organizations will already have implemented middleware backbones or a bus structure that allow intra and inter enterprise communications. Moving to Web Services and SOA requires new protocol support and a number of additional services.

Integration and Assembly

In the early learning stage Web Services are generally an additional option for integration. Many organizations may set the objective to establish an assembly infrastructure and environment that allows services to be used in many different contexts. It should be noted however, that many of the early services may not be good candidates for general purpose assembly, unless they have been reengineered for general purpose usage.

Development environment

Development tools have rapidly adapted to provide support for Web Service protocols. Through a combination of platform and development tool support, the technology of Web Services will be largely transparent to developers. Adequate support is already provided for the early learning stage. However, beyond that tools will need to evolve further to provide support for SOA modeling and design, and the ability to support the design of complex service based business processes that must be translated into emerging Web Service protocols such as BPEL.

Moving further out, we can expect to see much greater emphasis and support on the assembly and consumption of services integral to business process life cycle support tools. As the coverage and sophistication of this support extends, we will view this as a service assembly and management platform.

Asset Management

As Services become further abstracted away from their implementation through the application of SOA principles, they will be recognized as an independent asset type in their own right, rather than a property of a component or object. Asset Management will become important during the Integration stage to understand and manage the complex relationships between requirements, services, implementations, and countless associated development artifacts.

UDDI Directory

The emergence of private UDDI directories in enterprises will become widespread during the Integration stage to facilitate the internal provision and consumption of Web Services, and to provide a filter to external unqualified Web Services in public directories.

Service Level Management

Service Level Management will be essential for both Service Providers and Consumers to monitor Services and their compliance with Service Level Agreements. Whilst the growing volume of Services in use and transactions will be obvious drivers to SLM, even the simplest of Web Services used during the Early Learning stage may still be subject to stringent SLA requirements and need careful monitoring.

Most enterprises will implement Web Services Management capability through a variety of approaches to enable the following topics including security, monitoring and measurement, diagnostics etc.

Security Infrastructure

As the organization matures its use of services, roles and responsibilities will change. For example who undertakes the testing process? In the early stages as services are part of projects, budgets may dictate that the services are simply developed and tested and consumed as part of a common process - Though we might actually disagree and would advise against, but we accept reality sometimes makes this difficult. But as services become shared between projects, then across the organization and SLA's are required, it is essential that some form of (independent) certification comes into play.

Classification systems

Security is often referenced as a barrier to wider Web Services adoption. In the early learning stage existing web security mechanisms such as SSL will often suffice for straightforward transactions. WS-Security protocols will enable message level security that is suitable for more complex transaction scenarios. It can be expected that malicious attacks, such as denial of service will start to use Web Services necessitating the use of XML aware Firewalls.

Monitoring & Measurement

Mechanisms will be needed quite early in the process to monitor Web Services for SLA compliance, and straightforward fault management and diagnostics.

Where Web Services are abstracted away from the underlying low level network and database traffic that composes the implementation, it provides an opportunity to monitor Services at a meaningful level to the business. This enables not only monitoring of computing resource, but also of business performance.

Diagnostics, failover

With meaningful business Web Services, diagnostics and failover can be considered at both the business and infrastructure levels. Failover can be implemented at the SLM level for example by re-routing Service requests dynamically.

Consumer/Subscriber Management

The need to manage service consumers in terms of access control (not the same as security) and accounting for their usage is not just relevant to commercial Web Services, as internal usage may still be the subject of internal accounting procedures. Not only may this entail providing links to accounting and billing systems, but to provide a more dynamic environment, self subscription mechanisms will also have to be provided to consumers.

Web Service Protocols

Though several core WS protocols are in place and/or in progress through standard committees, a broader set will continue to emerge and evolve to support the needs of Enterprise level Web Service and other scenarios. Many organizations are implementing their own protocol compliance guidelines in order to facilitate early learning activity. It will make sense to adopt the WS-I profiles as they come available, although it will still be necessary to have some level of coordination on what profiles are being used at any point in time, and also any local overlays that are applicable. Interoperability will continue to be a minor problem in the Early Learning stage.

Contents...


Previous Page Next Page
eLearning

  © Everware-CBDI Inc 1999-2008