Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Case Study
When used properly in an enterprise network environment, SOAP can provide a dramatic increase in application robustness and overall response time. A telecom company foresaw a dramatic annual increase in the number of high speed Internet access orders it would receive on its customer Web site. The daily estimated increase could be in the neighborhood of 10-fold by year's end.
Given the size increase in expected orders and some issues with the existing architecture, a better solution was required. This solution needed to provide an exponential increase in response time, the ability to be distributed across multiple tiers in order to share memory and network resources, and the capability of sharing resources across two firewall boundaries. In addition, the public Web site was deployed using Java servlet and JSP technology, whereas the DMZ and private network were deployed using Windows 2000, NT, and SQL Server. Obviously, platform interoperability creates another problem for any system architect; for the purposes of this project, it would become vital. SOAP was chosen for server-to-server communication by implementing standards that are consistent across all platforms.
In order to understand the need for redesign, it's important to understand the system that would be replaced. The previous system, as depicted in the following figure, relied on the use of RPC calls via SQL Server stored procedures on a staging server. Each order that was taken by the JSP-based Web site would submit an order record (or rather, a host of them) into a SQL Server that was located in a DMZ. The domain SQL Server, which initiated cross-firewall remote procedure calls to the staging server, executed a nightly process. Multiple stored procedures, on both the domain and DMZ staging server, were required for all data validation to occur and for the flow to happen. Next, the domain server ran a host of local stored procedures, which made RPC calls across the firewall to the staging server, which also made hosts of other stored procedure calls, eventually sending the resulting records back across the firewall to the domain server. Each individual order required about 25 cross-firewall requests, and 15-20 stored procedure calls distributed across each server. At the beginning of the redevelopment process, it was taking about 10-20 seconds per order.
Figure 4 SQL Server-initiated RPC Communication
){kind=link}
Think of the impact of growth—if the company maintained the previous architecture and order volume increased exponentially, each "nightly" run could turn into an 80-hour (give or take a few) process. In this case, an order submitted via the Web site may not show up in the domain database for several days. If the order had not yet been picked up by the domain server, the next day it could delay order processing. Not only is speed an issue, but data integrity and customer information persistence are obviously important components to consider. Obviously, a new architecture was needed to accommodate the company's growth.
The new architecture needed to submit orders as they came from the Web site, automatically, all the way through the DMZ and into the domain database server. It would enable a semi-real-time order flow and eliminate the need for a nightly batch import process.
Initially, the Apache-SOAP implementation was deployed onto the Java Web server. The Java servlets that consume the order data and transfer it to the staging server were augmented with the Apache-SOAP packages. The servlets were redesigned to build an XML document via the XML DOM approach. This XML string is then transmitted via a SOAP call to the firewall that separated the Web site from the DMZ, where a COM+ listener accepts the XML input, creates the order, and returns a response containing various bits of information. From this point forward, the user is disconnected from the process, though they have received all pertinent information required if they need to make changes to the order via a call center.
Further analysis revealed that queuing technology was needed to enable an asynchronous messaging methodology. The COM+ component stored the XML data onto a queue using MSMQ. A separate process then picks up the messages as they come into the system for further conversion, as required by the domain database. This converted XML is once again transmitted from the DMZ area to the domain through the DMZ/Domain firewall, where it is once again queued. A queue was used in this location to protect the database component architecture from becoming overloaded. This satisfied a management requirement that Web order processing should not impact the day-to-day business.
To provide the database with a steady order flow, the messages are queued inside the domain, in their final format, where they await component pickup. An MSMQ trigger then fires multiple instances of a COM+ component, which distributes each individual section of the XML request to its destination table by way of multiple stored procedures. For instance, the Customer portion of the XML document would be handled by a Customer component, which would send it into the database by way of a stored procedure, the Order section by a separate Orders component, and so on.
Figure 5 SOAP-based Solution
){kind=link}
The final outcome yielded a significant increase in performance and more real-time access to the data, despite the complexity of the system. By using SOAP, cross-platform and –firewall communication was made possible without the use of stored-procedure-based RPC. This fact alone frees up much of the server resources so that the database can concentrate on it's main purpose – data storage and retrieval. Additionally, given the fact that the business logic is pulled out of the database and placed into COM+ distributed components, enables greater resource sharing and distribution across multiple servers. The current architecture is distributed across six machines – two machines are utilized as queue servers, two for application logic, and two final machines that distributed the database storage.
At press time, testing had indicated that, for complete order submission and storage, a total of 1-2 seconds could be achieved, with little impact on existing systems that utilized the same network and database resources. The 3000% increase over previous daily orders had become a plausible reality, and the existing systems were minimally if at all impacted by the change. By using SOAP as a more modern method of RPC and order delivery, the client had achieved their goals and realized a more strategic position in the already competitive Internet telecommunications market.