1.4 How to create and use Web services

As with most issues pertaining to Web services, the first thing to note when thinking about implementing Web services is that there are two very distinct and different scenarios that have to be taken into account ”that is, Web services as a consumable versus Web services as a deliverable . Hence, implementation per se depends, and depends greatly, on whether your interest lies in using Web services to develop new applications or providing Web services to be used by others. Therefore, the first cut that has to be taken when looking at implementation- related issues is determining what side of the fence you intend to be on (i.e., the demand side as a consumer or the supply side as a provider). To make matters more interesting, each of these two camps can have very widely divergent players within them ”each with different motives and needs.

Let us start with the demand side. It is easy to see how Web services will be of immense interest and value to in-house programmers employed by corporations to develop and enhance proprietary corporate applications. These in-house programmers are thus seen by many as the predominant target market for enterprise-level Web services. This will no doubt be the case when the previously discussed issues such as security and manageability have been adequately addressed, but these are not the only enterprise-class software developers who are likely to want to use Web services.

Developers employed by software vendors are also likely to want to avail themselves of best-of-breed functionality available in the form of Web services ”provided, of course, they meet the reliability, integrity, and cost (i.e., pricing) expectations of the company as well as the particular software project. In many instances there is likely to also be political and support-related issues as to the desirability (and even wisdom) of including dynamically invoked third-party software components into a commercial application that is meant to be sold to other corporations. However, that, fortunately, is not the issue at hand at this point. The issue here is that even on the demand side there can be considerable variance as to how and when somebody would want to use Web services ”and consequently also as to how he or she would want to go about realizing the implementation.

There are at least three distinct scenarios on the supply side, as originally highlighted in Table 1.2. These are as follows :

Software vendors (or individual software developers) interested in delivering new functionality in the form of Web services
Software vendors with existing commercial applications interested in making some of the functionality from these applications available in the form of Web services
Enterprises , which are not software vendors, and which may now wish to use Web services as a mechanism to market and deliver proven, business process “related software functionality culled from existing, mission-critical legacy applications

Suffice to say that each of these camps will require somewhat different tools to realize their objectives. For a start, the enterprises that want to get into the legacy modernization game, as discussed earlier, will want to start off with business logic “capturing, host integration tools such as IBM s WebSphere Host Publisher. Host integration tools, in the main, rely on a highly visual (i.e., screen I/O oriented) paradigm that isolates and captures specific elements of business logic by stepping through an actual transaction associated with that business logic (Figure 1.18).

Figure 1.18: A screen shot related to testing a newly created Web service from IBM s WebSphere Studio ”one of the premier tools for developing, deploying, and using Web services.

They do not require access to the application s source code or the expertise of programmers familiar with the inner working of the application. They can, in general, be used very successfully by software developers who have instructions as to how to invoke and navigate through the required transactions. Host integration tools may also be of use and value to the software vendors that want to market functionality from existing applications ”though they typically have the advantage of having ready access to the source code of the applications in question. Consequently, they have the option of culling and packaging the requisite functionality into Web services form ”from scratch, so to speak. Similarly, software vendors interested in offering new functionality, in the form of Web services, will typically opt to do that using their preferred, in-house development methodology, given that competent programmers can, within reason, create bona fide Web services using any programming language and software development environment.

1.4.1 How to circumvent implementational pitfalls

There are three fundamental issues that any person involved with implementing Web services, whether on the supply or demand side, will invariably encounter at some stage ”in one form or another. These three issues are as follows:

Platform selection
The role of Java versus Microsoft s .NET
Advantages of utilizing Web services development tools such as those offered by Microsoft, IBM, BEA, and so forth

At this juncture, it has to be stressed that Web services are truly platform independent. This platform independence applies to both sides of a Web services configuration (i.e., the usage side as well as the provision side). This is indeed the case, because a Web service is a run time “invoked external subroutine, running on a different machine that functions by accepting input parameters in the form of an XML document and returning the required results also in the form of an XML document. Therefore, applications that use Web services can run on any platform. Web services are also totally platform independent. They can run on any platform, whether a mainframe or a PC. Web services also may be developed on any platform without any implication whatsoever as to where or how they are going to be deployed. Hence, there are no platform-related restrictions of any sort when it comes to any aspect of Web services. This all-around platform independence should never be forgotten or underestimated. Consequently, there are no limitations as to which Web services can be used by which applications or where they can be developed or deployed.

The platform independence of Web services, as previously discussed, is also in no way related to Java. Though many of the super heavyweights that promote Web services have Java-centric offerings, Java is just another programming scheme as far as Web services are concerned ”keeping in mind that Web services, in addition to being platform independent, are also totally programming language agnostic . Thus, Web services can be developed in any language. Web services may also be used by applications written in any programming language ”irrespective of the vintage of that language.

Therefore, applications being written in Visual BASIC or C++ can readily invoke Web services functionality being provided by legacy programs written in COBOL, PL/I, or even BAL. In the same way, Java may be used to create Web services or to develop applications that use Web services. Applications being developed in Java can use Web services being provided by software written in any language, including Java, whereas Web services emanating from software written in Java can be used by applications written in any language. Just as with platform independence, the programming language neutrality of Web services has no boundaries. It is truly any-to-any when it comes to programming language interoperability. It thus also provides a bridge between the old and the new when it comes to software programming methodology.

Despite the platform and language impartiality, Web services, in their role as the new programming paradigm for the next iteration of Web evolution have, nonetheless, become the latest battlefield in the now decades-old IBM versus Microsoft vendetta. This is, however, somewhat ironic, since many of the pivotal Web services “related standards (e.g., SOAP, WSDL, UDDI, BPEL4WS, WS-Security, and so forth), as shown in Table 1.1, are the result of open and close collaboration between IBM and Microsoft. What is clear, though, is that the standards were created by technocrats, whereas the vendetta is being fought by the combatant and aggressive marketers. Microsoft s Web services push revolves around .NET, whereas that of IBM now revolves around the Java-based WebSphere Application Server and WebSphere Studio. Chapters 3 and 6 are devoted to addressing this issue from all angles.

The one major downside to the .NET initiative is its lack of platform independence. Although Web services developed by or running on a .NET server can be used with impunity by applications running on other platforms, including IBM mainframes and iSeries, the .NET-based applications, Web services, and tools can only run on the Windows system ”with the Windows servers, in turn , only running on PCs. Many, especially those who have become hooked on Java, find this platform restriction galling.

The Java-based Web services solutions, whether Web services or tools, in marked contrast, can and will run on multiple platforms ”including Windows 2000/2003 servers. This is the rub. However, as stated unequivocally earlier, you have to be very careful when trying to draw a fine line here about platform independence. In some cases, possibly even most, it may not really matter where a Web service is running ”provided that it meets the requisite reliability, resilience, security, and performance expectations. Thus, it makes sense not to get too religious about this issue. There will be more on this later in the book. With the major Microsoft and Java tools for developing Web services being discussed in Chapters 3, 6, and 8, it is sufficient to close this chapter by noting that proven tools for developing, deploying, and testing Web services are available, at a minimum, from IBM, Microsoft, BEA, Sun, SAP, webMethods, and so forth.