People have thought of establishing a relationship between SOA and Web 2.0 for quite some time. However, Dion Hinchcliffe notes that:
… these two cultures are generally failing to cross-pollinate like they should, despite potentially extraordinary opportunities.
From an architecture perspective, a few people have barely started to look at how the two fit. In this article Ganesh Prasad, Senior Architect in a large financial institution, Rajat Taneja and Rhys Frederick, both consultants, detail their analysis of how SOA and Web 2.0 relate, by defining SOFEA, the service-oriented front-end architecture.
In the past few months, Mashup frameworks have started to bridge the gap between the two, and new products from companies such as IBM, or WSO2 are now focused principally on associating a Web 2.0 user experience with the consumption RESTful or Web Services.
Last week, the Apache Tuscany project opened a new way to bring SOA and Web 2.0 together by facilitating the assembly of services and Web 2.0 User Interfaces.
The Syndication domain has been addressed to a certain extend by the development of Atom Publishing Protocol which exposes RESTful services to manage collections of resources. However some see limitations for a broader utilization in the enterprise.
One would argue that we are just at the onset of integrating SOA and other aspects of Web 2.0 such as collaboration (wiki, tagging, blogging), search, ads or file sharing are still far from being explored.
Optaros, a consulting company based in Boston and with offices in Europe, has actually gone further and developed a practice focused on delivering Web 2.0 + SOA solutions leveraging Open Source Software where possible.
InfoQ spoke with Optaros’ Marc Osofsky and Dave Gynn to find out more.
InfoQ: How do you see the Web 2.0 fit within the enterprise?
Dave: We call it, “Next Generation Internet”. Try to extend Web 2.0. Social aspects, read/write, Rich User interfaces, more network aware components (not just monolithic application).
It used to be that a page came from a single application. Now we see users interacting on not really a page coming from different servers. Definitely interest in kinds of the simpler services: REST interface, someone wants to interact in the future. Ajax drives you into thinking how you provide data to a page. JSON formatting.
Marc: At the delivery level, the key with Web 2.0 technologies is the ability to jointly optimize User Experience and architecture. In general the customer is not in the position to articulate its requirements fully. The technologies offer rapid prototyping, it enables the customer to react to it and come up with new ideas. It actually works so well that we have been able to create a fixed time, fixed price business model.
There is also a great synergy between Web 2.0 and SOA. We have seen other system integrators engaging on SOA only or Web 2.0 only and it takes a lot longer.
InfoQ: What has been the impact of Open Source and more generally component reuse in the enterprise?
Dave: Four years ago, the founders of Optaros identified that OSS was shifting power from the ISVs to users. This shift would change the opportunity landscape for consulting companies and required a new delivery model.
Our goal is to focus the budget of a project on what creates a real differentiator for the customer. Typically, 80% of a project can be delivery by low cost commodity components, while 20% are specific to the customer.
Open Source introduces a new reuse model. In any given company, applications are often used once. This means that, within a company, it is really difficult to create a community around some code.
At Optaros, we reuse entire solutions, SOA middleware components such as Mule, Drupal for Content Management System, and Sugar CRM.
InfoQ: Could give us some details on your approach to solution and component selection?
Dave: Today you are still looking to reuse a whole solution, not individual services. Services are still hard find, though more and more applications are providing good service interfaces. For instance, we are not yet talking about a content management service; we are still looking at implementing a content management solution.
Our methodology starts with product and component evaluation. We take an entirely new approach here; we are looking for people that trying to solve the same problem and identify what solution and components they are using, instead of evaluating a matrix of criteria.
For instance, one of our clients is a university. They hired us to help them implement a content management system, we compared their requirements to the one of other customers, this lead us towards Sakai.
Marc: In the case of Wonderbox [a retail project they completed combining store front, CRM and backend integration], we took an approach which is common to a lot of retailers. We “re-platformed” completely by using Assembly, Dynamic Scripting Languages and Web 2.0 (RIA, Ajax and Streaming). At the core we deployed a request broker, put a wrapper around their infrastructure and started to migrate their back-end services. We used all open source components: OS Commerce, Sugar CRM to manage the BOM and track usage and payments. We used Mule ESB to connect to all the services.
InfoQ: What is your experience with Open Source SOA Infrastructure Components?
Dave: In our experience, you benefit from having your middleware being vendor neutral, you get better standard support for instance. You get also less vendor dependencies: if you are wiring your infrastructure to a vendor protocol you are missing the point of SOA. Of course, you also benefit from a cost perspective as open source components are free or very low cost.
Over time, Open Source Components tend to integrate with everything, which is not always the case with a particular vendor.
The key advantage of Open Source Software is during the early stages of a project. When people are doing a proof of concept, they will use an open source component as a place holder, then at some point they might buy a product, but customers usually end up keeping the Open Source Component, this is particularly true for ESBs.
One good story of people using services to get the benefits of different parts of their application is SwissCom Hospitality, wireless providers for hotels. PhP based front-end. Develop and Modify the front-end, but they wanted their back-end services written in Java, with 3rd party services (proxy, data caching). We used Web Services to go from PhP to a Tomcat container.
Marc: Scripting languages like Symphony or Python are scaling quite effectively. We start seeing high traffic web site using these technologies. The key for us is that they enable rapid prototyping with user experience designers. We can show fully functional sites within a few weeks. SOA brokers and containers are also very mature, we don’t see many issues there. The whole SOA approach is showing enterprise class strength in our opinion.
What we see missing are more functional components. For instance the “Merchant Desktop” that would enable managing pricing and product information across store fronts. This is often a custom component. From a SaaS perspective, the one area that we see missing is the core order management checkout process. Some solutions offer this component but it is tightly coupled with the presentation layer.
In the case of WonderBox, we have designed and implemented a new platform in under 6 months. The increased speed of delivery you experience is key because, in the retail sector you get a 6 to 9 month window to change anything. Systems have to be stable for the holiday season.
InfoQ: Could you tell us about the methodology that you have developed and the tools you are using?
Dave: Out methodology brings together an Agile approach with fixed scope. You have to focus on reusing and assembling components and stay away from custom components. Very early we focus on identifying the component we can get that solves most of this problem. We are looking to minimize the amount of code that we write.
When some of our development does not constitute a unique differentiator we often try to push it back to the open source project. For instance, we were using ActiveMQ when it did not have a strong dead letter processing capability. We wrote the dead letter handling for ActiveMQ, committing these features back to the project benefited our client: when the next release came out, they didn’t have to go through a major upgrade and over time they leveraged bug fixes and performance optimization. This is truly a win-win situation for the client and the open source project.
We try to use open source tools as much as possible because of hand off to the clients.