OpenPaaS’ Newsletter — May 2018
OpenPaaS and Entreprise service buses: on the road to full-on integration
Introduction
Among its other area of expertise, LINAGORA is proud to be a software editor focused solely on developing free and open source software. This openness has many benefits, including making integration between in-house applications much easier, and ultimately allowing for the consolidation of its portfolio.
In last month’s newsletters, we covered the long-term prospect of integrating LinTO, our open source smart assistant in the making, with OpenPaaS, our beloved collaborative platform. This late-May newsletter will illustrate how another in-house software, Petals ESB — which is currently being integrated to OpenPaaS — can team-up with OpenPaaS to offer customers an even more complete experience. But first, we will shed some light on the kind of problems Entreprise service buses (ESB) software are trying to solve and where they come from.
Happy reading!
Application wilderness
Any given institution has various sets of needs when it comes to software — overlapping or not — from the organization itself to the individual worker: the finance department needs accounting-related software; the marketing department requires customer relationship management software; almost everyone needs an office suite; etc. The information technology (IT) department, which seeks stability above anything else, is nonetheless expected to quickly satisfy this internal demand, while coping with external pressures to adopt new technology (blockchain, anyone?).
As a result of this, the number of software your IT department is managing is likely to grow steadily — to the point of becoming unmanageable. Without thoughtful architectural decisions along the way, entropy, understood as the gradual decline into disorder, may ensue, driven by strong centrifugal forces.
Unsurprisingly, this particularly problematic outcome, which can be called application wilderness, is especially acute for organizations that have decades-old IT departments. Application wilderness is the coexistence within one company, business or information technology environment of a great number of isolated software, which have grown over time like weeds, with desperate need for integration.
Application wilderness is not just a made-up expression: it has real negative consequences. Among them is information siloization. When insular software are coexisting within a specific domain, the information sent to them will eventually grow to constitute compartmentalized silos. In information management, this phenomenon is called information silo, and is illustrated in the diagram below. How can we avoid this outcome?
Business-oriented computing
Ideally, within a company, an IT infrastructure and network would grow organically with the business, with little to no friction. But the actual world isn’t the best of all possible worlds. In reality, the IT and non-IT part of a company often clash, due to contrasting if not opposing interests. How can they both be reconciled? Rather than to try to change people themselves, a more promising approach is often to adjust their environment, without trying to change the way they work.
Let’s enter the way-back machine and shrink ourselves down to the level of a software in order to introduce component-based software engineering, which alongside its offspring have offered answers to help solve the so-called application wilderness problem. Or at least, that is what will be defended.
Component-based software engineering (CBSE), also known as component-based development (CBD), is an approach to software engineering born in the 80s that stresses the need to create software out of reusable and loosely coupled components. Here, components are seen as black boxes which only defines the way they will talk to other parts of a software, allowing developers to reuse them without knowing how they work internally. Alongside object-oriented programming or software quality insurance, to quote only a few, CBSE has represented one of many answer to the early 70s software crisis, a crisis triggered by the rise of available computing power and the lack of appropriate tooling to meet the then exploding demand for software. The promise behind CBSE was that by raising the level of abstraction, it would be simpler to write useful and efficient computer programs, allowing the software industry to better cope with the demand at the time.
One beneficial side-effect of this approach is that it has improved the readability of software for non-technical audiences, contributing to filling the gap between the software folks and the layman. How so? Components can be easily tied to real-world events and link to business workflows.
Take for instance the Unified Modeling Language (UML): this language was developed in the 90s and is being used to model the way interactions between components work in a software, making it easier to associate lines of code to their corresponding process. (Shameless plug: OpenPaaS has implemented UML diagramming through an additional module.)
Let’s now elevate ourselves to the level of the operating system, where component-based ideas have also largely been applied, most notably to programmatically link the user-generated contents of various software together.
In the 90s, Microsoft jumped on the CBSE train and created The Object Linking & Embedding (OLE) alongside the Component Object Model (COM), two proprietary systems infamous for being routinely abused by hackers and riddled with vulnerabilities, thanks notably to ActiveX, which made those technologies accessible from untrusted networks such as the World Wide Web. (The ActiveX page on Microsoft’s website is no longer available. Rest in Peace, ActiveX?). IBM too has its own implementation, the System Object Model, which was tightly integrated to their now defunct OS/2 operating system. Finally, JavaBeans, which regroups many Java objects into a so-called bean, is yet another example of a component-based model.
Entreprise service buses to the rescue
Let’s now rise again and go back to the level of the architecture of an information system itself. Within a company, multiple software are coexisting. In order to avoid application wilderness, they need to be integrated with each other. Entreprise application integration (EAI) is a set of tools used to link existing software together while avoiding point-to-point connection.
This approach comes with many benefits:
- Applications are treated as black boxes;
- They only have one system to talk to;
- Information will flow more easily from one application to the other.
When services are provided through an network, the expression Service-oriented architecture (SOA) is used. It is worth noting that a service, in this context, share familiar traits with containers, which are also self-contained entities treated as black-boxes by their environment. In a similar vein, the SOA model has championed the idea of microservices, one of the foundation of the DevOps movement.
So what are Entreprise service bus (ESB)? ESB are middleware that implement both SOA and EAI. They allow applications to talk to each other by translating and moving their requests, often across a network.
ESB software are intimately tied to business workflows, and are designed to break information siloization by allowing software to exchange information over a common bus. As such, they represent a good way to reduce the architecture debt of an IT ecosystem, because they take into account legacy systems by design, and therefore help long-running businesses to manage their current infrastructure.
Petals ESB meets OpenPaaS
Petals ESB, LINAGORA’s ESB and part of the OW2 community, is a Java-based platform used to mediate heterogeneous systems by exposing them as services in a common communication layer, the bus.
More concretely, Petals ESB receive as input information from applications (in the REST, SOAP or any other format it understands) and when an application requests data back Petals ESB will convert it so that the output will be compatible with what the application is requesting (for example the SOAP format).
Architecturally speaking, Petals ESB is made up a kernel called the container and of many extensions known as Petals components. These components support various standards such as SOAP, BPEL, SCA, XSLT alongside communication standards such as HTTP, Mail, FTP, and others.
Petals ESB’s main characteristics are:
- Distributivity: Petals ESB is a distributed platform, made out of many instances that are able to communicate with each other over a network.
- Guaranteed Message Delivery: a message that is sent to a service will always be delivered. If the service is off-line or unreachable, the message will be either stored, or sent to an equivalent service.
- Message Routing: the effective recipient of a message can be chosen at runtime in function of various criteria.
- Robustness: In case of an incident, the platform can restore its last-known working state and resent messages that were not processed.
- Respect of standards: Petals ESB is built around open standards.
- Monitoring: the content and the properties of the messages that transit in the bus can be monitored.
- Extensibility: with its component-based architecture, it is possible to extend, update and modify the platform dynamically.
- Tools: Petals ESB is completed by several tools, including a development environment, a web console, a governance solution, a Maven plug-in, and administration ANT scripts and many more, making it a complete suite.
Not unlike the DevOps trend, which is bridging the gap between developers and system administrators, ESB like Petals ESB brings business people and information technology specialists closer together.
What will Petals ESB brings to OpenPaaS? Petals ESB will allow legacy applications to transfer data back and forth to OpenPaaS. But not only that, depending on the context, it will also play the role of a gateway, allowing multiple instances of OpenPaaS to talk to each other. For instance, each and very municipalities could manage its own instance of OpenPaaS and decide through Petals ESB what service should be available to other instances.
Conclusion
New architectural trends and innovations such as ESB don’t just magically appear. They are built on top of decades-old concepts and mature technologies; and they try to solve real problems, such as to break information silos. Throughout this newsletter, the pre-history of ESB has been illustrated, just as the benefits they can provide to organizations. Let’s wish those technologies and trends continue to thrive.
Talking about thriving, the 7 and 8th of June 2018, the OW2 consortium, — which hosts Petals ESB among many other great open source projects like GLPI, an IT asset inventory we use at LINAGORA — will held its yearly conference in Paris. It is free as in free beers, and showcase many interesting talks. The word is out!
For next month newsletter’s, we will focus on LinShare’s history and future development. LinShare is LINAGORA’s open source file sharing application.
Keep in touch with OpenPaaS on Twitter, Facebook, GitHub.
Interested in joining Linagora? We are hiring!
