FAQs

Full member

• $85,000 annual dues
• 500 hours of dedicated staff support per year for on-site or remote technical assistance and/or development work
• Participate in the governance of the Consortium through eligibility to serve on and elect the Board of Directors
• Admission to annual OJB Implementers Conference

Support member

• $24,995 annual dues
• 150 hours of dedicated staff support per year for on-site or remote technical assistance and/or development work
• Admission to annual OJB Implementers Conference

Associate member

• $995 annual dues
• Up to 10 email or telephone consultations per year with Consortium staff to support OJB implementation
• Admission to annual OJB Implementers Conference

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 info@ojbc.org)

Contact info@ojbc.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:

1. A federated query “engine” that offers a consolidated interface for submitting searches and queries to multiple data sources and aggregating the results for presentation to users.
2. A web application that provides a browser-based interface to the federated query engine.
3. A subscription-notification capability that allows for the creation and storage of subscriptions (“alerts” for the occurrence of specified events) and subsequent notification (currently via email) when those events occur.
4. A web application that provides a browser-based interface to the subscription-notification capability, allowing users to create subscriptions manually.
5. Interfaces to systems that can automate the creation of subscriptions based upon the occurrence of triggering events. For example, an interface to a probation case management system can create a subscription when a new case is added, so that a probation officer can be notified if his/her supervised individuals have further law enforcement contact or are re-arrested.
6. Interfaces to systems for “pushing” key events to partners that need to consume event information. For example, the OJB includes an incident reporting interface that automates submission of electronic police reports to prosecutors, and can also submit incident reports to the FBI N-DEx  Similar event-reporting interfaces exist for charge filing, dispositions, probation and parole case initiation, and booking/arrests.
7. Support for user authentication using a federated identity model that conforms to GFIPM.
8. Support for authorization (access control, policy enforcement, privacy policies) that conforms to the Global Technical Privacy Framework .
9. Coming soon (2015): The capability to populate an analytical data store with justice event information that has been “sanitized” of personally identifiable information, and can be used to produce a variety of performance measures and other statistics on the operation of the justice system

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.

The OJB also secures its federated query components with an approach that conforms to these GFIPM profiles: user-to-system and system-to-system .

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:

• The core components of the OJB are made available for download, in source and binary form, at no cost
• Licensees are allowed to modify the source code, as long as any modifications are shared back with the community via the OJBC
• Licensees are allowed to redistribute changes to the core OJB components, as long as the source code for those changes is made available under the Reciprocal Public License as well 

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.

We are still working out the details of this.  Eventually, we hope to leverage GitHub’s repository forking capability.  For now, please just contact info@ojbc.org and we will work with you to enable sharing of your modifications.

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:

• Why open source is more secure than closed source (link to http://www.datamation.com/open-source/shuttleworth-explains-why-open-source-is-more-secure-than-closed-source-video.html)
• Open source security (link to http://tldp.org/HOWTO/Secure-Programs-HOWTO/open-source-security.html)
• Six open source security myths debunked and 8 real challenges to consider (link to http://www.zdnet.com/article/six-open-source-security-myths-debunked-and-eight-real-challenges-to-consider/)

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.

OJB components have been developed on the Java platform.  Specific Java technologies (other than the core Java runtime) include:

• Velocity
• jQuery
• Apache Camel
• Apache CXF
• Open Services Gateway Initiative (OSGi)
• Apache Karaf
• Spring
• Pax Exam
• and many other open source Java projects.

There were two primary reasons for choosing the Java platform:

1. Java runs on the widest range of hardware and operating system platforms from Windows to Linux to mainframes. Because we want the OJB to be reusable in as many contexts as possible, this seemed to be a sensible choice, versus alternatives that run on only a narrower range of architectures.
2. The OJBC’s open source commitment required the choice of a platform on which a robust set of open source components and libraries were available. We could not achieve our mission to provide a low-cost platform if the use of the platform required the purchase of costly application servers or other underlying libraries.

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 info@ojbc.org.

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 intermediaries that run on the broker include, by default, loggers that write certain information to log files stored on the broker server.  This information can include data useful for audit logging purposes (e.g., what information was accessed by whom), but also can include information useful for system administration purposes.  All of it can be easily disabled, if desired.
• The subscription-notification intermediaries store subscriptions in a database—there is no way around this, as the subscriptions have to live somewhere.  Each subscription contains match criteria for subscribed events (e.g., name and data of birth, or biometric identifier, for the subject of interest), the email address of the subscriber, and start/end dates for the subscription.  This database does not need to be stored on (and ideally should not be stored on) the intermediary broker server.  And, this information is only stored if subscription-notification is enabled, and then it is only stored for subscriptions actually entered.

We offer two mailing lists—one geared to general user topics, and the second to developer/technical topics:

User Mailing List
Developer Mailing List

OJBC staff are always available to consult and assist with your plans.  Feel free to post a question to the OJB User Mailing List or Developer Mailing List or contact info@ojbc.org.

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.