Building a business logic layer over multiple Web services: leveraging multiple Web services to build a truly distributed Web services architecture

Building a business logic layer over multiple Web services: leveraging multiple Web services to build a truly distributed Web services architecture – Feature

Rajesh Zade

Over the last few years, there have been significant developments in the Web services world. Many enterprises have embraced Web services to build business-to-business transactions and a uniform communication layer among applications over corporate intranets. This article discusses how to leverage application resident business logic by building a business logic layer over multiple Web services.

Many businesses are adopting Web services to gain access to applications and legacy databases that reside inside corporate networks (usually behind corporate firewalls). Web services have changed the B2B model from centrally located, exchange-oriented B2B APIs to distributed, corporate network-resident APIs. This model has gained huge popularity because it gives corporations complete control over the applications they run and also allows them to expose only those areas that are of interest to their business partners and those they deem appropriate to expose to the world. In the future it will be hard to imagine any businesses running all the applications internally without communicating with any other businesses or partners. Since Web services allow businesses to gain access to partial business logic and data residing within other businesses, the technology also opens up a whole new area for building a business logic layer that can operate over several other Web services in real time. The central idea of this article is how to build a logical layer serving as a Web service over other multiple Web services accessing remote applications and analyzing responses obtained from those Web services in real time. We use a simple case study based on JAX-RPC to build two Web services, “Timesheet” and “Insurance,” and also build a logical layer, “Payroll,” to evaluate responses from these two Web services. The “Payroll” client can easily be represented as another Web service that satisfies requests from such parties as your payroll processing company. We will also discuss EAI/BPM service integration techniques.

Web services, broadly speaking, are services offered via the Web. It is a platform-, vendor-, and language-independent, request-response model. In a typical Web services scenario, a business application sends a request to a service at a given URL using the SOAP protocol over HTTP. The service receives the request, processes it, and returns a response. The examples presented here are based on Sun Microsystems’ Java Web Services Developer Pack 1.1 (http :// pack.html). You will need to download and install JWSDP-1.1 on your machine to run the examples. (The code is online at ices/sourcec.cfm. Please read readme.txt carefully before running these examples.)

Using Multiple Web Services Within One Container

Consumers and providers of Web services are typically businesses, making Web services predominantly business-to-business transactions. An enterprise can be a provider of Web services and also a consumer of other Web services. For example, an HR department could be in the consumer role of Time Tracking and Insurance Tracking services provided by outsourcing companies, and a provider of a Payroll service to payroll processing companies. To be a provider of a Web service, a provider service doesn’t have to be a service that processes just local application logic or fetches local legacy resident databases, but can very well work as simply an adaptor to other consumer Web services.

In Figure 1, many Web services are in the provider role (time tracking, insurance, and others), and one is in both the provider and consumer roles (payroll).


The Payroll service consumes the Time Tracking and Insurance service responses to produce a response requested by external businesses in the form of a Payroll service.

A number of business applications can utilize such a design approach (see Table 1).

Case Study: “Build Payroll Service”

Let’s build a service layer as described above to produce payroll information. This service is based on the JAX-RPC API from Sun Microsystems. A similar service layer can also be built based on the JAXM API or by using a combination of two APIs. The “Payroll” service presented here is a client that utilizes the two consuming Web services, “TimeTracking” and “Insurance.” It can also be built and published as a “producer” service that responds to a service request from a payroll-processing agency.

We will create the following components to build this service layer:

* Insurance Service:

–InsuranceIF: Insurance interface that defines the service methods

–InsuranceImpl: Actual implementation of an InsuranceIF interface

* Time Tracking Service:

–TimesheetIF: Timesheet interface that defines the service methods

–TimesheetImpl: Actual implementation of the TimesheetIF interface

* Payroll Service (Client):

–PayrollClient: Client that invokes the above services to generate final paycheck amount

These services are deployed on the Tomcat server. The project is built using the Ant build system. Each service code resides in its own folder and each folder has the following set of files to build and deploy services on the Tomcat server:

* build.xml: Ant build for each service and client (uses targets.xml from “common” folder)

* config.xml: A configuration file read by the wscompile tool

* jaxprc-ri.xml: A configuration file read by the wsdeploy tool

* web.xml: A deployment descriptor for the Web component (a servlet) that dispatches to the service

* Property file for the ant build system

Service Invocation Flow

When it receives a request for gross pay, the payroll service invokes calls to get the total hours and the rate information from the Timesheet service. Then it makes calls to the Insurance service to get health, life, and disability insurance premium information. Finally, it calculates the gross pay and returns it as a response to the calling service.

Let’s discuss the Timesheet service further. We will not discuss the Insurance service since the implementation of both the services is very similar.

The Timesheet interface (see Listing 1) defines two methods, getHours(int empId) and getRate(int empId). Both methods take empId as a parameter and return hours billed for the current period and the consulting rate of the employee. A simple implementation of the service is described in Listing 2.

Listing 3 describes the configuration file for the Timesheet service needed for the wscompile tool and Listing 4 describes a configuration file read by the wsdeploy tool. The wscompile tool automatically generates the WSDL file when the service is compiled and deployed on the server. A complete listing of the WSDL file can be browsed when you visit the http://localhost: 8080/time sheet-jaxrpc/timesheet and click the WSDL link on that page. JAX-RPC takes care of marshalling and unmarshalling the data returned by the service methods.


Listing 5 describes the partial code of the payroll client that uses both Timesheet and Insurance services. As mentioned before, the payroll client can very well be built as a “Payroll” service that invokes Timesheet and Insurance services to compute employee salary.

EAI/BPM Techniques

Let’s look at how we can use our business logic layer along with EAI (enterprise application integration) and BPM (business process management). We will look at these options briefly and then apply the concepts to our case study. Business Process Modeling Language (BPML) is the language of choice to implement complex business processes as declarative business logic.

Today’s enterprises also consider Web services while implementing BPM and EAI. Enterprises are exploring new avenues to automate business processes and share business data across the enterprise, allowing departments to be more efficient and productive. There is a dire need for a full duplex, bidirectional solution to share business processes seamlessly and exchange data among ERP, CRM, SCM, databases, data warehouses, and other important internal systems within the company. Enterprises have been using EAI technologies that enable unrestricted data sharing throughout networked applications within the company. EAI is the process of creating integrated infrastructure for linking disparate systems, applications, and data sources across the corporate enterprise The implementation of EAI technology has been an expensive affair with proprietary interface implementations to inter act with various applications in real time With the nightmare of managing disparate applications, data, data transformations, and proprietary interfaces, corporations are hoping SOAP-based architecture of Web services will be a breather

The emerging BPM breed of software provides analysis, design, automation, and optimization of business processes They allow business managers and analysts to change the business process logic without changing the underlying IT pro grams. Many enterprises have applications where changing business processes involves engineers and programmers BPM is the foundation of next-generation EAI. BPML is an XML-based business process definition language. The Business Process Management Initiative’s ( mission is promote and develop the use of BPM through the establishment of standards for process design, deployment, execution, maintenance, and optimization develops open specifications, assists IT vendors in marketing their implementations, and supports businesses using BPM technologies. Enterprises are exploring Web services as viable option for EAI and BPM solutions to leverage their existing software assets The use of standard XML protocols makes Web services platform, language, and vendor independent, and an ideal candidate for use in EAI and BPM solutions.

Declarative programming techniques are used to capture the business logic your application as business rules and process models in the transaction logic and process logic layers. Transaction rules can be compiled into reusable components and executed within the Transaction Logic Engine. Process models are executed within the Process Logic Engine.

In this case study, we’ve implemented business process logic for payroll functionality. A business analyst can easily change the business parameters (integration points) regarding time tracking and insurance data extraction without changing the application programs to implement new business logic. Figure 3 is a re-representation of the case study from a BPML point of view. Instead of integrating with time tracking and insurance Web services, as in the case study, we are now integrating with enterprise products based on EAI or BPM. These products provide integration points that can hook into their applications. Once the data is obtained from these products, it can be utilized in real time by building a BPML layer. Figure 4 is a process diagram for our Payroll layer.



Web services as stand-alone processes in themselves are powerful interfaces to complete B2B transactions. By building a logical layer over multiple Web services, you can leverage application-resident business logic in real time and take Web services technology to another level. Web services can also be built over enterprise products based on EAI and BPM. Business Process Modeling Language (BPML) is an emerging language to build such a logical layer over enterprise applications.

TABLE 1: Applications as both provider & consumer

Industry Use

Mortgage Processing Loan applications can be processed based

on services such as “credit history”,

“account information”,”credit card

information”,and “debt information”.

Information obtained from these services

can be evaluated in real time to screen

prospective loan applicants.

Payroll Processing Our case study demonstrates a payroll

processing application that is based on

“Time Tracking”and “Insurance”services.

Retail Appropriate product prices can be

distributed as a service that is based on

other services such as “Product

Information”,”State and Local Taxes”,

“Shipping And Handling”.

Government Many government agencies such as IRS

can process tax information based on

several other services provided by federal

and state government departments.


* W3C Web services architecture domain:

* JWSDP-1.1: servicespack.html

* The Business Process Management Initiative:

Rajesh Zade has over 14 years of experience in the computing field and has been working in various Java, eCommerce, and Web services technologies since 1996. Currently, he works as a chief technical architect for NetCliff, Inc. RAJESH.ZADE@NETCLIFF.COM. Avinash Moharil has more than 14 years of experience in the computing field and has been working as a senior technology consultant and project manager in Silicon Valley. AVINASH.MOHARIL@NETCLIFF.COM.

COPYRIGHT 2003 Sys-Con Publications, Inc.

COPYRIGHT 2003 Gale Group