Broker architecture for Web services
Prior to Web services, making B2C or B2B applications Web accessible was laborious, and in B2B Web systems the communication protocol used was specific to the application platform. With Web services, the communication language and protocol are standard.
What are Web services?
Consider the following example. A Federal Law Enforcement Agency (FLEA) has a database application with a stored procedure (legacy program) that takes as input one or more of the following: Social Security Number, First Name, Last Name, Date of Birth, Place of Birth, and so forth. The output of the program is detailed personal data. For instance, if SSN is input, the program will output the other fields just listed.
FLEA wants to make this program available as a Web service to Local Law Enforcement Agencies (LLEAs). How will the interaction work? LLEAs will create an XML document with input parameters. It will then use SOAP to send the XML file to the FLEA Web service. The Web service will perform the computation and return data in an output XML file, which is delivered to LLEAs using SOAP.
The Web services architecture consists of XML formatted files for exchanging information and SOAP for communication between applications. The actual format of the input and output XML documents is defined in the respective XML Schema Definitions (XSD) by the Web service.
Because the idea of Web services is similar to Web content (in terms of simplicity of publishing and accessing applications), there are mechanisms for application providers to publish descriptions of their service and for application users to search for Web services. WSDL is the mechanism for publishing the Web service name and XSD. UDDI is a way to search for services.
What is the broker architecture?
Consider a more realistic situation: LLEAs and a variety of other authorized organizations access the previously discussed Web service and other related applications from FLEA and other agencies. Applications that request a service are called client applications, and those that provide a service are called server applications. Client organizations may include employment agencies, credit agencies, and LLEAs. Server applications include those that retrieve personal data, past addresses, credit history, criminal records, tax records, and so on. These legacy server applications are hosted by different organizations.
We have a situation in which multiple organizations are requesting information from several service providers. A broker is a central medium that makes the information transfer happen: It is a common gateway/address for client applications to access a wide variety of services. These services may require a broker to interact with only one server application or multiple server applications. Brokers perform the following functions:
- Receive SOAP requests in XML format from client applications.
- Authenticate the request and check for authorization.
- Depending on the nature of the request, compose calls to multiple server applications. Composition includes creating a list of input arguments for each server application and sequencing the calls to server applications. Output arguments from, for instance, the first server application may be input arguments to the next server application.
- Collect data from all the legacy server applications and transform into output XML. The output XML must meet the specifications in XSD of this Web service. This XML with SOAP header information becomes the response that is sent to the requesting client application.
- Publish all the services offered. In this example, the services are Bio-data single source, Bio-data multiple sources, Bio-data and address history single source, Bio-data and address history multiple sources, and all other combinations with credit history, criminal record, and tax history. If available, the broker can connect to multiple sources for the same data. A client application would look up one of these services on the UDDI and request the service by sending an input XML document. The XML document received by the client application in response will contain the requested information if the process was successful.
In order to accomplish step 3, the broker must provide plug-in adapters to which legacy applications are connected. Each legacy application requires a plug-in adapter. For instance, adapters will be required for each of the following types of legacy application: COM/DCOM, EJBs, specific ERP programs, and stored procedures. (Note that all Oracle stored procedures use the same plug-in adapter.) A plug-in adapter in the broker is responsible for making connections to the legacy application, sending function calls with parameters to the legacy application, receiving output from the legacy application, and transforming this output into an internal data format specified by the broker. In step 4, the data returned from all the legacy applications is transformed from a broker’s internal format into the Web service’s output XML format.
In addition to the plug-in adapters, the Broker needs a recipe or a script that it can use to translate a Web service request into calls to multiple legacy applications. As an example, consider Listing A in XML format.
Conclusion
In conclusion, a broker architecture for Web services provides:
- A common gateway/address for accessing all the legacy systems as Web services.
- A standard method for transforming legacy applications into Web services.
- A method for calling several legacy applications in response to a single client request.
The broker architecture is useful from a client perspective because it removes the pain of managing calls to multiple server applications (even if each is a Web service). Instead, the client makes one call, creates one XML file, and receives one XML file.
From an application provider perspective, the broker minimizes the effort to create Web services out of legacy applications and standardizes administrative tasks like authentication, authorization, and error trapping. These tasks are taken care of by the broker rather than by individual services.