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
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
Developers employed by software
There are at least three distinct scenarios on the supply side, as originally highlighted in Table 1.2. These are as
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
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
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.
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:
The role of Java versus Microsoft s .NET
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
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
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
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
The Java-based Web services solutions, whether Web services or tools, in