You want your system to work in harmony with campus IT—we can provide the knowledge and skills needed to do that.
Our modern integration services are re-usable, secure, and manageable. Optimally designed and implemented, APIs will be useful for evolving use-cases well into the future, message queues can seamlessly keep data in sync across numerous campus systems, and standardized data formats can ease the adoption of both.
APIs
Our current technology stack for API development is built on a foundation of Spring Boot™, Apache CXF™, and Apache Camel™.
Spring Boot is an open-source Java-based framework often used to create stand-alone micro services. The resulting APIs can be run on any JVM, but are especially suited to run within a containerization platform such as Docker, which combines API code with an operating system, libraries, and all dependencies required to run it in any physical environment.
Apache CXF is an open-source services framework that uses frontend programming APIs, JAX-WS and JAX-RS. These services can speak a variety of protocols such as RESTful HTTP, XML/HTTP, and SOAP over a variety of transports such as HTTP, JMS or JBI. It includes "HTTP binding" annotations that makes it easy to build RESTful services.
Apache Camel is an open-source message-based framework that implements widely recognized "Enterprise Integration Patterns." It allows applications and their components to communicate with each other using discrete messages as inputs and outputs—and absolutely nothing else. It defines "from-to" routes to direct the movement of messages and transformations to translate, sort, enrich, and validate them.
Message Queues
We run Berkeley's message queues on Apache ActiveMQ, the de facto standard, open-source, multi-protocol, Java-based message broker. The queues provide guaranteed asynchronous message exchange between systems, especially suited to frequent, event-based, real-time updates.
Standardized Enterprise Data
Each system has a local model for the data it uses to fulfill its functions. When that data is shared between systems, however, it should be transformed into the form of an “Enterprise Data Object” (EDO). EDOs are models designed not to fulfill the needs of any particular system, but to represent a shared notion of that information across all its campus uses. Because such notions change far less often than process or technology, EDOs serve as a stable lingua franca that all systems can understand.
EDOs are designed in close cooperation between Integrations architects and business process owners, and published in the bMeta Enterprise Metadata Repository.