Assembling the Web Service Infrastructure cont'd...
Stages of Web Service Infrastructure Deployment
Deployment of Web Service enabled infrastructure is likely to happen in 3 stages as illustrated
in figure 2. In some cases, organizations may expose limited external Web Services as their first use,
though as explained elsewhere it is becoming more common for organizations to adopt internal usage first.
Actual infrastructure elements that need to be upgraded or added at each stage will of course vary
from organization, which is explored in Table 4.
Upgrades |
Comment |
| Stage One - Internal usage - limited upgrade to key infrastructure where required |
| Web/App server |
Likely platform for new cross functional business systems requiring WS |
| EAI server |
Front end current non-WS enabled systems. Some orchestration. |
| Other App/DB servers |
Upgrade current or 'legacy' app, OLTP, DB servers where some limited native
WS now provided. Otherwise use EAI to access. |
| UDDI Registry |
Private UDDI registry for internal use |
| Web Service Management |
Basic monitoring of internal WS to provide performance and usage statistics,
and raise alerts to basic problems |
| Message Orient Middleware and/or ORB |
Possibly upgrade existing MOM to provide reliable messaging. Similar
upgrade ORB to integrate existing object infrastructure |
| Stage Two - External usage ' main impact security
and additional WSM to manage SLA |
| Web Service Management |
Add modules for SLA Management, User Management, Access control, and Message Management to
support External usage |
| XML Firewall |
External usage requires XML/WS level firewall and security |
| Stage Three - Enterprise Wide SOA infrastructure - underlying
platforms/ transports transparent. Enables shift to On Demand Operating Environment by
"virtualizing" the back end implementations. |
| Web Service Management |
WSM components deployed to individual servers. Eventually compliant with emerging WSDM standards |
| XML Router |
Compatible with WS-Addressing |
| Orchestration Server |
BPEL4WS, and/or WS-Choreography compliant business process orchestration |
| Web/App/DB Server |
Upgrade where full WS capability provided, including emerging enterprise standards |
Table 4 - Web Service Infrastructure Deployment Stages
Figure 2 - Web Service Infrastructure Deployment Stages
Several considerations need to be made when upgrading the infrastructure for Web Services,
some of which will be potential inhibitors
- Project Culture
Working against the implementation of an enterprise-wide Web Services infrastructure is the project-centric
culture that predominates today. In our survey of organizations who have implemented Web Services, 70% of
the projects were funded at the divisional level. As such many questions regarding the responsibility,
funding or even the need for an enterprise-wide approach remain cultural rather than technical.
- Interoperability
With Web Service protocols evolving rapidly their implementation across the diverse infrastructure is
likely to raise issues of interoperability due to different versions and inconsistent implementations
by vendors. Infrastructure elements will need to be upgraded in parallel to avoid interoperability
issues.
- Lowest common denominator functionality
Additionally, the diversity of infrastructure elements means that not all will deliver the same Web
Services capabilities. E.g. certain emerging protocols will only be supported by some elements.
- Performance
Web Service infrastructure will at least in the near term often constitute an additional layer of
infrastructure, as opposed to replacement, impacting performance. However, this should only affect
the Web Services themselves, not other messages and transactions passing through the same infrastructure
element. Organizations can also consider introducing parallel infrastructure elements dedicated to
Web Services to ensure existing operations are not affected.
- Service Level Agreements
Consider how Web Service infrastructure elements contribute to, or impact, the delivery of SLAs. Consider
what WSM capabilities might be needed to manage and monitor SLAs. What SLA is offered by the operational
Web Services environment to the application/service developer?
Large and global enterprises face a similar challenge of upgrading for Web Services as they do with any
other infrastructure decision. E.g. the project culture issues raised earlier. Web Services are unlikely to
change current practice without an associated change in culture. However, given that Web Services are primarily
being introduced at present in large enterprises to support EAI needs, it once again raises the issue. We
believe it is sensible for Central IT to deliver or at least provide guidelines on the following,
- Global Private UDDI Registry - There seems little point in allowing each division to
implement their own
- Protocol Usage and Interoperability Standards Guidelines as to which Web Service protocols
can be used should be issued to enable enterprise wide interoperability and integration, and the use of
WS-I profiles
- Reference Platform Issue guidelines for recommend platform(s) that support above
- Messaging Infrastructure Upgrades to network to transport Web Services messages.
Roadmap Actions |
| Plan & Manage |
Identify infrastructure upgrade required for new technical strategy, in each stage
Assess Organization impacts. E.g. Project vs central responsibilities
Acquire funding for infrastructure upgrades
Set SLA policies
Establish WS security policy |
| Infrastructure |
Adopt phased approach to infrastructure upgrades. Upgrade infrastructure in step with needs,
and protocol evolution including:
- WS Developer environment
- Hosting environment for WS facades
- Hosting environment for WS applications
- On Demand Operating Environment
- Support for Consumer environment
- Developer tools
- Security infrastructure
- Monitoring and measurement
- Diagnostics and failure
etc
|
| Architecture |
Plan WSM deployment architecture, e.g. extent of distributed elements
Establish SOA middleware
layer |
| Process |
Publish interoperability strategy and guidelines |
| Projects |
Upgrades to centralised infrastructure
Assess WSM requirements
Private UDDI implementation |
|
