Step1 : Integrating Services with the WSO2 platform

This is a follow-up to the platform overview post about the overall WSO2 platform and its capabilities. In this post, we focus on Integration. The diagram below depicts the various integration components and their relationship.


Accessing Data: should your enterprise be small or large, you have data to manage. Data can be stored in many different places: spreadsheets, CSV files, relational databases, NoSQL databases. Traditionally, applications have been using JDBC and standard APIs to access the data, and there is nothing wrong technically doing that. However, this poses few management problems:

  1. Code accessing the data (SQL queries for example) is spread across many apps, and any change to the data implies a change in all the apps.
  2. There is no way to centrally scale/optimize the access to data.

From an architecture point of view, the recommendation is to create a data access layer, which encapsulates all the data access (creating DAO and DTOs  which abstracts the underlying database and data model). The Data Services Server allows you to do just that, but also provides:

  • A user-friendly interface to build services from data. Those services can be SOAP-based or REST-based, return XML or JSON. You can provision a service in minutes if you choose to generate the services straight from the data model
  • Support for data security: you can assign a role to a certain data column: for example, hiding sensitive information from the Employees database for non-HR people.
  • Support for nested queries, that is the ability to use the result of one query as input to another one.
  • And of course, the usual transactional support you would expect connecting to a database.

Managing Services: now that we have services, either existing ones or created with DSS, we need to proxy/virtualize them to decouple the consumer layer from the producer layer. You may not see this as useful at first, especially is all you do is just proxy the service and nothing more, but experience proves that this decoupling will become useful as your architecture evolves and applications start requiring enriching, transforming or composing services. Back-end services can stay as-is, while the mediation layer does the ground work and makes that totally transparent to the consumer. You may also be worried about latency, which is why you need to evaluate ESB products carefully, to ensure they will scale while keeping transactions duration in a range that is satisfactory for your business.

Adapters are one of the key requirements for an ESB. As the central backbone to connect to anything, for traditional ERP such as SAP to popular cloud offerings such as SalesForce or Concur, ESB needs to be able to talk to all . We have launched a major effort end of last year to build dozens of adapters, and we are publishing them on your WSO2 Store, build on our Enterprise Store product.

Our ESB is one of the most mature products WSO2 has, and our customers have chosen it for :

  • Being configuration-driven as opposed to coding
  • Its extensibility (connectors, transports, business logic)
  • Its performance
  • Its scalability

Messaging-based integration: if you need to integrate in an asynchronous manner with another application, inbound or outbound, you need a message broker system. A message broker provides support for point-to-point and publish-subscribe integration, messages persistence and supports standard protocols such as JMS, AMQP or MQTT. You can plug any messaging systems into our ESB, as long as it supports those standards. WSO2 Message Broker is based on the Apache QPid project and offers unique distributed architecture.

Business Process management: the mediation layer must not contain business logic or state. They act on the message format and contents, but do not “understand it” at the business level. Nor will an ESB remember anything about what happened if the system crashes for example. Moreover, ESB transactions are measured in milliseconds, not hours or days. If you need to model complex interactions between services, that processes are long-running and you need to keep state, you are entering Business Process Management (BPM) territory. A BPM layer uses the services exposed by the mediation layer and as such, “sits on top” of it. In many processes, a human needs to be involved, through the use of Human Tasks.

In summary, using our Integration products, you can :

  • Expose any data source as a service
  • Proxy any service
  • Compose, transform, enrich services at the mediation layer
  • Orchestrate services in long running processes, including human intervention
  • Relay messages across applications in a reliable and scalable way.