|
In
the Commonwealth of Massachusetts, a key weapon in the fight against wel-fare
fraud is the ability of different Gov-ernment agencies to query each other’s
data. Using a store-and-forward messaging system based on IBM’s MQSeries,
the agencies can automatically perform batch queries, and real-time validation
will soon be possible when applications updates are complete. In fact,
the Commonwealth’s new system, known as CommBridge, developed by Systems
Engineering, Inc., provides real-time and batch communica-tions among
a wide range of agencies run-ning the MVS, AIX, Windows NT, Windows 95,
and HP-UX operating sys-tems on a variety of computer platforms.
This newfound ability is somewhat of a revolution for the Commonwealth.
Because the various Commonwealth agen-cies enjoy a great deal of autonomy
in their information technology (IT) opera-tions, each agency has developed
systems that are well-suited to its particular needs. The drawback, until
very recently, has been difficulty in communicating between the heterogeneous
systems operated by the different agencies. For example, Federal regulations
require the Department of Transitional Assistance (DTA) to frequently
match welfare recipients against wage data maintained by the Department
of Revenue (DOR). In the past, this required numerous time-consuming steps:
- mounting
a tape onto the DTA system
- downloading
the welfare recipient database
- delivering
the tape to the DOR office
- mounting
the tape onto the DOR’s drive
- running
the matching application
- delivering
the resulting matches back to the DTA, where they were re-loaded to
complete the eligibility cycle.
Needless
to say, this was a lengthy process that required a great deal of human
intervention at both DTA and DOR. Sometimes, the matching operation was
delayed because tapes were mislabeled or lost. To compound the problem,
the data centers for the two agencies were located miles apart, and there
was only one delivery run between the two centers each day. If the tape
was not ready by the time the driver left, matching would have to wait
until the next day.
These same problems occurred whenever data communication was required
among Commonwealth agencies. Among the many situations in which various
agencies need to exchange data, one example arises when the Department
of Social Services (DSS) places children in foster care as a result of
abuse or neglect. In that instance, the DSS must notify the welfare department
to reduce payments to the children’s parents, and the DSS financial system
must be notified to begin payments to the new foster parents.
About 2 years ago, the Commonwealth’s IT Division (ITD) began exploring
various approaches to automate data sharing among the different agencies.
This project gained impetus when the Commonwealth decided to move its
main data center from Boston to Chelsea, making it even more difficult
to share data with other data centers located in Boston. In addition,
various agencies had identified the need for real-time data sharing, which
was impossible under the existing system. ITD staff members identified
two candidate technologies, namely CORBA object technology and IBM’s MQSeries
message brokering approach.
Asynchronous
Messaging
After careful requirements analysis, the Commonwealth’s ITD selected the
store-and-forward asynchronous messaging approach, because it had a considerably
stronger track record in similar successful applications. A key advantage
of asynchronous messaging in this application is that it allows the various
Commonwealth agencies to maintain their closely guarded independence in
the application development arena. According to Anna dos Santos, Director
of the ITD’s Enterprise Applications Bureau, “Asynchronous messaging provides
a unique architecture that allows developers to write applications without
consideration for the eventual message destination. It is very unobtrusive
from the application programmer’s standpoint, requiring only very minimal
adjustments to the individual application. Another very important plus
was that MQSeries ran on each of the operating systems that we use.” Architecturally,
the new CommBridge store-and-forward messaging application is divided
into information request and information service components. In the real-time
mode, a set of functions called from a business application serves as
the request component interface to the CommBridge, while in the batch
mode, this interface is replaced by executable programs that can be distinct
from the business application that creates the data files. The information
service component in the real-time mode is a dynamic response queue that
is created with the initial request and terminates when the system delivers
the service response or the user ends the session. The information service
component in the batch mode involves static queues that are created during
initial interface set-up and configuration. Requests created by the business
application are placed on the transmission queue and handled at some point
in the future according to rules defined during initial set-up.
Transparent
To Application
With the new CommBridge store-and-forward messaging application, business
programmers are isolated from the complexities that middleware normally
imposes. The programmer simply includes simple verbs in their native programming
language. The requester-and-service program framework transparently handles
the routing of responses to the appropriate requester program.
Another key element of the Comm-Bridge is a set of program templates that
standardize the structure and simplify the development of new application
interfaces for file transfers, real-time transactions, and asynchronous
event-driven transactions. Once created, a given template can be reused
on other platforms by other users who require access to the same information.
Configuration files that reside on both the request and service hosts
define the parameters for the specific interface and are accessed by the
CommBridge functions. A configuration generator eliminates the time and
potential errors involved in repetitive manual coding to implement various
platform-independent MQSeries environments. The analyst simply describes
to the generator the key information regarding a proposed service or requester,
and the generator creates configuration files and installation scripts
for MVS, NT, AIX, and HP/UX servers, as well as Windows 95 clients. As
a result, the business programmer does not need to know the details of
the configuration files.
Pilot
Project
The CommBridge was initially developed within the context of a pilot project
involving the DTA and DOR. The focus of the pilot was to entirely eliminate
the tapes, and establish strong and rigorous electronic communication
links between the two agencies. The MQSeries for MVS/ESA was implemented
on ITD’s IBM 3090 mainframe used by some DTA applications, and was linked
to DOR’s Unisys 2200 platform via MQSeries running on a Windows NT server
at the front end. “The successful pilot proved that CommBridge provides
a unified architecture that allows platforms to communicate in the same
way without knowing what system is at the other end,” said Mark Heumann,
ITD’s CommBridge project manager. “A data matching process that previously
took several days was reduced to a matter of minutes. Larger monthly data
exchanges can now be run overnight and results returned the next morning.”
Anna dos Santos and her team are now extending the CommBridge concept
across the Commonwealth. “All of the Commonwealth’s systems will be able
to communicate with each other in a standardized fashion using standard
interfaces, eliminating the need to write a customer interface for each
system in the network. We want other departments to identify additional
services they can take advantage of. For example, our new Department of
Social Services system, Family Net, running on an HP 9000, needs to be
able to send payment requests to our mainframe accounting system. That
system is now in production. Other systems also need to access that same
accounting system service, and Comm-Bridge will be deployed for those
in phases.”
Unduplicated
Lists
The new CommBridge store-and-forward messaging system also met a long-term
need to be able to produce an unduplicated list of clients served by more
than one agency. Legislators frequently make queries regarding the needs
of individuals. In the past, determining the services provided to a given
individual would take an hour or more of phone calls to six different
Massachusetts social services agencies. In addition, in the development
of legislation, questions frequently arise as to how many people the Commonwealth
currently serves in a certain area. Jack Hornfeldt, Chief Information
Officer of the Executive Office of Health and Human Services, said, “This
was virtually impossible to determine in the past, because it required
manually collecting files from all of the agencies involved and running
an unduplicated count. With the implementation of CommBridge, this information
can easily be generated in batch mode. Real-time mode may be used in the
future for other transactions.”
Conclusion
Overall, the Commonwealth is very pleased with the performance of the
CommBridge. “The store-and-forward concept behind MQSeries makes a lot
of sense when you’re dealing with decentralized systems,” dos Santos said.
“They’re not always going to be available, so you want to make sure you
don’t lose your messages. It gives us the best of all worlds. CommBridge
will also enable the State to implement a more coordinated electronic
commerce system by integrating Web servers or other interfaces. It will
also enable the exchange of data with other states in the U.S., and with
the Federal government. [The] architecture and design [can] be expanded
almost infinitely.”
“CommBridge has allowed us to build a framework for a more transaction-oriented,
online environment,” dos Santos concluded. “As new applications come on
stream, the online and real-time characteristics of MQSeries will become
more important to us in our future plans. Once systems and departments
are able to share data, that opens up a whole range of things they can
do. The system will save us considerable tax dollars by maximizing our
revenue, streamlining operations, and reducing fraud.” MM All of the Commonwealth’s
systems will be able to communicate with each other in a standardized
fashion using standard interfaces, eliminating the need to write a customer
interface for each system in the network. 30 Messaging Magazine November/December
1999
|