|
|
Even if you know what Web services are and what they can do, you need to determine when you should use them. Today too many new techniques flood the IT market without any critical analysis of their business usage and business payoff. It might be easy to say that you should always use Web services when you expose functions that you want to be accessible from other applications, but there are some concerns with Web services that you should know about before making your decision.
You should use Web services in the following situations:
When you need to connect different platforms and be able to exchange data between them.
Web services are powerful tools for overlapping the gap between different platforms. The simplicity of Web services and the human readiness of the result make Web services less error prone than such predecessors as CORBA and DCOM.
When you want to expose functionality from an old system and use it in new applications.
For instance, by exposing functionality that exists in the business legacy AS/400 applications, a company can boost usage of business-critical information. This makes it far easier to program toward Web services than accessing the AS/400 directly from new applications. It is also quite easy for administrators to configure access to the Web services. By using Web services with such old systems, you can reuse both code and data.
For general functions not used frequently.
Examples of such include central error reporting, application updates, and order and billing information, which can be made accessible through Web services.
When you need to send data through firewalls—for instance, in business-to-business (B2B) communication.
HTTP is often allowed to pass firewalls by default. This makes it easier than before to tie different systems together and still have firewalls between different parts of a intranet to make it harder for intruders to access a system. Since HTTP is the standard protocol for Internet, it proves to be no problem to integrate.
Microsoft wants you to use Web services everywhere—and we agree for the preceding scenarios. Their ease of use and natural isolation between layers and machines compensates for the little overhead you get when you use Web services instead of other Remoting techniques.
You should not use Web services in these situations:
When response time is critical to your system.
Today the performance of Web services is quite low due to the standard protocol they use and the packing and unpacking of data. With the HTTP design, no package can be given priority over another, and no guarantee exists that the pages will arrive in a certain order. Even if you could use a binary version for transporting data, it is not recommended for real-time applications, where time is critical.
Be also aware that a slow network can have impact on the response times. When retrieving many requests, long network distance can cause long response times. It is better to pack different requests into a larger one when communicating with a Web service over a distance to reduce the impact of a slow network. (Using chunky calls on methods, rather than having a chatty interface, will boost the performance of Web services.)
For single-machine solutions.
When you are developing an application running on a single machine, the use of Web services will not give you anything extra. In our opinion, it is wise to create the underlying business layers in a way that makes it possible to scale the application in the future by using Web services. This way you can meet new demands from the business further down the road. In Chapter 9, we will show you how to create the facade layer, making it possible to expose methods as Web services easily.
When homogenous applications exist on your LAN.
When you have only one platform (Microsoft, for instance) in your LAN, you will have better performance and ease of use if your applications speak with each other via DCOM (for old Windows DNA applications) or by using .NET Remoting (for new .NET applications). An interesting aspect of .NET Remoting is the ability to use .NET Remoting over HTTP similar to what a Web service does. With .NET Remoting, you also have the possibility of using a BinaryFormatter with SOAP to allow remote procedure calls (RPCs). Binary format is more efficient than the standard SOAP format due to lower serialization/deserialization overhead.
These are probably the only times when Web services should not be used. Even if the performance today is not quick as light, in the future the standardization of new kinds of transport protocols should change this situation. We employ Web services frequently, and find them very useful for reusing existing business values in a cost-effective and easy way. Microsoft also recommends Web services as a primary choice and .NET Remoting only in specific situations.
Most of the scenarios mentioned earlier for when you should use Web services are about integration. We will start to look into how integration and interoperability problems can be solved by using Web services in the next section.
|
|