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

Many people confuse Web-based applications and services with network-based services. All Web-based applications and services are network-based services, but not all network-based services are Web-based. Two examples of this are the traditional voice services provided with
216 Chapter 12
Centrex or PBXs, or email. Email may or may not be Web-based; it depends on the email client and server. Techies reading email with Pine or Emacs, or users of Eudora, or office environments such as Lotus Notes are not Web-based. Web-based email, though, is becoming more popular (as discussed in Chapter 8) and is available as both distributed and centrally managed services. Generally, Web-based applications and services have the flexibility to benefit from attributes of a distributed and a centralized management structure. There are many flavors of Web-based services, and for now they fit into my analysis of general network-based services.
The name "Web services" confuses many people, including me, because while some Web services are similar to Web applications, other Web services have little in common with the Web. A Web service using HTTP to exchange SOAP messages is similar to a Web application because they are using the same application protocol to exchange information. Web services, however, do not demand the use of HTTP and are perfectly happy with other application transport protocols such as SMTP and FTP. A Web service using FTP to transport SOAP messages has nothing to do with Web applications. To avoid confusion in this chapter, I rename Web services to what I believe is a more correct name: soap services. It is thusly named because of the SOAP envelope that Web services utilize to transport messages between users. The name "soap services" fits the wide range of Web services.
While different, Web applications and soap services have some similarities. Both of these technologies give users the ability to experiment. Many tools for Web applications and soap services development come standard in Unix environments or are open source. Both of these technologies are based on standards that are open and freely available on the Web. This reliance on open standards that are freely available promotes experimentation and innovation by users with both Web applications and soap services.
Another important attribute that Web applications share with soap services is flexibility in the management structure they allow. Because of the end-2-end nature of both Web applications and soap services, it is easy to experiment with these technologies. Without asking the network service provider for permission, any two users on the Internet can implement a Web application or soap service without any changes to the network infrastructure. These two users are the only ones that know about this new experimental service, which means that nobody else on the Internet is affected by this experimentation. Once used by a large group, though, these same Web applications and soap services can display attributes of centralized management. When it is in widespread use, changes to the application or service do affect a big user group, which makes it hard to
Web Applications and Services 217
experiment with. This flexibility of Web applications and soap services to begin their life with a distributed management structure and then morph into more efficient centralized management is of great value in dynamic markets, as the theories from Part One discuss.
Web Based Applications
The Web has proven to be a flexible platform for many tasks. It seems everything is becoming Web-based sometimes with wonderful results. Banking at home on the Web or having Web-based access to information about my students saves time putting valuable data and useful services at my fingertips. Some Web-based applications are great for users and service providers. eBay is one example; users love it because of its ability to put buyers and sellers together. It also has a good business model because the service provider (eBay) makes money. Other Web-based applications are well suited for users but have yet to develop business models that support their continued existence. Examples of these are search engines and map/direction applications that are popular with users but may not generate enough revenue to sustain themselves. Still other applications have proven to be of little value to service providers, users, and investors as illustrated by the "dot-com" crash. Thus far, the Web and Web-based applications have evolved far beyond anything their architects imagined, creating and destroying vast fortunes, transforming business processes, and changing society.
Sometimes the idea of a Web-based application is good, but the implementation and/or the user interface is not. How many times have you given up hope of an online transaction and instead called the organization to complete your task? The interface is really bad when you can't even figure out how to call them. In this context, Web-based applications are similar to other application software ultimately the user needs to accomplish his or her tasks. Web-based applications that are not easy to use fail despite the value of the underlying application.
Previous << 1 .. 84 85 86 87 88 89 < 90 > 91 92 93 94 95 96 .. 128 >> Next