7.4 The platform issue - yet again

7.4 The platform issue ”yet again

It goes without saying, but it has to be said for completeness, that there are two platforms that need to be considered for each Web-service invocation:

  1. The platform on which the calling application is running

  2. The platform hosting the Web service being invoked

Within the context of this duality, one can easily identify the permutations shown in Table 7.3 as being likely candidates,

Table 7.3: Two Platforms for Web Services

Calling Application

Web Service Being Invoked

On the same system (i.e., collocated)

On the same system, on different (but homogeneous) partitions

On the same system, but on heterogeneous partitions (e.g., z/OS and Linux on a mainframe)

System A

System B

But System A and System B are of the same type (e.g., UNIX servers)

System A

System B

But System A and System B are significantly different

The platform issues, in the Web services context, as discussed in the context of both .NET and Java, pertain to:

  1. Capacity (i.e., how many concurrent sessions it can handle)

  2. Performance (i.e., delivery of expected response times under normal workloads)

  3. Scalability (i.e., what the upper limits are when it comes to handling increasing workloads)

  4. Overall stability in terms of reliability, availability, and servicability (i.e., the platform can meet the expected uptime criteria, given that mission-critical applications for Fortune 500 corporations require 99.999% uptime over a year)

  5. Vulnerability (i.e., the platform is noted for being safe from hackers)

  6. Manageability (i.e., provides the necessary tools for remote monitoring and management)

Though these concerns have been discussed as they relate to .NET and Java, it is now important to yet again reiterate that both sides of the Web-services model are platform independent in that the calling application for a Web service nor a Web service being invoked need to be restricted to a specific platform. This, as highlighted in Figure 6.1, does not mean cross-platform portability. It does, however, mean that the Web-services model is not confined to any specific platform permutations. Java and .NET are also not the only viable platforms for Web services or the applications that intend to invoke Web services. Any of the traditional platforms (e.g., IBM s CICS, BEA s Tuxedo) can also be used for either side. This is particularly germane in legacy modernization scenarios, as discussed in the beginning of this book, whereby proven business logic from existing mission-critical applications can be isolated and repackaged as Web services using host integration tools such as IBM s WebSphere Host Publisher. The bottom line here is that any platform, provided it offers an appropriate transport scheme, can be used for Web services “based application scenarios.

The goal when it comes to platform selection, however, is to ensure that the platforms selected adequately meets the performance, uptime, security, and manageability expectations for the overall application in question. The big danger here is ending up with totally mismatched combinations, such as a high-volume, mainframe-resident, mission-critical transaction processing application (e.g., travel reservation system) serving 50,000 concurrent users relying upon a crucial, oft-invoked Web service that happens to be deployed on an old Pentium III server still running Windows NT 4.0. But you cannot make generalizations even with this very uneven combination.

It is indeed possible, depending on the processing involved, that the out-of-date Windows platform may still provide the necessary functionality, with adequate resiliency to meet expectations, especially if the server is located in a data center that is manned 24/7. One assumes that one would not be as concerned if the platforms were reversed , so to speak (i.e., a VB application running on an old WinTel server relying on a Web service deployed on a newly upgraded, multimillion dollar mainframe). However, it is fair to say that mismatched platform combinations invariably warrant particular scrutiny to avoid costly breakdowns in expectations down the road ”when the application is in full swing, handling mission-critical production work.

The desirability of cross-platform portability, such as Java, is a contingency against mismatched platform pairing . If a Web service is portable, then one does have the option, albeit at a cost, of having it hosted on a different platform if one has reservations about the platform it is currently being offered on. Given that this platform specificity is primarily going to be an issue if a Web service is limited to Windows, one still could have other options to mitigate the situation. Key among these would be to acquire or license the Web service so that it can be run in-house, behind the corporate firewall, on a carefully tended, dedicated WinTel server ”or, per the current trend, on a WinTel blade on a server rack.

The bottom line here is that with all of the debate that has ensued around .NET and Java, enterprises now have enough background and parameters to evaluate the platform criteria for specific Web-service scenarios ”independent of whether Java or .NET even comes into the picture. With all of the various platforms and platform options available today, IT professionals, given a set of service-level criteria, should be able to craft appropriate pairings to meet expectations.

Web Services[c] Theory and Practice
Web Services[c] Theory and Practice
ISBN: 1555582826
Year: 2006
Pages: 113

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net