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

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 .. 85 86 87 88 89 90 < 91 > 92 93 94 95 96 97 .. 128 >> Next

Web-based applications allow flexibility in management structure. As discussed in Chapter 8, centralized Web email exists (Hotmail), as do more distributed models provided by ISPs running the POP protocol with a Web interface. In general, Web-based applications are able to take advantage of the attributes of centralized and distributed management. This is true in several ways: user domain, management of data, and the ability of end users to experiment. The email example explains how Web-based applications such as Hotmail have a distributed group of users that cross many
218 Chapter 12
user domains, while other Web-based email applications have a more limited domain (see Chapter 8 for details). The email example also illustrates how Web-based email services may have both distributed and centralized management in the context of data management: Hotmail users manage messages on the mail server (a centralized structure), but ISP POP-based Web email systems download messages to the user's machine (a distributed style of data management because the user manages the messages). Web-based applications allow user experimentation because of the end-2-end nature of Web protocols. Once large and successful, these Web-based systems become harder to change due to their broad base of users; this is an attribute of more centralized architecture. Thus, Web-based applications have the strengths of both the distributed and the centralized management structures.
Web-based applications can be developed in a very distributed manner because setting up a Web server and experimenting with Web pages and applications are trivial. It's possible to keep the URL of the Web-application completely isolated from everybody else in the world. It's also possible to limit a Web application to a narrow group of users, such as the faculty link at Boston University, which allows faculty access to student information, making this a distributed architecture with a well-defined group of users. Changes to this system affect a known group of users. This is unlike an application such as MapQuest that provides maps and driving directions to a general audience, which is a more centralized structure and therefore harder to change. An environment that allows easy experimentation is exactly what is needed to find Web-based applications that meet users' needs due to the high uncertainty in this new area.
Soap Services
The questions companies ask, such as, "How should I integrate my many different IT systems" or "How can I maximize my return on investment (ROI) when building new IT applications?", seem to have the same answer soap services. In theory, soap services allow interoperability between heterogeneous systems, but it's too early to determine if this lofty goal will reach fruition because of the high level of market uncertainty. Most vendors (Microsoft, Sun, IBM) agree about the high-level aspects of soap services they are based on open standards such as XML and SOAP. The architecture of soap services promotes modularity and easy experimentation because they can be designed with end-2-end structure, which, as discussed in Chapter 3, promotes user experimentation. Currently, the most debated details focus on the server, rather than the client, and include
Web Applications and Services 219
what platform is best to build soap services on and what language is best for developing soap services. Fortunately for users of soap services, the value of these services depends on the architecture of the services, not the platform on which they are implemented. While the future of soap services is unclear, it is clear that they facilitate integrating vastly different information systems.
Everybody agrees on the need for infrastructure that permits easy implementation of and experimentation with new applications. There is no agreement, though, on how to reach this goal. Microsoft believes in its .Net strategy, but Sun, IBM, and others don't share this vision. For my argument, it doesn't matter what the specific technology will be, as long as it allows users to develop new applications. For now, everybody agrees on the big picture about how to exchange information using standard protocols such as SOAP and XML between any two pieces of software running on any two computers, as long as they are connected on a network and follow the standards.
Soap Service Background
Soap services provide a standard way for heterogeneous systems to exchange information. As discussed in the text that follows, soap services are not a new idea, but rather they are the continued evolution of many older ideas. What is new about soap services is that they are based on open standards that are accepted by everybody. These standards include the message structure (SOAP), how data is encoded (XML), the API detailing the interface that explains how to use the service (WSDL), and how to register a service so others can discover its existence (UDDI). At the highest level, a soap service is a resource on some computer invoked by sending it a message following the SOAP protocol. This SOAP message contains the information needed to perform the soap service. For example, Figure 12.1 illustrates a simple soap service to report the temperature for a city. This weather-service is listed in the yellow pages of soap services, along with directions for its use. The client can look up the soap service and call it to find the temperature in Cambridge, Massachusetts. Both the request and the response are sent in a SOAP message. This information is encoded in a standard way: XML. Because all soap services agree to use SOAP and XML, they allow any client access to these soap services as long as the client follows the standards. This is very similar to how a Web browser gives users access to Web applications. Soap services are not a new idea, but rather, the next generation of Remote Procedure Calls (RPC) [1]. Soap services promise the Holy Grail to IT professionals: a standard way to link any two systems so that they can exchange information.
Previous << 1 .. 85 86 87 88 89 90 < 91 > 92 93 94 95 96 97 .. 128 >> Next