Remoting the Business Logic

Team Fly 

Page 449

You may notice that all the work is done by the GetItemDiscount stored procedure. This means that we can change our discount policy by editing the stored procedure at the database server, without even looking at the middle-tier component's code. This is an added bonus for the specific application, but you can't count on this. A complicated business rule may require quite a bit of code in the middle tier, and you can't always implement business rules at the database level. When this is possible, you can simplify deployment even further (no need to touch the application's code, just change the stored procedure at the database). However, you shouldn't place an additional burden on the server just to avoid the deployment of a new component. In our example, the rule requires the execution of a non-trivial query against the database and we can't avoid it.

Remoting the Business Logic

As we mentioned, one of the benefits of building components, especially in large applications, is that we can deploy them on a single server (or a small number of servers) and service a large number of clients. The servers on which the components reside are called application servers and they're fast machines, usually connected to a database server through a high-speed link. The application server is where the business logic is executed. If your corporation changes a business rule, you can revise one or more components and install them on the application server, and all clients will see the new component the next time they request it. It's not uncommon for the application and database servers to be hosted on the same machine. When the system is overloaded, you can add application and database servers as needed. It's not a trivial task, but this is the way to build a highly-scalable application. Scalable applications are written so that they can be spread over multiple servers. You can add multiple application servers to scale out the business components, as well as database servers to scale out the database. With some form of load-balancing software, client requests are directed to the least loaded server at the time.

Another good reason for building components that can be executed remotely is that not all components may reside on your corporation's servers. Today's applications may need to work with resources outside a corporation's environment. Consider a Web application that accepts orders and calculates shipping costs. To calculate the shipping cost, you may have to connect to the database of the shipping company and interact with a component that can calculate the cost of a shipment, given its source and destination, and the weight of the goods to be shipped. You may also wish to display the progress of the shipping, if this information is available from the shipping company. Many online stores display the progress of the shipment online. This information comes from the shipping company, not from the merchant's database. The merchant's system requests this information from the shipper and displays it for its own customers.

Given the need for remoting components and different systems to talk to one another, we'll explore .NET's techniques for invoking components on remote systems. The two techniques are Web services and remoting. Web services are simple to set up; remoting can be substantially more difficult, but ultimately faster and more flexible. Web services are actually based on remoting, but they hide many of the underlying details.

First, we're going to host the business component on the web server and expose it as a Web service. All the clients on the network will call the Web service to retrieve the discount. Then we'll use remoting to access the middle-tier component on an application server.

Team Fly 


Visual Basic  .NET Power Tools
Visual Basic .NET Power Tools
ISBN: 0782142427
EAN: 2147483647
Year: 2003
Pages: 178

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net