There are many advantages to using the Web services architecture over any other. In fact, some Web services applications would be expensive or impossible to duplicate using any other technology. One of the challenges for technical leaders is to discover opportunities in which Web services can be used to solve today’s problems. In addition, we need to be looking for Web services solutions to problems that are ever present, but never solved. These areas include the cost of doing business, in effect, the cost of software development, and the time that it takes to react to new market opportunities. In this hour, we will look at a fairly extensive list of the advantages that Web services provide over more traditional approaches. In addition, we will cover some concrete examples of what is happening and what can happen in the future using Web services.
In this hour, you will learn about the advantages of using Web services for
Many of the early adopters of Web services technology have concentrated their efforts at interconnecting legacy (established, reliable, operational) systems to each other. Their reasons for doing this are
Working on internal systems entails less technical risk than working with outside entities. For this reason, companies have decided to keep the trial-and-error phase of new technology adoption out of the spotlight.
Many firms allow their internal developers to gain experience on legacy systems before allowing them to interface with their customers’ systems.
To make a Web service useful, a client must exist. Internal projects give the developers control of both the client and the service.
Older solutions are problematic. Many of these projects replace older programs that were written using other, often inferior approaches. Many of these approaches, like flat file transfers, are fragile. Other development projects, written in CORBA or DCOM, tend to be expensive to maintain and enhance. For this reason, they are obvious targets for replacement.
Web services wrap nicely around legacy systems, regardless of the language that they were written in. Many developers roll their eyes when they are asked to work on 25 year old COBOL or PL/1 systems. They mistake old for bad. From the standpoint of management, an older software system that has been running the company’s shipping department for more than 20 years is worth its weight in gold, regardless of how uncool the technology is. Customers pay for products that get delivered properly, regardless of how stylish the program that managed the delivery process is.
The thought of writing, testing, and implementing a new system to replace one that already works well is a tough sell to a company’s management. Why would they pay money to replace a solid performer with one that is certain to be buggy for the first few months, if not years?
Web services can be written in such a way that they require little or no change to the legacy code base. They can be written to interact with the older code similar to the way that a graphical user interface (GUI) would. The end result is a state-of-the-art distributed system that retains all the equity that a company has built up in its legacy code base.
Any company that is going to succeed in the long term is constantly trying to lower its costs of doing business. These cost improvement programs are focused on both internal and customer-oriented systems. Web services provides opportunities to save costs in these areas:
Cheaper than a LAN—. It is hard to imagine any way of interconnecting computers that is cheaper than using the Internet. Essentially, every computer that can access the Internet could serve as either a Web service, a Web services client, or both. A LAN requires that you interconnect all computers with some sort of cable. The Internet allows you to connect via each computer’s existing service provider.
Low-cost Electronic Data Interchange (EDI)—. You might find some cost savings if you set up electronic data exchanges with your best customers and vendors. EDI has pioneered this effort, and Web services are poised to expand it in every direction.
Remote Status Reports—. The fact that any two computers can participate in a Web services transaction means that you can get a status report from any organization in the world at any time of the day or night. The potential savings from the elimination of paper-based reporting systems is huge.
Remote System Management—. There is virtually no limit to the amount of remote management that can be done using this technology. Most of the savings occurs when a technician can troubleshoot a problem from his own desk without incurring any travel overhead or expense.
Dynamic Routing of Service People—. Web services are being expanded onto personal digital assistants (PDAs) such as the Palm and Handspring models. This allows people who still have to travel from site to site to use just-in-time dispatching. Instead of planning the whole repair day in the morning, a truck can receive the next assignment when that worker is actually ready to work on the job. This can result in large increases in efficiency and less customer downtime.
For the past 20 years, the Holy Grail of software development has been the concept of code reuse. The idea of code reuse is as simple as it is intuitive. Instead of reinventing the proverbial wheel a thousand times, you invent it once and use it a thousand times.
The complete promise of code reuse has remained an elusive target. One problem has always been the packaging of the code. For code to be reused, it has to be created in a way that makes it easy for a new program to find and use it. If the code existed, but you didn’t know about it, you could not receive any benefit from it. If you knew about it, but it was written in Java, a Visual Basic developer probably couldn’t use it. The fact that Web services can interoperate regardless of the language that each of them is written in is a tremendous development in the code reuse world.
For some time, it has been possible to create a Web service–style system by interconnecting programs written to the DCOM and CORBA standards. Practically speaking, the torment associated with doing that was so great that only the most important problems were solved in this way. To make matters worse, most company firewalls block these types of transactions, making it impossible to implement them.
With Web services, there will no longer be a need to translate DCOM objects into CORBA and vice versa. For the first time in history, all major hardware and software vendors are in agreement that Web services should exist and interoperate seamlessly. The reason for this ecumenical feeling is that Web services technology can be implemented on any computer platform using any development tools. This keeps every vendor in the game and reduces the need for professional gripers to tell us why the other company’s approach is weak. Now they tell us that Web services is the future, but the competition’s toolset is weak.
This ecumenical bliss is underscored by the fact that a very fair-minded organization, the World Wide Web Consortium (W3C), is the official keeper of the Web services quasi-standards that they call recommendations. Most vendors have people who sit on W3C committees and steer the new proposals in the direction that they want to see them go. The end result is that everyone remains in synch with the Web services community as a whole.
The high level of vendor commitment to this technology lowers the cost of using it. Not only does competition drive down tool prices, but it also encourages innovation by pressuring the tool vendors to keep thinking outside the box.
Better tools mean faster development, which in turn leads to lower development costs. Another way development costs are lowered is by allowing a wide variety of programming skill sets to play in the game. If you have an army of COBOL programmers, you can hire one Web services guru to set up the infrastructure, and then have your staff write everything else in COBOL. If you use PERL, keep your development in PERL. Web services tools are on the market that interact with almost any language. Even if the tool support is weak for your favorite language, you can create the WSDL and SOAP messages manually and communicate that way.
Many vendors provide rapid development tools that go beyond what is available for creating user interfaces. Web services are based on the creation of both a service and a formal description of the service called the Web Services Description Language (WSDL) document. This document contains enough information about the service to allow a client to be generated. Instead of starting with a blank sheet of paper, the programmer of a Web service client starts with a generated client that can successfully access a Web service. He can then enhance that client to interact with the other systems on the client side. The time and learning curve savings from using this approach is significant.
Many modern development tools can also generate Web service code from functional descriptions. Although these services are more limited than hand development solutions could be, they offer the advantage of speed. Even for complex requirements, the generated part of the Web service code can get the project started. From there, the programmer can hand code the unique parts that are beyond the capabilities of the tool.
Every business guru from Tony Robbins to Steven Covey will tell you that the way to succeed in business is to get close to your customers. Vendors who succeed in integrating their systems such as orders, shipping, and billing are nearly impossible for their competitors to dislodge because they are woven into the business processes of those customers.
One example of this would be an automated reordering system. If you provided an automated way of interfacing to the point-of-sale system at a major food retailer, you could know, by sales data, when to send more disposable diapers to a certain store. The competition would have trouble breaking into that account because they can provide product but not convenience. Convenience can translate into big savings for a customer because it lowers his cost of doing business. Figure 2.1 shows this business interaction.
Many companies have systems that could be opened up without much risk. Contractors could provide status reports in this way to put their customers at ease. Car companies could track the progress of custom vehicle orders so that the customer could enjoy the process of buying that special car. Baseball teams could publish their internal statistics for the rabid fans to follow.
Some Web services can provide savings to your company, while allowing your customers better access. For example, allowing customers to manage their own account data frees up your internal resources and increases the accuracy of the data. When a customer’s shipping address changes, he could access and change that data via a Web service.
Modern corporations are anything but monolithic entities. Most companies are built on the foundation of business partners—other companies that have traditionally been classified as suppliers. Forward-thinking firms have concluded that the best way to lower costs is not to beat your suppliers down to get them to cut their margins, but to help those suppliers lower their costs. It is better to find suppliers who will allow a level of integration that will benefit both companies.
One example of this is outsourced human resources. Writing paychecks to engineers is essentially the same thing as writing paychecks to the dancers in a Broadway play, even though their daily work activity is very different. For this outsourcing to be truly less expensive, however, the HR vendors’ systems must be able to interact with their clients’ systems well.
Web services are ideal for this type of interaction. You can interconnect two different systems without making significant alterations to either one. This can enable an outsourced company to act as a Web services client in order to collect payroll and personnel data. Figure 2.2 shows these businesses interacting.
This level of cooperation between computer systems will open up new opportunities for virtual enterprises. A virtual enterprise is one that is made up of several smaller enterprises. For example, if a hotel in Orlando booked your room, scheduled your flight, reserved your rental car, and sold you tickets to the theme parks, you would be doing business with a virtual company. No single company owns airplanes, cars, hotels, and theme parks. Each company owns one of these assets and offers the others through partnership agreements. In fact, you could start a company that owns none of these assets. Your sole reason for existing is to provide one-stop shopping for these types of packages. If you have a strong advertising strategy and the proper business agreements, you could sell merchandise that you have never actually owned. Figure 2.3 shows these businesses interacting:
The key to making this type of virtual business work is the low-cost interconnection between computer systems. If the cost of interconnection is too high, your enterprise will have to pass on too much cost to the customer. If your customer feels that you are too expensive, he will bypass your site and individually purchase services from each vendor.
Fortunately, Web services make it possible to create interconnections for far less cost than traditional approaches. In addition, the time needed to program a new service connection is far shorter using the Web services approach.
Another new potential source of revenue can be found in charging directly for the use of your business processes. This area is so new that we have to go into creative mode to even think of examples. One example that comes to mind would be a cost-estimating system. It is critically important for construction companies to accurately estimate the cost of building a certain building. Normally, these companies write internal systems that they plug the details in to. The result is a report showing a cost breakdown for the project.
You could imagine a group of programmers breaking off from one construction company and starting their own software company. This company could hire the best estimators in the industry and produce a superior cost-estimating system. Every construction company would run its own numbers internally, but it could pay our new company to run them too. The combination of the two estimates would serve to either increase confidence in the original number or to flag a potential problem if the two numbers don’t agree. Figure 2.4 shows these businesses interacting.
Another place where a Web service could be a revenue generator is in the field of product design. Engineering analysis software is used in the design of nearly all the physical goods we use. The automobile industry is an especially heavy user of this kind of software. Analysis is performed on the plastic in a dashboard, the beams in a chassis, the vibration in a steering column, and so on. Normally, a virtual solid model is created in the computer and submitted to one or more of these analysis programs for evaluation. The result of the evaluation might cause a design to be changed to better meet its requirements.
The software packages that perform this work are very expensive and normally only used by companies that have a lot of this work to perform. Smaller companies must either do this analysis by hand or simply do without. If the vendors of these packages could turn them into Web services, they could then charge based on the usage and not by the license. This could allow that vendor to sign up new customers easily because the initial expense would be very low. In addition, the fees paid to the vendor would come out of the customer’s normal expense budget and wouldn’t require a capital expenditure.
Another opportunity for a new revenue stream would be in selling empty seats, mechanics bays, and so on. All service businesses have perishable assets. An empty bay in an automobile repair shop or an empty table in a restaurant is perishable. If it is not used this hour, it is wasted and cannot be retrieved and sold in the future. Finding a way to sell these empty seats, even at a steep discount, would improve the profitability of these businesses. A large tire and brake chain could create a Web service that prices the same procedures differently, depending on the demand. For example, a brake job performed at 10:00 a.m. on a Saturday would be charged full price, but at 8:00 a.m. on Tuesday, it might be half price.
A business with a fleet of vehicles could schedule them for maintenance based on the demand. They could write a Web service client that interacted with the brake stores whenever a maintenance procedure was required. The Web service could provide a dynamic price based on the demand at stores across town. The client would compare these prices to the cost of driving to each location and would choose the one that provided the best value.
In addition, consumers could use a Web-based version of this software. An applet might serve as the client running in a browser. The customer would enter his parameters such as the procedure needed, urgency, location of vehicle, and so on. The Web service would then provide a list of shops and prices. The customer could then choose the one that he considers to be the best value and could drive across town, if necessary, to patronize that shop.
Another type of customer-oriented Web service would be a towing system. A Web service could be written that accepts requests for a tow. Normally, this request would be created by a phone call to an operator at 1-800-tow-junk. A stranded motorist would place a high priority request at full price. If he is really desperate, he might even add a tip in the offer.
All the tow services that monitor this Web service have clients installed on Palm-sized devices. Whenever a tow is needed, it will appear on the Palm, along with the price offered. The first available tow truck will commit to do the job and accept it by clicking on the Palm device. After contacting the stranded motorist, he would get underway.
Not all tows represent emergencies, though. Car dealers, junk yards, and repair shops use towing services a lot. They are not in as big a hurry as a stranded motorist, so they would offer less for a tow. The tow truck would move these cars during slow times or even on a night shift when prices are best. Whenever an emergency comes in, he would go to it, make more money that hour, and return to the car dealer when it gets slow again.
Almost any business with excess perishable capacity is a good candidate for this type of empty-seat selling. The dynamic nature of the pricing can lead to better utilization of resources and higher profits. In low-tech businesses such as towing, a third party would be the likely Web service provider. The provider might even provide the Palm-sized devices to the trucks in exchange for a 10% fee on each tow scheduled through them.
In this hour, you learned about the advantages that might be available to you with Web services. We covered how Web services can be used to integrate legacy systems, lower operational costs, lower software development costs, and get systems done faster.
In addition, you learned how Web services can help you to interface with your customers better as well as with your business partners. Finally, you saw how Web services can help you generate new revenue and support new business models.
This section is designed to help you anticipate possible questions, review what you’ve learned, and begin learning how to put your knowledge into practice.