Where Is Most of the Activity Taking Place Today?

One useful way to determine when your organization should engage in building Web services is to look at where other organizations are focusing their initial Web services development efforts. Today, the biggest payback using Web services can be found in (1) improving internal business efficiency and reducing developmental costs; (2) conducting certain business-to-business (B2B) transactions; and (3) providing a slew of new "individual" services (such as anytime, anywhere, to-any-Internet-device messaging for individual users).

Let's take a closer look. First, Web services are being used to develop new customized applications. The InterPro and mhe.net examples in the previous chapters are good examples.

Second, Web services are being used in the automation of certain business-to-business transactions. Web services are far easier to implement than many of today's cumbersome Electronic Data Interchange (EDI) applications (which are used by many businesses to package information and share that information with business partners). And supplier-to-supplier B2B transactions are usually based on message passing (as are Web services). By reducing programming complexity and by taking advantage of the Web services message-passing architectural basis, Web services are growing well in this B2B market segment.

Third, Web services are being used to make available new "automated attendant" programs that can help people manage messaging and automate other elements of their personal or professional lives.

Web services (particularly UDDI and WSDL) are being used internal to the organization to help enterprises create an inventory of application modules (this inventory serves to provide application developers with a useful in-house object code repository that can be used to help them reuse rather than rewrite code). The primary benefit derived from "inventorying" existing applications is that an organization gains an understanding of what modules it has already developed or has at its disposal and this can help reduce or eliminate redundant programming efforts by developers who are not aware that an application module may already exist within an enterprise.

In other words, if your organization:

• Is currently undertaking the development of new, customized applications, then using a Web services approach may be justified now. Note, however, that you must determine the level of security, transaction rates, and reliability of your new custom application and supplement Web services with other products and services that can bolster your custom application in those areas. If security, high transaction rates, and reliability are primary concerns, it may or may not be the right time for you to implement Web services (depending on your level of confidence in using third-party products to augment your Web application server);

• Has a large inventory of object-oriented application modules (as many software development and professional services firms do), then your organization may be ripe for adopting UDDI and WSDL protocols today;

• Is looking for a potentially easier way to build B2B transactions, Web services may (or may not) be appropriate (depending on security, transaction, and reliability requirements);

• Is looking to open new market opportunities (such as the InterPro scenario in the previous chapter), then it probably should examine Web services architecture; or

• Is trying to provide personalized automated attendant services for consumers and customers, then Web services may prove to be an appropriate design architecture for building such applications.