in black and white
Main menu
Home About us Share a book
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Network services investment guide - Gaynor M.

Gaynor M. Network services investment guide - wiley publishing , 2003. - 322 p.
ISBN 0-471-21475-2
Download (direct link): networkservicesinvestment2003.pdf
Previous << 1 .. 87 88 89 90 91 92 < 93 > 94 95 96 97 98 99 .. 128 >> Next

Microsoft is now supporting soap services, which it defines as follows [5]:
A Web Service is a unit of application logic providing data and services to other applications. Applications access Web Services via ubiquitous Web protocols and data formats such as HTTP, XML, and SOAP, with no need to worry about how each Web Service is implemented. Web Services combine the best aspects of component-based development and the Web, and are a cornerstone of the Microsoft .NET programming model.
Microsoft believes developers need a choice of languages, but not a choice of platforms. Microsoft insists on servers running its Windows software. Microsoft has built a snazzy development environment, complete with GUIs and drop-and-drag programming. It allows for building basic soap services without needing a sophisticated programmer. The architecture Microsoft has designed is language independent because it allows third parties to implement compilers for any language. This language-independent environment has value for several reasons: leverage of your current expertise, reuse of existing code, and using the best language for the task. Unfortunately, .NET insists on the Windows operating system. This is very constraining, as one can't leverage current expertise if it's not Windows, nor can one use Unix, Linux, or other operating systems. Finally, .NET limits the choice of hardware to smaller Intel-based systems.
Web Applications and Services 223
Language independence is very important, but platform dependence is very constraining, which implies that Microsoft is half right.
Remote Method Invocation (RMI) [6] was Sun's entry into distributed computing. It is tightly coupled to the Java programming language because both client and server must be written in Java. It's a nice, general distributed environment allowing a Java program to invoke a method on another network-connected computer that is running a Java Virtual Machine (VM). Sun's entry is perhaps the weakest because of its tight coupling to the Java language; DCOM and CORBA, on the other hand, are language independent. RMI works well in the Java environment: It is very network friendly, and it handles the details of data and code serialization for transport across networks. If the only programming language were Java, this would be a very attractive solution. Java, while popular, will never be the language of choice for all applications. The biggest problem with RMI is its tight coupling with the Java language.
Sun now believes in soap services as the standard way to integrate IT systems, which it defines as follows [5]:
. . . an application that exists in a distributed environment, such as the Internet. A Web service accepts a request, performs its function based on the request, and returns a response. The request and the response can be part of the same operation, or they can occur separately, in which case the consumer does not need to wait for a response. Both the request and the response usually take the form of XML, a portable data-interchange format, and are delivered over a wire protocol, such as HTTP.
Sun believes in platform independence for implementing soap services as long as you use the Java language to implement this service. This is the write-once-run-anywhere philosophy of Java: As long as the machine has the Java Virtual Machine (VM), your Java application runs fine (well, maybe). The idea is to build a soap service on one system and then port it to another platform, with little or no change to the software of the soap service, which works sometimes, but not always. Sun recommends using a Sun server, but its standards don't insist on it (a good thing for users and vendors). Unfortunately, Sun is not open-minded about what language soap services should be implemented in Java is the only choice Sun is willing to accept. Sun believes that Java is the best language for Web-based services no matter what the soap service is a claim that seems hard to believe and harder to prove. The reason for Sun's
224 Chapter 12
strategy is simple to understand because Sun owns the intellectual property rights to Java. Sun is half right; you should have a choice of platforms, but you should also have a choice of language.
As expected, Sun's system is typical of Unix development environments it consists of many tools, with many options. This type of environment is flexible you can do just about anything. Unless you are a guru, it is not easy to figure out how to do what you want. Unix experts will like Sun's approach; they can still use Emacs, and once they know soap service development tools, software is quickly implemented. Unfortunately, for nonexperts, the learning curve is long and hard. Unix and Java together are a powerful combination, but becoming an expert is difficult. Developers who like Unix and Java will find Sun's soap services development environment easy to work with as well as highly effective.
Table 12.1 highlights the similarities and differences between soap services and previous distributed computing environments.
Previous << 1 .. 87 88 89 90 91 92 < 93 > 94 95 96 97 98 99 .. 128 >> Next