How to Integrate Systems
EIS's Integration Hub takes over responsibility for several functions that are currently dispersed throughout campus systems, making the management, securing, and use of integrations easier for both providers and consumers of data. It also serves to decouple provider and consumer so that both need only worry about interacting via a stable, intermediary interface
While every system has its own internal models of data (shown here as “application data objects,” or “ADOs”), exposing those models externally has lead to a proliferation of point-to-point integrations. EIS promotes instead that integrations be built using “enterprise data objects,” or “EDOs” as the shared format. See How to Design Data for Integration for details.
API based integrations will continue to replace much of the file exchange and database views currently used on campus. To control access and manage throughput for APIs, an API management service has been implemented using 3Scale as the commercial provider and API Central as its campus web presence. This layer allows developers to browse available APIs and interact with them, authenticates systems calling a particular API, and tracks their usage. Tracking allows rate-limiting, to defend against abuse, and monitoring, to help API providers right-size their services. See Using APIs for details.
The request & response web services layer provided by Apache CXF enables exposure of both SOAP and RESTful services over HTTPS, and data binding using XML and JSON messages.
Asynchronous messaging is managed using Apache ActiveMQ. Messages can contain either textual or binary content and metadata, which provides additional information about the message and is useful for logging and monitoring. Messages can be produced and consumed using JMS clients or via specialized or generalized APIs. See Notification Services for an example of how EIS wraps messaging with an API front-end.
Routing & Integration
The routing and integration layer, based on Apache Camel, uses modular bundles to route messages and implement enterprise integration patterns such as transformation, enrichment, filtering, splitting, and aggregating (see http://www.eaipatterns.com/toc.html).
Fine-grained authorization takes the identity of the system calling an API (provided as part of API Mangement) and uses it to retrieve the system’s assigned roles and attributes of interest. These are compared to a policy that authorizes access to particular records or fields carried in the message, redacting or masking those that fail the policy. This allows APIs and the EDOs that form their payloads to be designed more generally, while still enabling data owners complete control over which of their data is exchanged with whom.