To bring scalable integration to its flagship court case management application, Justice Systems Inc. selected MuleSoft’s Enterprise Service Bus. The first production implementation using Mule’s ESB was a large Midwestern court with several hundred users and a diverse mix of integration points. The system is in production with Mule’s ESB orchestrating the message traffic with a persistent architecture to avoid information loss. With court-specific messaging isolated in Mule, Justice Systems’ application now takes a standards-based, straightforward approach to outside integration.
Based in Albuquerque, New Mexico, Justice Systems Inc. (JSI) has been automating court systems since 1982. More specifically, Justice Systems is in the business of case management solutions and has been very successful in its niche with an enviable install base of over 600 courts that include prosecutor offices and four state-wide implementations.
For many years, Justice Systems relied on a client-server architecture model where most interfaces to external law enforcement entities were individually crafted with custom code, according to the needs of the court Solution Accelerated custom exchange development Cost savings to court by automating exchanges previously handled manually Decouples court-specific integration modifications from main product code Benefits and the specifics of its outside agencies. Recently, Justice Systems developed FullCourt® Enterprise, its next generation case management system using a secure Java-based case management platform with browser access for all court users. With this most modern version, JSI was determined to take a more flexible approach to outside agency integration.
The goals were to make common outside agency integration a standard offering, avoid custom coding, and lower the costs of developing truly custom integrations. To accomplish these goals JSI needed an integration solution that was easily configured to accommodate court-specific needs.
Justice Systems was implementing a large Midwestern court system with several hundred users where integration played a key role in the court’s daily activities. This court would be the first implementation of the new integration solution. The court’s exchange touch points included interfaces to the county jail, multiple police departments, traffic school, collections agencies, victim notification, and connections to JSI’s own Prosecutor and Public Defender packages.
Selecting an ESB
From past experience, JSI knew the impracticality of writing a multi-protocol messaging system, so the first step of even deciding to look for an off-the-shelf product was an easy one. The next step appeared easy because a quick survey of the Enterprise Service Bus (ESB) landscape showed surprisingly few contenders. Don Harrington, the integration developer at Justice Systems says,“We looked at what was available and some solutions were large, sprawling, environments and much more expensive and complicated than we needed. We wanted a robust, well-supported tool that was targeted to moving and transforming messages; we didn’t need to reorganize our enterprise. Some open source products seemed too small, lacking widespread adoption and functional companies behind the products.” After weeding out the too small and the too large, JSI narrowed the options to two viable candidates: Mule Enterprise Edition and another company-backed open-source ESB.
Initially Harrington was excited about this other company’s ESB, “It seemed to have all the pieces we were looking for in an ESB. I tried a test case, pulling a police citations flat file from a directory, transforming it into XML, and bringing it into our FullCourt® Enterprise product with ActiveMQ. I assumed the technical crux would be the ActiveMQ configuration. To my surprise, I discovered out-of-the-box, this other ESB did not work with flat message formats; it needed the message to be XML. From this ESB’s support sites I realized the general view was: there is no reason to work with out-of-date flat file formats because structured formats are better. Perhaps they are better, but Justice Systems does real-world integration, legacy systems have to be considered and they are generally far less adaptable than newer systems. I kept running into odd complexities.”
The other viable candidate was Mule Enterprise Edition. Harrington recalls his initial impressions, “With regard to technology, our client base is very conservative, so seeing early on that Mule was used in the financial sector was a good sign. Mule was simple to download and had an active user community, which was important. The examples had broad coverage and Mule was up and running with little effort. My flat file import task that gave me trouble in the other open-source ESB was not a problem with Mule. It was smooth from the start and I just kept building on my knowledge.
Once Mule had proved itself, Justice Systems worked out an OEM agreement with MuleSoft. Jim Mortensen, CTO at Justice Systems Inc. notes, “The partnership addressed distribution needs for our courts. We have courts ranging from very large to very small and the agreement scales across the entire range so we can use Mule in any court with integration needs. The agreement also provided additional support and training.”
Using Mule’s ESB insulates JSI’s FullCourt Enterprise application from the implementation specifics of communicating with the outside agencies. The alternative, old-school method is extending the large court management application so it manages connectivity and formatting for all external exchanges in each court. Then the application is released with all supported courts’ exchanges or with clusters of court exchanges in regional variants. From the perspective of a case management solution provider, writing custom code for each court to manage information exchanges with external agencies is impractical and inefficient. Letting custom extensions creep into the core product’s code base becomes increasingly complicated over time. It has the potential to slow, or even destabilize the product. This approach also requires additional development effort, release coordination, and testing, which in the end translates to higher costs for the courts needing exchanges.
Any information exchange with an external system can be a tricky beast. It is rarely something that is written once, tested internally, and court and the outside agency. The two organizations may be on separate timetables, start with different assumptions, have different skill sets, or even different motivations. It is very common for one side to complete the development and a period of weeks or months pass by until the other side comes online. The process can be compared to building the transcontinental railroad where both sides are working out of sight from each other with a plan to join up somewhere in the middle and drive a golden spike. They are not so much working together, as they are working toward each other. This means there are many revisions along the way to perfecting a new information exchange. It is best if the revision/fix cycles are dealt with outside of the mainline code that actually runs the court.
Building a loss-proof architecture
FullCourt Enterprise creates and maintains the official court record. If this becomes corrupted or develops holes, judges become extremely unhappy. The referential integrity of the court’s official record must be ensured. In a messaging application this is managed through persistence.
FullCourt Enterprise communicates to the ESB using ActiveMQ messaging. Messages are persisted every step of the way, local to FullCourt Enterprise and local to Mule, so if any component fails, communication is lost, a database fills up, or a system is rebooted, new and in-transit messages will be saved. Once the failure is fixed, the persisted messages immediately flow to their destination, without loss of information or continuity.
NIEM — the language of integrate justice
The integrated justice space, which encompasses public safety, immigration, disaster management, intelligence, and homeland security, uses a highly-structured XML message format known as NIEM or National Integration Exchange Model. The idea is to have a unified format to move information between dissimilar agencies that can be rapidly connected without extensive mapping effort. Being fairly new, NIEM is in the early adoption stage and the government is incentivizing agencies –such as court systems– with grants to incorporate NIEM into their external interfaces. At the same time, court systems are traditionally very conservative and somewhat slow to embrace new technology. Their outside agencies, or exchange partners, are often even more resistant to change. Mule simplified Justice Systems’ task of treading this fine line of supporting both NIEM and legacy systems. Justice System’s flagship product, FullCourt Enterprise, creates and reads its messages in a NIEM XML format If the outside agency speaks NIEM, then the message is sent to the agency in the default NIEM format using whatever transport mechanism the agency supports. If the outside agency does not support NIEM, then Mule transforms the NIEM XML into a format the agency can digest such as fixed-length, delimited, or vendor-specific XML. This flexibility has worked out well for Justice Systems and its courts. The courts do not have to force outside agencies to adopt the NIEM format, but it remains readily available for grant qualification if the court decides to use it.
By using NIEM XML as the format created and consumed by FullCourt Enterprise and putting Mule in the middle to manage connections and transforms to the outside world, the pieces were in place to integrate this Midwestern court’s outside agencies. The connectivity and volume needs ranged from simple to complex. On the simple side, some exchanges like the check printing package and traffic school consumed flat files and used shared directories for reading and writing messages. Several of the exchanges hosted FTP sites where the messages were picked up or delivered including collections agencies, victim notification, and police citation import. Justice Systems also uses Mule for seamless integration between its internal products. FullCase®, JSI’s Prosecutor and Public Defender package, communicates to the court through a rich set of about 30 different NIEM messages. The messages are exchanged through FullCase database tables using JDBC connections. On the more challenging end of the exchange spectrum are the jail and multiple police department connections. For these, Mule hosts Web Services and presents call interfaces for the agencies to place and pickup messages, along with a check heartbeat method to verify connectivity.
Mule’s multifaceted ability to deliver messages does have the potential for abuse. Harrington cautions against getting overly creative, “During development and QA we needed to look at messages that came through every step of the way. Integration spans a lot of environments. We were using a Windows-based browser talking to a cluster of Linux application servers connected to another Linux machine that held a single instance of standalone Mule Enterprise. The testers were having problems getting to the Linux system. I suggested configuring Mule with a multicast router on the outbound leg to email a copy of the message to interested testers and developers. QA loved it at first, but I don’t know that I would do it again because in the thick of testing some people had upwards of 125,000 unread emails and system administrators were starting to grumble.”
In all of the exchanges, the FullCourt Enterprise side uses a NIEM format and communicates to the Mule ESB through Active MQ. Mule then acts as a universal translator using the most appropriate transport method to the other side, while communicating in the outside exchange’s native format.
Using a new product on a large project spawns numerous questions; one of the reasons Justice Systems chose Mule was because there was a real, staffed company backing the product. Mule had the broad authorship and oversight advantages of open source, coupled with the locus of ultimate responsibility supplied by MuleSoft.
Don Harrington has a real appreciation of the support he received, “We leaned on MuleSoft’s support organization quite heavily in our development stage; they were both knowledgeable and highly responsive. Their turnaround was immediate with either an answer or a targeted question. Some support organizations are either slow or a black hole, giving you some ‘make work’ tasks up front, as if they hope you will stumble across the answer on your own without them having to do any work. Not MuleSoft. The immediacy of their support was refreshing. By finding workarounds for things like ActiveMQ issues, rather than simply say it was not MuleSoft’s problem and send me to ActiveMQ, MuleSoft demonstrated a real commitment to my success. I have been in the software business for 30 years and MuleSoft’s support organization is the best I have encountered.
Bridging the transport and format divide
When asked what he liked about his part in taking this court live, Harrington says, “What pleases me most is the robustness of the system. When we brought up this first large court using Mule I was somewhat nervous. A court messaging interface has a lot of exposure. If Mule failed, the court and hundreds of users would soon be dead in the water because outside agencies such as jails and police supply the feed of offenders and incidents that create new cases. Our testing looked good, but until you put a system like that under a sustained, production load you are never really certain. As with any go-live of a major implementation, issues came up and were immediately addressed. I kept waiting, but nothing Mule-related dropped in my lap. Toward the end of the first week I began to relax. Mule never failed or misbehaved. Mule just runs; it elevates robust to the level of bulletproof.”
Careful is an adjective that describes certain industries, industries that encompass the financial sector, aviation, and court systems. The first risks money, the second life, and the third brushes against freedom and reputation. Failures or mistakes in these areas can do far more damage than simply derailing business processes. These traditionally conservative sectors require systems that are largely immune to failure and when the rare anomaly occurs, it must fail safely and recover; nothing — life, money, nor freedom — is lost.
Justice Systems Inc. knows the business of courts and over the course of a quarter century has fostered loyalty across an impressive number of courts. Tool selection is an important aspect of providing this cautious base a trusted system that automates court processes, while securely preserving the official court record. MuleSoft’s Enterprise Service Bus was the right choice for this vital architectural component of managing exchanges. Messages are sent, transformed, persisted, and delivered. Meanwhile end users are spared any awareness of the underlying complexities of NIEM XML formats, flat files, Web Services, FTP sites, or database connections. What an end user in the courts sees is seamless integration with other agencies. An information exchange that is invisible and taken for granted is an Integrated Justice Information System that is functioning very well.