It's OSCAR Night

A Middleware Solution Lets The HP 3000 Shine In A Client-Server Environment

When you are writing the check for your phone each month, the question of "how didthey do that?" probably doesn't come to mind. Suffice it to say, however, the myriadconnections and switches through which any given long distance telephone call can berouted is mind-boggling. But handling that kind of complexity is what some companies, likeBilling Concepts (San Antonio, Tex.), do best.

Billing Concepts' Local Exchange Carrier (LEC) division, maintains the phone historyrecords, and more importantly the lifecycle of actions taken to address questions ordiscrepancies with one or more calls on behalf of the customer. The industry-leading, corebusiness is a comprehensive billing system that collects long distance charges fromtelephone users on behalf of more than 1,300 local telephone companies, including longdistance companies, operator service and information providers.

Core to this leadership is the 100 percent handling of billing inquiries from telephonecustomers. This frees telecom providers from maintaining this facet of customer support.

The more than 300 call center support representatives work from PC's running WRQ'sReflection to login to a HP 3000 and run the primary HP 3000 main support application(primarily written in COBOL and VPLUS). Data was replicated from the core system to otherapplications which required it. Needless to say, the startup time CPU requirements, numberof sessions and the series of database opens consumed by this architecture were immense.

Startup times, particularly around peaks (shift startup) were unacceptable. Theinterface, all in HP VPLUS, began to show it's weaknesses. In addition to call centersupport personnel, there were other business users who required access to the data:Managers and administrators had periodic needs to view customer accounts or handle"escalated" sites.

Premier Software Technologies's (Cupertino, CA), Open Services Catalog and ApplicationRepository (OSCAR), however, introduced a middleware solution, which allowed BillingConcepts analysts and engineers to reorganize the COBOL logic into atomic subroutines.Middleware enters as the underlying technology for which different client-serverimplementations manifest themselves. At some point, a collection of application layerscomprise a client-server application, but the very nature of client-server programs makesit difficult to draw only a "dotted" line around the software we used to know asthe application.

For organizations evolving their applications into a collection of Application Serversproviding "business services", and a collection of Application Solutionsproviding human and machine business process interfaces, where does the scope of an"application" begin and end? Well, it doesn't. The application becomes thecollection of services and interfaces in support of an organization's logical businessprocess. And middleware is the communication between these layers.

OSCAR's middleware solutions encapsulates these subroutines, effectively publishing tothe network the subroutines interface signature. With these new "headless" andindividual (or atomic) functions (OSCAR calls them Services), accessible via the OSCARmiddleware, engineering was able to build new C++ and Web clients. These new front endswere built for different classes of users: each leveraging the back end set of serviceswere engineered and connected to the new MPE Services.

Client-server is both a relationship and a communication pattern. But clients are not just Win32 desktop applications. A client is a generic application layer interested in subscribing to a service provided by another application layer (e.g., a server). So, what is client-server? Let's try this: client-server is an n-tier application. Tiers communicate using a courteous "request/reply" messaging model. The benefit is a separation of application functionality into organic, easier-to-change, application layers.

Interestingly, there's a very simple parallel introduced by the Internet. The http protocol of "get/put" is a very clean match with the "request/reply", thus making "request/reply" middleware very suitable for Web clients. It does help to weave this Provider/Subscriber model back to the original. Because we cannot definitely state what client-server applications are -- or are not -- we must think of client-server in terms of a "Logical Model", and a set of "Design Values".

The layers within the Logical Model communicate using the "request/reply" protocol:

User Interface <-> User Task Logic <-> Business Logic <-> Data Resources

Value 1: Decouple in order to Recouple
Value 2: Expressive Systems
Value 3: Reduction in the cost of change

Because the deployment of the first 33 of these services, new "requesting"applications have been adopted. Billing Concepts' Interactive Voice (IVR) application isnow able to take voice information, format the data, and re-use the same services.However, this unanticipated integration is a common phenomenon.

Encapsulating MPE IMAGE and COBOL business logic, with true procedural middleware,provides for a transparency to other developers and the platforms/technologies they eitherchoose or maintain. The goal, therefore, of client-server is not new graphical interfaces,but rather a de-coupling of the platform and technology.

OSCAR engineers servers rebuild the application logic into a collection of services onthe HP 3000 box object-oriented paradigm. Clients (GUI, kiosk, batch) issue"requests" for services to a Connection Manager process. The Connection Managerresides on the HP 3000 box. The Connection Manager is responsible for recognizing incomingrequests, and launching the appropriate server which can handle the request. The Server,in turn, provides the response to the requesting application. Servers are MPE processes,they do not consume a session.

The Connection Manager can pre-allocate Servers, such that they are "hot" andready for incoming requests. This feature allows the MPE machine to be prepared for saythe call center's morning shift. The Servers, which support the same 300-plus call centerclients, consume one-third the CPU cycles as did the direct login using the old VPLUSclients.

Premier Software Technologies provides unique CGI Trader programs which can be used,rather quickly, to arrange service result data and dynamically format it into HTML. Thisserves as a starting point for future Web redesigns, using Web Application Servers.

The benefits are:

  • Reuse of C++ clients, Web clients, batch programs, IVR.
  • Leveraging MPE for business transactions, not database read/insert (the ODBC model).
  • New interface paradigm and technology decoupling.
  • Reduction in CPU usage and user licenses.
  • Call Center productivity --
  • Improved desktop integration --true Windows client enables integration with all other Win32 applications.

Future projects include:

  • Integration with IVR and CTO.
  • Distribution of the Web interface to the end customer, self help customer support.

So, you may be asking, "How is this different from database middleware such asODBC, ADBC, JDBC?"

Unique to OSCAR, is that it does not use ODBC or distributed database accesstechnology. OSCAR deploys a complete Application Server layer -- sitting above Image,sitting above the existing business logic. The customer organizes business logic and imagecalls into atomic services.

These services are invocable from any other TCP/IP connected platform and language.Clients, or "requesters" make connections to servers, call API's to invokeservices through "request" messages and receive services results from"response" messages. The OSCAR middleware does not dictate what the requestorstechnology must be: 3GL, 4GL, WEB servers, servlets, and many others.

-- Jon van den Berg, is CEO, Business Development for Premier SoftwareTechnologies.