Mashup, WOA, SOA, SaaS, REST and the kitchen sink

These days there is a lot of jargon thrown around and following is my attempt to make sense of put these all together in a simple terms. A could of year back some of us, the early adopter of SOA, had put together the Enterprise SOA Maturity Model (Presentation). The maturity model for IT organizations (in simple terms) consisted of three levels starting with initially developing web applications, followed by composite (aggregated) applications and finally maturing to end-to-end (automated) business processes.

It is great to observe that some in the community are very strong advocates for Web-Oriented Architecture(WOA) as a first step towards adopting SOA. This basically validated our initial assumption that business will only fund those projects that demonstrate value and providing web based solutions is the easiest way to get their buy-in. For those not familiar with WOA - you may want to read this Blog on What is WOA - The Future of Services-Oriented Architecture . What WOA does is simplify the architecture and approach - however there is still a need to ensure consistent architecture and governance across the enterprise.

The above diagram illustrated the architecture approach for WOA based sample application. To keep it simple - this sample applications integrated with Identify Management, Stock Information and a Business Process. The RESTful approach makes is simpler and easier. However, the deployment model can very quickly become pretty complex, especially with the introduction of ESB as a mediation layer. I completely agree that this is how I deployed and may still adopt the model again in the near future. However, as the number of services increases, it increases the burden on the Architects as well as IT Operations to manage not only the complexity of services dependencies, but also the complexity of multiple instances of the same services in the production environment. Coupled that with the introduction of ESB as a mediation layer and the configuration of the load balancer and firewalls between the various sub-zones in the network - this model could become unmanageable (even with an SOA Repository + CMDB) very quickly.

Alternate Approach:
Last year while working with my colleges we came across Tuple Space (an implementation of the associative memory paradigm for parallel/distributed computing) a theoretical underpinning of the Linda language developed by David Gelernter and Nicholas Carriero at Yale University. The original Linda model requires four operations that individual workers perform on the tuples and the tuplespace:

• in atomically reads and removes—consumes—a tuple from tuplespace
• rd non-destructively reads a tuplespace
• out produces a tuple, writing it into tuplespace
• eval creates new processes to evaluate tuples, writing the result into tuplespace

This simple approach of handling Tuples (Objects) in memory should enable us to integrate the enterprise using simple (limited set of) operations, similar to what the RESTful style.




The above diagram illustrated a simpler approach of integrating the enterprise (or enabling composite applications). From a business context - they always deal with an entity such as Customer, Order, User, Inventory and Product. This approach enables the IT Project teams to understand and define the business context in their language .


How does this work?
There are various different technologies and for this example - lets take JavaSpaces. Every objects has it's own unique space. The number of operations that can performed on a space are limited to Write() - Create/Update the space, Read() - Read the space without delete, take() - read and delete the space and Notify() - send an event when ever a space changes (write() or take()). Of course, they had additional commands and some vendors have provided SQL interface to these objects.

Impact to IT Operations
As organizations move to the objects (space) model - it makes it easier for IT Operations to manage multiple instances of the distributed (in-memory) data grid, eliminated the need to know and understand the services dependency matrix. This approach does not eliminate the need for ESB but does limit the need of multiple (logical) hops and reduces the number of (proxy) services that need to be maintained and managed by IT (development and operations).

Impact to BPM
Business is very much interested in knowing, preferably in real-time. the status of their business. Unfortunately, the currently BPM products can provide BAM capabilities only for those business processes that run on their instance. None of the existing products have the capacity to provide end-to-end near real-time BAM capability.

This approach enables IT to provide business monitoring and management functionality by leveraging the notify() capability of JavaSpaces.

In my opinion, in the long term the BPM vendors shall be providing the modeling and simulation capability and the Business Process Execution shall be powered by distributed (in-memory) object infrastructure.


Impact to SaaS
Today most of the SaaS Platforms (also referred to as PaaS) are object driven. The objects and their relationship not only drive the user interface but also the Business Process and Rules management. They are already one step ahead of the rest of the industry. However, most of SaaS infrastructure and platform teams spend a lot of time an effort in dealing with multi tenancy.

The Distributed object technologies provide capability to map the objects (spaces) to data sources (Databases, JCAs, WS, Files, etc.) one could potentially implement a multenant SaaS solution powered by an existing packaged application at the back end. Something that the existing SaaS companies should not ignore.

Business State Machines
As discussed previously - business deals in the context of entities (or business objects) and their decision making criteria is based on something happening (events). A combination of Event Servers and Business State Machines may be sufficient and enough to provide an end-to-end business process management (run-time).

Impact to Master Data Management (MDM)
In my opinion, MDM is a must-have solution for any enterprise that is interested in managing and monitoring their end-to-end business processes, independent of whether they adopt SOA or not. As MDM solutions deal with the most common business entities (objects) such as customers, contacts, orders and products the distribute (space) object model fits in very well. Address Standardization, Matching, reading entire customer record and performing real-time aggregation (analytics) becomes much easier to develop and manager. An approach that existing MDM vendors should look into. Most of the MDM solutions provided by vendors are easier to implement (compared to 5 years back where we had to build it all within IT), the biggest challenge with these solutions is defining and maintain the Master Data in business context.


Summary:
Even though the traditional approach scales to meet large enterprise needs, it is too complex and difficult to provide for true agility. The distributed space concept has the ability to facility business agility through plug able modules (based on event/state change notifications) and map the objects back to a source system. This not only changes the game but also takes the industry one step closer to the reality of cloud computing.

Just my thoughts and as always do feel free to drop me line with your comments and/or feedback.

- Yogish