At the beginning of the client/server era, remoting was mostly used for accessing a server's resources. Every database or file server is an implementation of some technique that allows code to be executed remotely. Programming these older frameworks was so difficult a task that few products except for these server-side core services implemented remoting.
Nowadays the building of distributed applications has gotten a lot easier so that it's quite feasible to distribute business applications among various machines to improve performance, scalability, and maintainability.
One of the key scenarios for implementing remoting is the concentration of business logic on one or more central servers. This considerably simplifies the maintainability and operability of large-scale applications. Changes in business logic do not entail your having to roll out an application to your organization's 10,000 worldwide users-you just have to update one single server.
When this centralized business logic is shared among different applications, this labor-saving effect multiplies considerably; instead of patching several applications, you just have to change the server's implementation.
The security of a company's vital databases represents a common concern in this time of Web-enabled businesses. The general recommendation is against directly connecting from the Web server to the database because this setup would allow attackers easy access to critical data after they have seized control of the Web server.
Instead of this direct connection, an intermediate application server is introduced. This server is placed in a so-called demilitarized zone (DMZ), located between two firewalls. Firewall #1 only allows connections from the Web server to the app server, and Firewall #2 only allows connections from the app server to the databases.
Because the application server doesn't allow the execution of arbitrary SQL statements, yet provides object-oriented or function-based access to business logic, a security compromise of the Web server (which can only talk to the app server) is noncritical to a company's operations.
In today's mid- to large-scale enterprises, you will normally encounter a heterogeneous combination of different platforms, frameworks, and programming languages. It is not uncommon to find that a bunch of tools have been implemented: Active Server Pages (ASP), Java Server Pages (JSP), PHP, or ColdFusion for Web applications, Visual Basic or Java for in-house applications, C++ for server-side batch jobs, scripting languages for customizing CRM systems, and so on.
Integrating these systems can be a daunting task for system architects. Remoting architectures like CORBA, SOAP, and .NET Remoting are an absolute necessity in large-scale enterprise application integration. (CORBA and SOAP are introduced and compared later in this chapter.)
Opening systems to third parties in a business-to-business environment is quite common nowadays. This process started with hard-to-implement EDI documents, transferred via proprietary networks, and is recently opening up for smaller companies due to the possibility of using SOAP, which is fairly easier to implement.
Order-entry applications, which allow your business partners to directly place orders from one ERP system to the other, constitute one example of an application utilizing this kind of remoting. More sophisticated applications are starting to be developed-address verification, customer creditworthiness ratings, and online price-comparison systems are just the beginning.