The computing infrastructure of a company that has been running for a few years typically consists of a number of heterogeneous, loosely coupled applications that range from off-the-shelf packages to applications developed in-house. Such systems are commonly referred to as software ecosystems. The need for computing support in new business processes, and, the necessity to improve/optimise the current ones, is pushing companies to promote integration in software ecosystem. Enterprise Application Integration (EAI) solutions cope with two kinds of problems within software ecosystems, namely: keeping a number of application’s data in synchrony or creating new functionality on top of them. In either case, the EAI solution involves devising and deploying a number of so-called wrapping processes, which interact with the applications, and a number of so-called integration processes, which implement an exogenous workﬂow of messages amongst them. See an example of EAI solution here.
It is common to find the ad-hoc approach and the Point-to-Point style to design integration solutions when there is a small number of applications; however, when this number increases the most successful style is the Hub-and-Spoke [Hohpe03]. Simply put, the former style promotes the integration by directly connecting those applications which take part of an EAI solution, two-by-two, without having in mind the reuse of this solution; on the other hand, the latter provides a hub, where the business logic for the integration solution is stored (promoting the reuse), and, spokes, which are communication channels used to communicate the hub with an application wrapper and vice versa, or a hub with another hub.
A good alternative to support the design of Hub-and-Spokes are the so-called Process Support Systems (PSS): a piece of middleware which, amongst other functionalities, provides means for specifying distributed processes and for monitoring their executions [Hagen00]. Good examples of PSSs are conventional workflow systems [Aalst04] and more recently those based on BPEL [Louridas08]. Examples of PSSs that focus on EAI solutions are Microsoft BizTalk Server, Open ESB, Apache Camel, Mule ESB,Tibco Software, Apache Service Mix or Spring Integration. These technologies are intended to provide programming interfaces, frameworks and/or components to ease the design of EAI solutions. To put an example, they provide kind of wrappers which can be used to read/write on resources like files, databases, message queues, and so on. This kind of wrapper is already well-studied by the research community. My colleagues who work on wrappers are interested in wrapping web applications, since they are much more complicated and require the wrapper to emulate the interactions of a person to read/write on a web application. Working on this special kind of wrapper are other PhD students, my colleagues: Inmaculada Hernández, who researches on automatic navigation; Hassan Sleiman y Patricia Jiménez, who research on information extraction; y, Iñaki Fernández de Viana, who researches on information verification. Our complete range of research also includes the work of our colleague Carlos R. Osuna on a very important and connected field: information integration. So, if you want to have more information on these topics, please, check their web page or the IntegraWeb research project web site where we are all working :-)
My research regards to Enterprise Application Integration. In this field, according to a recent report, for each dollar spent on developing a new functionality, companies usually spend from 5 to 20 dollars to integrate it [Weiss05]. This claims for solutions that can contribute to reduce this high cost of integration. Current tools to engineer application integration solutions, like the ones introduced above, are rather low-level since they rely on programming interfaces, frameworks and components [Visser07]. Furthermore, these tools are attached to a specific implementation technology what makes more complex the process of designing the integration solution, since specific knowledge on the technology is also required.
Abstraction is the key to progress in enterprise application integration. Considering this premise, a Domain-Specific Language (DSL) called Guaraná DSL is being developed to increasing the level of abstraction at which application integration solutions are designed, which is appealing insofar this may help reduce development costs [Hermans09]. This language increases the abstraction level, not only, by abstracting from boilerplate code, but also, by allowing the design of Platform-Independent integration solutions, so that it can be automatically transformed into a specific implementation technology.
For more information, I invite you to for a glimpse at Guaraná DSL or check our publications if you are more interested in our ideas.
[Weiss05] Optimizing the value of strategic outsourcing. J. Weiss. Aligning relationships: Technical Report, IBM, 2005.
[Hohpe03] Enterprise Integration Patterns. G. Hohpe, B. Woolf. Addison-Wesley. 2003.
[Hagen00] Exception Handling in Workflow Management Systems. C. Hagen, G. Alonso. IEEE Trans. Software Eng., 26(10):943-958. 2000.
[Aalst04] Workflow Management. W. van der Aalst, K. van Hee. The MIT Press. 2004.
[Louridas08] Orchestrating Web Services with BPEL. P. Louridas. IEEE Software, 25(2):85-87, 2008.
[Visser07] WebDSL: A Case Study in Domain-Specific Language Engineering. Eelco Visser. GTTSE, 291-373. 2007
[Hermans09] Domain-Specific Languages in Practice. F. Hermans, M. Pinzger, A. van Deursen. MoDELS, 423-437. 2009.