Carbon: OSGi and SOA
Carbon: OSGi and SOA
Join the DZone community and get the full member experience.Join For Free
The State of API Integration 2018: Get Cloud Elements’ report for the most comprehensive breakdown of the API integration industry’s past, present, and future.
Ever wonder if you could get the Enterprise Service Bus (ESB) without the 'Bus'? Did you ever need a data services server without the actual 'server'? On WSO2's middleware platform, the Carbon framework allows all of WSO2's SOA software to be striped down to core functions. The componentization of WSO2's products is possible through the OSGi specification on which Carbon is based. Paul Fremantle, the Co-Founder and Chief Technology Officer at WSO2, says, "We were one of the first middleware vendors to come out with a complete OSGi platform." In an exclusive interview, DZone found out why WSO2 decided to build its foundation on OSGi and how SOA software benefits from componentization.
WSO2 is four years old and it still maintains a business model where its SOA software is free and open source. Its business is based on providing training, support, and consultancy for the software. Paul Fremantle says many open source companies try to make money off of dual-licensing, or they provide free crippleware versions, but customers have to pay for a full-featured version. He finds these models to be "gimmicky," which is why WSO2 products are solely licensed under the Apache Software License. Fremantle says this model has lead to increases in revenue every year. Along with this business model, he says, the ability to componentize their software has been a key factor behind WSO2's success.
Fremantle explained that SOA is about making components fit together: "To me, service-oriented architecture is not just about sticking an ESB in the center of your organization. I've been involved in SOA for a long time and my perspective is that you want to push out the commonality between services and the common formats as far as possible into the organization. What that translates to when you actually get to a real customer architecture, is the common product offerings of most companies don't always fit."
About five years ago, Fremantle says, before they had names like "SOA" and "ESB", a large financial services company built a central Bus and they wanted every department to communicate through it. It was one of the earliest forms of an ESB and it was heavy and complex due to the massive amount of connections it had to facilitate. Two years later, the company came back and said that no one was using the ESB anymore. Instead, people were deliberately bypassing it. Fremantle says, "People were doing sneaky HTTP/XML calls around the edges to avoid using the central ESB." There were two reasons for this, Fremantle said. First, the funding for the ESB came from the departments based on their usage, so they were inclined to find workarounds to avoid fees. However, when the company ended that payment system, people still didn't use it. Fremantle said, "The real problem was that in order to use this system you had to set up lots of meetings with the central IT team and say what your transformations were, what your input/output messages were, and provide documentation." Then someone would have to build the transformations and the flows, and then the transformations would go through a three-month QA cycle. "There was a bureaucracy around this that was really painful," said Fremantle. "That's what SOA is trying to get away from. It's trying to get away from centralized, monolithic IT systems."
When Fremantle went to talk to this company as a representative of WSO2, they liked his company's ESB capabilities, but did not want to run them in an ESB. They instead wanted to deploy those mediations in the application servers where the services are hosted. Fremantle said that was one of the key inspirations that lead WSO2 to build an OSGi framework capable of deploying ESBs and servers as core functions.
Fremantle explained how this works with two examples. One example is the ability to apply an XSLT to the Data Services engine so a different system can talk to it without having to install a whole ESB. "You can install what is called a mediation component which uses OSGi to plug in to the data services server," said Fremantle. "When you do that you actually get the transformation capability in the data services server. You don't have to have two servers, you can have one." Another example is illustrated by WSO2's new gadget features, where you can build a user interface for a business process and co-deploy it into the Business Process Server. You could also embed ESB mediation capabilities into the Business Process Server.
In the Carbon OSGi platform "you can treat the SOA middleware like a lego box," said Fremantle. "It's kind of like Eclipse for middleware." In the same way Eclipse lets developers pull down the features they need to customize an Eclipse runtime, architects using WSO2 can plug in the services they want and customize their SOA. In fact, the Carbon framework uses p2, which is part of Eclipse's OSGi project, Equinox. Fremantle says one more reason why OSGi and SOA are a match made in heaven is that "OSGi is almost like an SOA within the JVM," said Fremantle. He says it's applying the same principles that you'd want to have on the micro level in JVM at the macro level of SOA within an application or within a runtime. Fremantle says that as a result, OSGi fits very nicely with SOA. Rather than having one big central ESB or one big server doing data services in the middle, Fremantle says, WSO2 thinks an architect building SOA should be able to put together lightweight, decentralized systems, where you can just choose what you need.
WSO2 recently announced that it is taking its OSGi based services into the cloud.
Opinions expressed by DZone contributors are their own.