CBDI Web Services Roadmap - Guiding the Transition to Web Service and SOA

Sponsored by

Sponsored Papers

Vendor Web Services Roadmap Report - IBM. IBM's strategy today is centered around "Business On Deman...
more

Many Organizations are now undertaking development of service oriented architectures, but the probab...
more

Whilst investment in Application Integration initiatives over the last decade has undoubtedly improv...
more

ISVs and Packaged Application Vendors Start Here cont'd...

Competitive Threats

Many ISVs will find themselves driven to Web Services as a competitive response. Agile ISVs looking for competitive advantage will use Web Services sooner rather than later. Though initial usage may well be only skin deep, it will quickly become a hygiene factor that ISVs must adopt to keep up. Long term, ISVs will need to re-engineer their applications to exploit Web Services. Though this will be more expensive and difficult, ISVs who move fully to SOA to support this will undoubtedly gain long term competitive advantage in terms of agility and flexibility over those that simply try to dress up their existing interfaces with new protocols.

The business models of some ISVs will be threatened by increased use of Hosted Services that will introduce new types of competitors. ISVs have for some time been able to adopt the ASP approach. Web Services improves the integration and granularity of the hosted solution. However, it also introduces the possibility that end-user organizations could open up their own applications and provide them as hosted services in certain situations. Perhaps the best example today is Amazon who enable other retailers to use Amazon's systems as a basis for their own e-commerce operation, which can now be better integrated with the retailers systems through the use of Web Services. This effectively places Amazon in competition with ISVs selling e-commerce solutions.

See http://www.amazon.com/webservices

Web Services Adoption Steps

ISVs can consider the following outline steps towards adopting Web Services in their products

1. Wrap existing interfaces with SOAP and WSDL to provide basic Web Services support. Some of this ability will come courtesy of the application container the software runs in (such as J2EE, .NET, etc), and require minimal effort.
2. Building a more comprehensive Web Services Façade can be useful to deliver more meaningful aggregate business services, rather than simply exposing the existing APIs, and can be used to provide support for emerging enterprise level Web Service protocols that may require some application specific behaviour.
3. Perform invasive surgery on the application to enable it to consume relevant Web Services rather than simply provide them. This probably requires the use of a "plug point" approach as the specific Web Services may be unknown in advance.
4. Start to use the Web Services you provide for end customers to integrate your own software components (eat your own dog food). This will prepare for more radical re-engineering in future - such as the move to an on demand operating environment
5. Consider what Web Service infrastructure elements you might acquire, licence or partner with vendors to provide, that would benefit customers in deploying or accessing your applications as Web Services. For example including components of Web Service Management.
6. Consider how a hosted version of the software would be deployed, what Services would be exposed, and what infrastructure would be necessary to manage users, usage, and SLA.
7. Re-architect where relevant to support a truly distributed implementation where individual components could be redeployed on demand

Roadmap Actions