Full- and Support-level members must be government agencies, or partnerships of such agencies, from any level of government in the United States (municipal, county, state, tribal, Federal).
Associate-level members can be any individual, corporation, or government agency.
(For questions about future participation by academia, nonprofit organizations, or industry, contact email@example.com)
Contact firstname.lastname@example.org for details.
All Consortium members contribute to the evolution of the OJB platform and support the advancement of justice information sharing by enabling the reuse of low-cost technology in a collaborative model. All members also gain admission to an annual OJB Implementers Conference that will offer hands-on training opportunities, collaboration opportunities, and networking. And all members get support from OJBC staff experts to develop and/or implement information sharing capabilities.
Yes, the OJBC is a 501(c)(3) non-profit corporation, incorporated in the State of California in 2011.
OJBC is governed by a Board of Directors, which has final decision-making authority on all matters of Consortium governance. Full members of the OJBC are eligible to vote for and serve on the Board.
Over the past several years, SEARCH has helped incubate the OJBC by providing in-kind administrative support, and, since 2012, staff services to the OJBC Membership. Assisting with the startup of the OJBC has helped SEARCH fulfill its mission to support better justice information sharing. The Boards and Memberships of the OJBC and SEARCH foster a strong working relationship in support of their complementary missions.
The Features page describes these in detail. However, a quick list includes:
No, this is not the purpose of the OJB. The OJB is about the reuse of software across jurisdictions, not the sharing of members’ data with one another. This is not to say, however, that two or more OJBC members could not use the OJB software to enable access to one another’s information—and the fact that both members were using the OJB would ensure that they could do so in a standards-based way using inexpensive software to do so.
Other than some utility components, all OJB components implement GRA-conformant service specifications, which live in the ojb-resources-common component on GitHub. Each service is exposed as a web service defined by a WSDL that leverages the National Information Exchange Model (NIEM) as its information model. Where GRA reference service specifications exist, the OJB has leveraged them to the extent practicable.
These terms are defined by the Global Reference Architecture, the principal justice community standard for system interoperability. They are the building blocks of standards-based justice information exchanges.
An exchange begins with a connector, which responds to some kind of trigger—for example, a user initiating a search from an application, or data becoming ready for transmission to partners—by forming a message and sending that message in a standards-conformant way to an intermediary. The intermediary receives the message from the connector and applies business rules to it; these rules determine what happens to the message within an overall business process. After applying the rules, the intermediary sends the message (perhaps after transforming it) to one or more adapters that interact with systems in the receiving agency to either store or act on the information.
Incident reporting offers a good example. A connector at a law enforcement agency watches the records management system (RMS) database to detect when an incident report is approved. When a report is ready for transmission, the connector reads the incident data from the database, constructs the XML message, forms a web service message, and sends it to an Incident Reporting Service intermediary. The intermediary receives and inspects the message, and applies whatever rules have been configured. For example, it might transform the incident into a charge referral and send it to an adapter at the local county prosecutor’s office, and then perform a second transformation and send that to an adapter at the state law enforcement agency’s statewide incident repository. In other jurisdictions, the intermediary may forward the incident to a notification service that looks up whether any subscriptions exist for criteria that match the incident, and if they do, the notification service (which is also an intermediary) will send emails to the authorized subscribers.
Note: This is a hypothetical scenario and that the behavior of the incident reporting intermediary is entirely configurable. These steps, or different ones, may be performed at each implementing jurisdiction’s discretion.
For a more detailed description of the connector-intermediary-adapter architecture, see the SEARCH whitepaper on this topic .
The most important language to include in your RFP is a mandatory requirement that data in the system be available for you to query in a standards-based, non-obfuscated manner. The system should come with documentation that describes the structure of the underlying data, and the mechanisms available to query the data.
Ideally, the interface to the data should conform to industry and justice community standards, such as the GRA and NIEM. But if this is not feasible for the system developer/vendor, it is possible (and generally not difficult) to build adapters and connectors that “translate” between the system’s representation of information and the standards-based interface. However, this requires that the developer/vendor provide clear and complete documentation of the structure of the information and the means of accessing it.
Be sure to monitor the OJBC blog for further guidance on this topic.
First, the OJB rests on the notion that there is a lot more commonality across jurisdictions than many people think. We have demonstrated this over the past 3 years in the founding member jurisdictions.
Still, there are differences across jurisdictions. We encourage users to read a series of blog posts in coming weeks that highlight the architectural features in the OJB that enable jurisdiction-specific extensions. In the meantime, we are happy to address specific questions on the OJB User Mailing List or Developer Mailing List.
Be sure to monitor the OJBC blog for further guidance on this topic.
The “core” OJB functionality is licensed under the Reciprocal Public License, Version 1.5. Consult the license text for the details of the rights, privileges, and obligations associated with the license. In summary, though:
Licensees do not need to become a member of the OJBC to access and use the OJB source code. However, membership offers specific benefits, including support from OJBC staff experts to develop and/or implement information sharing capabilities.
The OJBC exists to promote a more effective and efficient justice system through improved sharing of information and automation of business processes. The consortium seeks to accomplish this by lowering the barriers to entry, and by creating a way for jurisdictions to reuse what others have done at very low cost. The OJBC also wants to ensure that further usage and expansion of the OJB software is also shared back with the community, so that the entire nation can benefit from new capabilities. Open source licensing helps to accomplish all of these aims.
The OJBC also seeks to accelerate justice information sharing by enabling government agencies as well as industry partners to leverage a common platform for building information exchanges. The Consortium believes that the nation will be better off investing resources in building exchanges rather than re-inventing and re-building core infrastructure components that could easily be shared.
Unlike other open source licenses, the RPL requires the sharing of derivative works—extensions of the OJB platform—back with the community, so that the platform continues to grow and expand.
The OJBC presence on GitHub: https://github.com/ojbc/
It is widely accepted among security experts that “security through obscurity” is really not secure at all. The best information security techniques are those that are exposed to public scrutiny; this is certainly true of all the principal encryption and signature algorithms in common use on the Internet today. It is only through public scrutiny that flaws and weaknesses can be exposed and fixed rapidly.
Recommended reading regarding open source security:
The OJB’s security mechanisms largely rely on open industry standards, such as Web Services Security (WS-Security), Security Assertion Markup Language (SAML), and related standards. These standards have all been carefully reviewed by the Global Justice Information Sharing Initiative and adopted into Global standards such as the GRA and GFIPM.
The OJB uses open source implementations of these standards that are in use in hundreds of thousands of applications and organizations worldwide.
There were two primary reasons for choosing the Java platform:
Absolutely. In fact, most of the deployments of OJB components in the founding member jurisdictions are on Windows servers. The Java platform has been highly optimized for running on Windows, and the OJB components run just fine in Windows. Adapters can interact successfully with SQL Server databases. Federated identity components integrate very well with Microsoft Active Directory through the standards-conformant Active Directory Federation Services.
In addition, it is feasible to integrate OJB components with web services authored in .NET languages as long as those web services conform to the GRA. For example, an agency or vendor could build a .NET web service to integrate an existing .NET-based system, and “plug in” this web service to the OJB federated query, making the data in that system accessible through the query.
In all likelihood, yes. The OJB is an implementation of the justice community standards that are designed to enable linking of disparate justice systems from law enforcement records systems to prosecution and court case management systems to corrections information systems, and beyond. Because most of these systems today do not support the full set of these standards “out of the box,” the standards (and therefore the OJB) have software components called “connectors” and “adapters” that enable standards-conformant interfaces without disrupting the existing systems.
Current OJBC members have contributed adapters and connectors for some of their existing systems; the plan is to add additional adapters and connectors in the future. The OJBC also welcomes the participation of the vendor community in building (and even contributing) adapters and connectors for their systems to enable interoperability with other services in the OJB. Join the OJB User Mailing List or Developer Mailing List to discuss or contact email@example.com.
Yes, as the term “ESB” is commonly defined. The OJB supports inter-agency and cross-domain information sharing through an architecture based on message exchange among loosely-coupled components. Messages are always NIEM-conformant XML documents, and the interfaces between components conform to the GRA and GFIPM. The open source infrastructure underlying the OJB—especially Apache Camel—provides typical ESB support for format and protocol transformations (e.g., reading data from databases into XML, consuming “legacy” batch flat files in various formats and converting to XML, etc.), and fully supports enterprise messaging requirements like guaranteed message delivery with persistence. It is based on open industry standards and can be deployed on virtually any modern computing platform, locally or in the cloud. Commonly supported ESB functions such as publish-subscribe, aggregation, filtering, and transformations of messages are all supported.
If your definition of “ESB” differs from this, ask about it on the Developer Mailing List.
The OJB is not a single application that you “install”. It is a set of many components that work together to exchange information between agencies.
Currently, we use Maven to install all the OJB components (other than the web applications) into Apache Karaf, the OSGi container that we use. For testing or demonstration purposes, it is generally easiest to do this from a local Maven repository on the same machine that hosts the container. In the near future, the OJBC will maintain a public Internet Maven repository for all open-source components, and it will be possible to install from there once that is set up.
It is possible to install all of the components for the federated search/query application on one machine for demonstration purposes. We plan to put together a how-to guide on this in the near future.
No. OJB components interface to these systems to enable query and push/pull of data to and from them. The OJB is like UPS or FedEx, in that it picks up packages (messages) from the sender (using a standard interface), transports them securely to a routing facility, which then routes and transports them securely to their final destination. It does not store, produce, or maintain any records itself, and the applications and processes that produce and consume the messages at each end are separate and distinct from the OJB.
Only in specific, constrained circumstances:
The first step in deciding how your system plugs in is to identify the services that your system would provide via the platform. For instance, if your company provides a law enforcement records system, you may wish to enable your customer agencies to submit incident reports to their justice partners or to the FBI N-DEx system via the OJB. In this example, your system would need a “connector” to extract new incident reports out of your RMS and send them to the Incident Reporting Service.
The service specifications for this are available in GitHub: https://github.com/ojbc/main/tree/master/shared/ojb-resources-common/src/main/resources/service-specifications/Incident_Reporting_Service. In examining that specification, you will note that its information model closely follows the FBI N-DEx IEPD, so if your product already adheres to this de facto community standard, then you are most of the way there. Your connector would simply package this message into a web service and send to the Incident Reporting Service as configured in your customer’s jurisdiction.
No. The OJBC always welcomes contributions—and contributions must be open source. However, it is perfectly acceptable to develop adapters and connectors and license them in any way you choose as long as those components are not derivative works of components that you have licensed from the OJBC.
Yes, if the interfaces to/from your product adhere to justice community standards and you can format messages according to the specifications adopted by the OJBC. In practice, this means your product must be able (either natively, or via an adapter or connector) to communicate via standard web services, and the content of the web services messages must adhere to the National Information Exchange Model (NIEM) Information Exchange Package Documentation (IEPDs) in the OJB service specifications.
The specifications are available in GitHub: https://github.com/ojbc/main/tree/master/shared/ojb-resources-common/src/main/resources. Or Join the OJB User Mailing List or Developer Mailing List to discuss … we are happy to help you.