Web services technology is not a revolution in the world of computing but an evolution of the old concepts of component-based software development. Web services, a stack of emerging standards that describe a service-oriented, component-based application architecture, are built on service-oriented architecture (SOA), as shown in Figure A. These standards provide a distributed computing technology for revealing the business services of applications on the Internet or an intranet using open and standards-based XML protocols and formats.

Figure A
SOA Model

Nevertheless, several myths surround Web services technology. Let’s discuss the top five myths about Web services technology and their respective facts.

Myth 1
Web services technology provides a “total and complete” EAI and B2Bi solution by itself—i.e., a solution for all integration needs.

Web services technology is not EAI and B2Bi in and of itself. Rather, Web services technology is another means of enabling EAI and B2Bi, one that can significantly change the traditional point-to-point integration approach. Web services technology can’t eliminate the need and use of EAI and B2Bi middleware frameworks.

Myth 2
Web services allow the creation of applications by pulling together services dynamically on the fly, enabling all the patterns of EAI and B2Bi, namely data, user interface, function/method, and business process-oriented integration.

In this generation of Web services, it’s possible to achieve only function/method-level integration between applications.

Myth 3
In its current state, Web services can be used for session- and transaction-oriented integration.

Web services are not transactional in nature and provide basic non-session-based “request/response” functionality. In addition, Web services standards don’t yet define security, operational management, workflow, business rules, transactional integrity, and other elements of an enterprise-ready computing platform. The next generation of Web services, however, will be functionally and technologically advanced, offering user interface encapsulation, transactions, service context, and security. At that stage, Web services technology will have the potential to streamline middleware integration.

Myth 4
Web services can be used securely over the Internet.

Security is one of the primary factors that will determine whether companies adopt Web services. Security also poses the greatest risk for this technology. Secured interoperability holds the key to Web services’ success in the long run. The key security requirements for Web services are authentication, authorization, data protection, and non-repudiation. At this stage of technology, standards for security, such as industry standards and support for use of digital signatures, are still being developed.

Myth 5
Web services are a brand-new technology that greatly enhances your return on investment (ROI).

Web services technology can yield a higher return on investment (ROI), but only when built on top of existing assets. In order to leverage existing EAI and B2Bi middleware frameworks and infrastructure, the integration brokers and application servers must provide an integrated development environment and platform for easily building and deploying Web services and service components. Since Web services work hand-in-hand with .NET and J2EE technologies rather than as a competing technology, all the leading J2EE and .NET servers and development tools have started supporting Web services technology.

Where and how to start using Web services
If the facts are so different from the myths around Web services, the natural question is where and how to start using Web services. As a starting point, identify areas and projects or subprojects in which Web services could work, such as non-transaction- and non-session-based information-retrieval scenarios. Just because Web services are the latest thing doesn’t mean you should pour hundreds of thousands of dollars into the technology, especially when the Web services standards are still evolving. Finally, it’s worth mentioning that you should use Web services for internal integration projects that are non-transactional in nature before you use them in B2Bi projects.