The Romulus approach to Enterprise Integration Mashups
The success obtained by the mashup approach to the development of web application in the last months, with an increasing number of web sites currently available in the net, may be ascribed to its very interesting characteristics, such as the possibility for the user to define web application by composing existing data services, by using existing graphical widget, by adding some form of “logic”.
The concept of reuse, declined as use in the modern SOA approaches, helps in reducing the time for the application development, together with the concept of composition: the mashup web applications that currently are very famous in the web was “composed” by non specialized users, with a very reasonable amount of time.
The current approach of mashup help the users in creating what the community defines as “Consumer mashups”, it means mashup having the following characteristics:created to be directly consumed by the users,implemented by providing simple logic, that can be easily realized client side built on existing, well known, data services, aggregated to realize business need.
The success of the mashup in the creation of web application has suggested the possibility of using a similar approach in the enterprise context, becoming a hot topic of discussion in the community. There are different very good reasons that allow to draw the mashup near the enterprise world. First of all, the mashup may be considered a simple form of data integration, making it a very interesting topic in the area of enterprise system implementation. Secondly, the technologies used for such integration are the same used in the enterprise environment, such as Web Services or RESTful Services. Thirdly, the “compositional” approach, that is the base for the mashup, help in the reduction of development time, which is one of the biggest issues when facing enterprise application creation and integration.
On the other side, the increasing success of SOA as design model for complex applications seems to provide a great help to the mashup approach in terms of granularity of the functionalities, standardization and accessibility of resources.
Then, the ingredients for a good recipe are there, so the question is: “The mashup approach is well suited for the development of enterprise applications?”, “Which are the relationships between the mashup approach, SOA, the integration and the enterprise applications?”.
A possible response to this question comes directly from the Web 2.0 world, where the mashup and the RESTful access to resources have built their success. In this context, a new trend in the development of web applications has been formalized: the Web Oriented Architecture (WOA). The term WOA was created by Nicholas Gall, Gartner VP Distinguished Analyst, in June 2006:
“WOA is an architectural style that is a substyle of SOA based on the architecture of the WWW with the following additional constraints: globally linked, decentralized, and uniform intermediary processing of application state via self-describing messages."
A deeper analysis points out many reasons to consider the WOA approach inadequate in the enterprise environment: Enterprise environments are heterogeneous, because the applications represent a support to the business, so once developed, they are not replaced simply because the technologies they are built on change or improve.
The services that represents the actual business for the enterprise have some critical non functional requirements, such as security, reliability, accountability. WOA provides no support for these requirements, so it's simply unusable at the current state of the art.
Therefore, the WOA approach as is cannot be considered as an adequate solution for the development of enterprise applications, but the basic ideas are still interesting and applicable. It will be important to clearly define the context, the objective and the scope of the usage of Enterprise Service Mashups in order to fully understand the approach followed in Romulus.
One of the goal of Romulus is to reduce the development time for any kind of application that has a web interface, included the applications with an enterprise background, it means having complex behaviours and services provided by heterogeneous environments.
The mashup approach based on service composition may be very helpful to reduce development time, but, as in the Roma approach, some assumption will be made in order to provide an acceptable set of functionalities that will help the user without increasing the overall complexity.
The first assumption is the usage of an architectural component to provide service heterogeneity, a fundamental characteristic for enabling mashup: this component is an Enterprise Service Bus (ESB) JBI compliant.
A second assumption is that the services that can be mashed-up are made available to developers in a Service Registry Repository: the service contract (the WSDL) and their (textual) descriptions can be accessed by the developer in order to be used for mashup.
A third assumption is the usage of a declarative process language for the definition of mashup: a declarative language is less expressive than an imperative or procedural language, so depending on the type of composition the resulting mashup may be created or not. Anyway, according to the simplicity that made the success of the mashup approach, an enterprise service mashup that cannot be expressed by using a declarative language is maybe too complex to be defined mashup, but can be considered a real business process.
Enterprise Service mashup
An enterprise service mashup, also referred to as a business mashup, is a business process that combines data from multiple internal and public sources and publishes the results to enterprise portals, application development tools, or as a service in an SOA environment. Enterprise mashups must also interoperate with enterprise application technologies for security, governance, monitoring, and availability.
In essence, in the context of a service the information is made available following the principles of service orientation, like standardized contracts or separation among interface and implementation. The services are a crucial element of each business process and must be available in a correct and consistent form across the entire enterprise system.
The definition of enterprise service mashup requires the possibility of composing complex services adding sequencing and conditional behaviours. Sequence of execution and branching in case of failures and other events are critical for business transactions. This kind of expressiveness in the process definition can be achieved with the standard WS-BPEL, which allows the portability of processes using an abstract definition of exposed and consumed endpoints.
Following the SOA best practice of using standards instead of custom solutions, the enterprise service mashups in Romulus will be created by using the BPEL language, taking into account also that many ESB JBI compliant come complete with BPEL engines components.
The Romulus EI Mashup architecture
The picture above shows the basic architecture of the Enterprise Integration Mashup approach.
The services available for mashup are:
The ones exposed directly using the Roma framework Service Aspect
The ones exposed on the ESB, created annotating a POJO with Roma framework, or creating a BPEL, or by using one of the JBI binding components available for integration (a sort of adapters)
The ones available and accessible on the network.
In order to mashup services, the approach is based on an extended BPEL editor that, in addition to the usual functionalities, such as the creation and debugging of BPEL processes, the creation, building and deploying of “Composite Applications”, will help the developer in finding and managing services throughout a palette (WSDL Navigator).
As part of the Romulus approach to Enterprise Integration Mashup, a set of “general” services have been developed and are provided to the users for mashing up. Currently, the services released are:
Logging Services: provide facilities for using a centralized logging service as part of the Integration Mashup Service
Accounting Services: provide facilities for accounting the usage of the services involved in the mashup and the mashup service itself.
A Roma web application will provide a console that helps the user on managing the logging and accounting “general” services, allowing the user registration, the setting of different provisions, the logging levels.
Dependencies and requirements
The described approach is completely general in its definition. Anyway, the current version is based on the following open source components and tools:
Roma Enterprise Module: a Roma module that allows the exposition of web services defined in Roma over the ESB. The service is exposed by annotating the service implementation class, following the Roma approach, and the module realizes everything is needed for creating the composite application to be deployed in the ESB.
Roma Registry Module: a Roma module that allows the registration of web services created with Roma on the target Service Registry Repository (WSO2). The web service is annotated by the developer, and the module will perform the registration when the service is deployed in a web container.
WSDL Navigator: a NetBeans module that enriches the NetBeans BPEL editor with the Service Registry Repository Palette. This palette shows the content of the service registry, the WSDL that have been registered and their description, in order to support the developers during the mashup definition.
General Services for Mashup: a set of services that provide to the EI mashups logging and accounting capabilities.
ESB4Romulus
Blogs