This note is excerpted from a longer paper Building the Connected Enterprise.
The Internet promised to streamline business-to-business transactions and communication as never before. But because of the complexity, the lack of standards and the large numbers of disparate business software applications crisscrossing the Web - that promise has been a long time coming.
Web services (a poorly conceived name for the technology) are different from Web sites that help to connect people with technology and information. Web services are a set of technologies designed to automate connections across applications and databases. They are built upon a set of standards and protocols that all major technology vendors have embraced.
The benefit of this is that they replace "big bang" approaches to technology with targeted incrementalism. The business proposition in this scenario is much more compelling: Invest modest sums of money with relatively short lead-times (often six to twelve months) and generate tangible business benefits, particularly in the form of operating savings. In these challenging economic times, that's a powerful proposition.
I am often asked how a business can get started with web services. While the actual answer will cary with what the business wants to achieve with the use of web services, there are some basic steps that need to be decided on. The following provides an outline of the steps that an organisation will take in order to build a connected business using Web Services. Not all the steps are essential and there are many alternatives to the ones listed. But treat this list as a discussion point.
1. Select a business resource that can be supplied as a service
The trick in getting started with Web Services is working out which business assets are best recreated as a service. What may seem like a good idea at first glance may actually have problems down the line. For example, on-line mortgage applications could make a good Web Service. However, if the business application that actually processes mortgage applications is a proprietary one with poor opportunities for building connections into it, then having a good Web Service that makes access to mortgage applications easy may only compound the difficulties your customers have in getting a result from the Web Service.
2. Pick a platform for your Web Service
The two main choices you have are .NET from Microsoft and J2EE which is available from a number of sources, including IBM, BEA Systems, Oracle, Novell and Sun Microsystems. .NET has been written using Web Services from the ground up, whereas J2EE has retrofitted APIs to enable XML communications in the Java environment. But the choice between the platforms is more often than not made on whether the system is server-centric (J2EE is the preferred choice here) or client-centric (where .NET wins because of the Windows connection). Those who are concerned about Microsoft’s monopolistic tendencies take comfort in the fact that J2EE has a number of competing vendors who are keen on making products interoperable and standards-based.
3. Choose a development environment and an application server
If you choose .NET, then you will probably use Visual Studio.Net from Microsoft as your development environment, though you may choose to use an open source product or Borland’s Delphi. In the J2EE world, the choices are large and include WebSphere tools from IBM, Forte from Sun Microsystems, Extend from Novell, WebLogic Workshop from BEA Systems, and so on. The Web Service will need to be delivered on an application server. Again the Microsoft environment will be dominated by the new application server that Microsoft has put into Windows Server 2003. But the J2EE user will need to choose an application server, most probably from the company that provides the development environment.
4. Expose your web service for discovery
Web Services need to be able to describe themselves to other software resources, using a standard such as Web Services Description Language, or WSDL. But the real excitement of Web Services is tied to dynamic discovery, which has two different dimensions. One, a number of different services can be tied together to a single URL - these services can change over time but clients only need to know the one URL. Two, services can be listed in directories, that work like intelligent versions of Yellow Pages, using UDDI (Universal Description, Discovery and Integration) so that one software system can discover a service it needs.
5. Secure your Web Service
Scare-mongers pick on security as a gaping hole in the Web Services standards. For once, they are probably correct, though much work is taking place in developing standards that make Web Services secure. One significant issue in security is authentication – knowing that the sender of a Web Service is who they claim to be and that their message has not been tampered with. A number of security specialists, such as RSA Security, WestBridge and Entrust, offer products that focus on security concerns specific to Web Services, such as the lack of firewall protection and the exposure of multiple applications interfaces to the outside world.
6. Orchestrate your Web Service
Orchestration sounds like getting a bunch of musical instruments to work together to create something complex but unified like a symphony. That is exactly the analogy that the Web Services standards people are seeking – defining and executing the logic and rules that assemble disparate Web Services into a multi-step business process. A lot of standards are being developed in the area of business process orchestration, particularly by the Web Services stalwarts such as Microsoft, IBM and BEA, but a number of process and workflow vendors are also getting involved.
7. Connect your Web Service to an application
Web Services are not expected to replace the vast majority of business applications that already exist. However, if the applications cannot interface with Web Services, then companies will have to make a decision whether they want to continue using closed, proprietary software systems. Increasingly, business applications vendors such as SAP, Microsoft Business Solutions, Epicor and PeopleSoft are using Web Services standards and protocols to open up their own applications, plus we will see many new applications that are architected on Web Services platforms from the ground up.
Next Steps
If you get this far, your competitors will probably be way behind you. But you will be sucked into looking at many more ways in which you can use Web Services. At that point, you will probably experience a skills shortage in your organisation as you seek more and more developers and business analysts who can together orchestrate and automate business processes. You will also find that your early Web Services have been developed on multiple Web Services platforms, environments and toolsets. Pick on a single Java company to work with and figure out how you can deal with Microsoft, because many of your users will probably be using the next version of Office as their entry point into the world of Web Services.
And always ask the question of your developers, “Can’t we use Web Services instead?”
Comments