Enterprise service bus | GreenVulcano 4 is a lightweight and powerful open source ESB

GreenVulcano 4, the latest evolution of our enterprise service bus designed to go beyond the traditional approach on SOA architecture by innovatively interpreting the (EAI ) enterprise application integration to meet today's requirements for high flexibility but with the robustness and reliability of the systems traditional.

1. Speed, in all phases of the life cycle, from development to provisioning up to operations, to respond in the best possible way to the changing needs of the market;
2. Economics, limiting infrastructure costs, thanks to the possibility of being used both on the on-demand cloud and on commodity hardware, thus also reducing the considerable software license costs;
3. Flexibility, modularity and polymorphism, which guarantee the ability to cover needs that are not yet born and we can not foresee, changing its own structure without design from scratch.

Enterprise service bus | what's this

Intrinsically, the enterprise service bus is a mechanism in which a bidirectional interface from connected systems is always provided. This means that all source and destination systems must be connected to the ESB and that the applications themselves communicate by sending messages on the bus.

An enterprise service bus is, therefore, a bus on which messages between integrated entities travel.

However, one should not think of the BUS as a mere intermediary structure, since it is possible to modify the messages by intervening in the logic of the software.

ESB GreenVulcano: a use case

To better understand the strength of an ESB, let's analyze its implementation.

Suppose we have a business model according to which, a series of stores that operate on behalf of the shop, are periodically supplied from a single warehouse, all respecting the following logic:

1. When the goods arrive at each store, the ERP system must be updated
2. The cashier who sells the single item of clothing sends information to the ERP system via the App. The status of the garment is updated to "sold".
3. The cashier or Sales manager sends via the App the eventual return of the garment that a customer has returned to him, for the issue of a Credit Note
4. A night batch issues an invoice for each store on daily sales
5. The payment system sends the request for SDD (Sepa Direct Debit) to Banca Sella. Invoice in "paid" status. Once the payment has been received by the Bank, the invoice is set as "paid".

As you can see there are several systems and components that cooperate with each other in a reality that we can define as integration platform: the ERP system, the web services displayed by the bank, the application that updates the ERP system for each sale of a garment, the insertion of data that takes place through the NFC reading of the various items, can in fact use protocols and different programming languages.

The enterprise service bus connects the various applications with which it interfaces.

If every service were to have a communication interface for every other service, how many interfaces should we create?

Here, therefore, that each system should have a single interface to the ESB, as can be seen in the figure below.

Scalability of an ESB

Imagine the example illustrated above, in a context without ESB: if each component must be able to interact with all the other components, no more than 16 interfaces would be needed, but 56!

Any change to a component could result in the modification of all the interfaces of those components with which it interacts: you can imagine the time that each update needs.

The use of an ESB is therefore the winning choice, as we can well understand how such an architecture can be scaled in terms of components, allowing a very large number.

Enterprise service bus architecture

The SOA (service-oriented architecture) used by Greenvulcano, as the acronym suggests itself, is a service-based architecture: in fact, we have the requests for services, and on another level, we have the actual services called up and connected by means of a BUS. The OSGI specifications implemented in Greenvulcano therefore allow the development of a component platform. These components or applications, available as bundles for distribution, can be installed, started, stopped, updated and uninstalled remotely without requiring the restart of the ESB that is deployed on the Karaf container.

The services or components within Greenvulcano, can be either strongly decoupled, think about the case in which a feature can be associated with a single service, or we can have a workflow of services (that is, multiple services performed sequentially). The enterprise service bus integrates and orchestrates all this.

Enterprise service bus | characteristics

The main features of Greenvulcano will be described below

• Running on the Karaf container for greater lightness: this also allows you to load new configurations and hot features without having to reload and deploy the application in full.
• Integration between different applications with different technologies such as JMS, Web Services, JDBC, HTTP and more
• A visual development environment (developer studio): this allows you to develop some services in a simple and intuitive way or a workflow of several concatenated services. See our tutorial and find out how easy it is to create an event-driven push notification.
• A monitoring dashboard that allows you to deploy services
• High reliability, security and scalability
• Use of Java 8 and OSGI 6.