Category Archives: Architecture

Everything you need to know about architecture patterns: a quick reference for Solution Architects  

The success of a solutions architect depends on the approach taken from the beginning. The role can be challenging with the need to carefully balance the organization’s business as well as technical requirements. That’s why we had a dedicated track on architecture patterns at WSO2Con Asia 2016 held earlier this year  in Colombo, Sri Lanka, to help SAs understand today’s best practices and how they can deliver value more quickly. If you missed out, here’s a recap of the patterns we discussed with the link to recordings of each talk.

Iterative Architecture: Your Path to On-Time Delivery

Agility is key for enterprises to optimize business functions, introduce new business capabilities, and explore new markets. Thus, enterprise software systems should support both evolutionary as well as revolutionary changes that will impact core business functions.

Screen Shot 2016-04-25 at 12

WSO2’s VP – Solutions Architecture, Asanka Abeysinghe, discussed the advantages of adopting an iterative approach when introducing architectural changes to support business and technical requirements. He demonstrates this with real-world examples of successful implementation of architectures in iterations. 

Breaking Down Silos with Service Oriented Architecture

Service-oriented architecture (SOA) has outrun the notion of systems silos with its use of standard protocols and specifications at integration points, which allows systems to communicate with each other in a much more flexible manner. Nadeesha Gamage, associate lead – solutions engineering at WSO2, explained the drawbacks of having a siloed architecture and how they can be avoided by moving to SOA, thereby enabling greater agility. He discussed how SOA can be broken down further to a finer-grained microservice architecture and, as a result, how an enterprise can benefit using the WSO2 suite of products. 

Event Driven Architecture: Managing Business Dynamics for Adaptive Enterprise

SOA implements a synchronous request-response model to connect remote processes in distributed system; it creates an inherent rigidity and additional dependencies when applied in modelling business processes and workflows. In contrast, event driven architecture (EDA) is based on an asynchronous message-driven communication model to propagate information throughout an enterprise, thus supporting a more natural alignment with an enterprise’s operational model and processes/workflows. In this session, Solutions Architect at WSO2, Dassana Wijesekera, analyzes key business challenges that encourage the use of EDA and discusses a pragmatic approach of designing and implementing an EDA using the WSO2 integration framework.

Moulding Your Enterprise with Resource-Oriented Architecture

An enterprise environment is typically heterogeneous, often spanning across organizational boundaries. Building such systems require tools that promote intrinsic interoperability and provide ease of integrating over boundaries. It also needs to use technology that promotes simplicity and is easy to handle. Resource-oriented architecture (ROA) supports this by focusing on entities and interactions for effective enterprise integration. Shiroshika Kulatilake, solutions architect at WSO2, explained the idea behind having a ROA in your organization, both externally and internally and also talked about how WSO2 technology can help you built your enterprise system in a resource oriented manner. 

Building Web Apps Using Web-Oriented Architecture

Web-oriented architecture (WOA) or SOA + WWW + REST  takes you several steps further by filling the blanks of SOA and helping you build an end-to-end complete web application. In addition to APIs, WOA identifies user interfaces and application states as first-class components of an architecture. Most of what we build today is actually WOA, though the abbreviation might not be that popular.

Screen Shot 2016-04-25 at 2

Lead Solutions Engineer at WSO2, Dakshitha Ratnayake, discussed the changes to WOA over the years, today’s trends, and how you can leverage WOA to build web apps. 

Reinforcing Your Enterprise With Security Architectures

WSO2’s VP – Engineering, Selvaratnam Uthaiyashankar presented an informative session on

leveraging the extensive feature set and extensible nature of the WSO2 platform to provide a robust security architecture for your enterprise. He also explained some of WSO2’s experiences with customers in building a security architecture and thereby extracting commonly used security architecture patterns.

Understanding Microservice Architecture

Today many organizations are leveraging microservice architecture (MSA), which is becoming increasingly popular because of its many potential advantages. MSA itself is divided into two areas – inner and outer architectures –  which require separate attention. Moreover, MSA requires a certain level of developer and devops experience too. Sagara Gunathunge, architect at WSO2, presented an awareness session about MSA and also discussed WSO2’s strategic initiatives in both the platform level and WSO2 MSF4J framework level. 

Deployment Patterns and Capacity Planning

Identifying the right deployment architecture is key when providing smooth operation of a production system. In the next step, it’s crucial to determine the size of the deployment by understanding the number of servers/VMs/containers necessary to support the minimum, average and possible maximum load that the system is expected to handle. Solutions Engineer at WSO, Chathura Kulasinghe, in this talk focused on how you could take a fact based approach to determine the size of your deployment. 

Pattern-Driven Enterprise Architecture: Applying Patterns in Your Architecture

It’s no secret that architectural patterns help you build beautiful enterprise architecture. High-level patterns such as SOA, ROA, EDA, MSA and WOA provide many best practices for enterprise architects who are looking to evolve their existing enterprise architecture or for those creating newer enterprise architecture strategies. Mifan Careem, director – solutions architecture at WSO2, analyzed the good, the bad and the ugly (if any) of the various architectural patterns in his talk. He discussed practical examples of the patterns in practice and also went on to build a solution architecture from scratch using WSO2 components with the help of patterns. 

Still interested in meeting the experts and discussing these topics and more? Sign up now for WSO2Con EU, which will be held in London from June 7 to 9. Be sure to grab the early bird offer before May 8.


Orchestration and Choreography – When To Use An ESB vs a Workflow Engine

Service chaining and workflows, commonly referred to as orchestrations, are common integration scenarios in enterprise systems development. There are two distinct type of orchestrations we deal with when realizing these systems:

  1. Short-running stateless orchestrations
    Service chaining messaging patterns that are more synchronous in nature and deals with transient data/sessions.
  2. Long-running stateful orchestrations
    Service chaining messaging patterns that are asynchronous in nature. These workflows take human input and approvals and are configured to run for longer durations with more persistent sessions.

If we look at these two types a bit closely the short-running ones are more straightforward; it mainly follows a request/response pattern, talks to multiple service endpoints, derives a response from one service call and composes the message to be sent to another service call. Enterprise integration patterns, such as message splitting, transformation, cloning and aggregation, are key building blocks in such orchestrations. The enterprise service bus (ESB) pattern fits this description quite well.

Screen Shot 2016-03-29 at 12

However, the long-running ones are more complex in nature and often involve human approval activities, work delegation, and assignments. A typical example for such a use case is a loan approval workflow; when a banking customer applies for a loan, the request triggers multiple services (1) credit approval service – this means connecting to multiple credit bureaus and valuing the customer’s credit worthiness, (2) evaluating the loan type (personal/home/vehicle, etc.), (3) finally, human approval (bank manager’s or loan department’s approval).

If you look closely, this particular workflow has different types of system interactions from a technical point of view. Not all interactions are long-running, yet the end-to-end scenario is so. The traditional architectural belief for such an end-to-end scenario is to model it with BPEL or BPMN (with a workflow/BPM tool), resulting in a complex model with human tasks and external links.
The common characteristic of this use case is that it is asynchronous in nature. The loan applicant will not get a response instantaneously; other parts, such as calling a credit bureau and getting the credit rating, is a synchronous stateless service call. Manager approval is a human interaction. Hence you do not have to follow the traditional path and build the entire workflow with the BPM tool. What you can follow is a hybrid model where you model the synchronous short-running stateless interactions with an ESB and long-running human interaction with a BPM tool. The proposed solution is depicted in the following architecture diagram.

Screen Shot 2016-03-29 at 12

The corresponding sequence of interactions has been illustrated in the following diagram.

Screen Shot 2016-03-29 at 12

SOA patterns and an enterprise middleware platform – a winning combination!

Service-oriented architecture (SOA) patterns provide structure and clarity, enabling architects to establish their SOA efforts across the enterprise. Moreover, these SOA patterns also help to link SOA and business requirements in an effective and efficient way.

Since service orientation has past roots in distributed computing, some of these patterns share similar attributes with distributed computing patterns and concepts. SOA design patterns also inherit concepts from other areas, such as object orientation patterns, enterprise architecture integration patterns, enterprise integration patterns, and software architecture patterns.

SOA design patterns capture the essence of past best practices, solution design principles, and general guidelines to build efficient SOA systems. Even though some of the implementation approaches of SOA keep changing (e.g. the introduction of rapid application development, the importance of devops principles in SOA and gradual movement from a top down approach to a bottom up approach etc.), these principles and design patterns make a lot of sense when building small to large, simple to complex distributed and service oriented systems.

The WSO2 Middleware Platform provides a set of loosely coupled, lean, open source capabilities that can be mixed and matched to build an end-to-end SOA solution. This platform approach means architects have the power of a range of orthogonal tools that support open standards to build their solution – the open standards based integration between the components is a strong arsenal when building solutions since architects can now bring in any preferred standard compliant component to achieve certain functionality, in line with an organization’s enterprise architecture principles.

The WSO2 team presented a series of SOA patterns, aptly categorised as the ‘SOA Patterns Webinar Series’ in 2014. Each webinar in this series covered the definition and explanation of the said pattern, along with real world use cases, solution architecture principles, and examples on how the pattern could be achieved using the WSO2 middleware platform and its suite of products. This is just the tip of the iceberg though – WSO2’s orthogonal toolset means implementation of patterns are just a download away.

SOA Pattern: File Gateway

Presented by Mifan Careem and Jason Catlin, this pattern looks at how a File Gateway pattern can be used to interact with real time and batch processing systems, by providing an intermediate file processing service between batch files and services. This webinar also looks at related patterns such as service loose coupling, data format transformation, service abstraction and technology and operational challenges in implementing this.

SOA Pattern: Policy Centralisation

Suresh Attanayake and Umesha Gunasinghe look at the importance of managing organizatinal policies centrally to overcome redundancy issues and inconsistencies and how a Policy Centralization pattern can help overcome this. This webinar looks at how the WSO2 Platform, focusing on the WSO2 Identity Server, can be used to implement such a pattern.

SOA Pattern: Legacy Wrappers

Chintana Wilamuna and Nadeesha Gamage explore the well known Legacy Wrapper pattern, as a solution to an enterprise which has large amounts of customised legacy code that cannot be easily modified nor replaced. In this webinar, they also look at common and popular tools from the WSO2 toolset for providing a legacy wrapper, including the WSO2 Enterprise Service Bus and the WSO2 Data Services Server.

SOA Pattern: Asynchronous Queuing

As business ecosystems become more critical, real time and complex, users expect inter-system messages to be processed in less than a second, regardless of the complexity and distance between ecosystems. Senaka Fernando and Lakmal Kodithuwakku look at the Asynchronous Queuing pattern as a solution to this. In this webinar, the team also focuses on the pros and cons of such a pattern as well as the implementation details using the WSO2 platform.

SOA Pattern: Event driven messaging

In a connected business context, systems need to work efficiently with each other, responding to internal and environmental changes real time. An event-driven architecture for messaging provides a solution to this by allowing the external entities to establish communication channels to the main entity as subscribers for its events. Dakshita Ratnayake and Chathura Kulasinghe look at the Event Driven Messaging pattern in detail, along with a demo of the same in this webinar.

SOA Pattern: Compensating Service Transaction

In this webinar, Nuwan Bandara and Nipun Suwandaratna look at different strategies of compensating transactions and how they can be used to recover systems to the original abstract states to guarantee system integrity. They discuss a solutions approach to achieve business integrity across stateful and stateless transactional workflows and how the WSO2 platform can be used effectively to achieve this.

Event-Driven Architecture for Online Shopping

Event-driven architecture (EDA) offers high agility and expandability to integrate with future applications while providing real-time analysis and monitoring as events occur, ensuring that today’s solutions will also meet long-term requirements.

WSO2 offers a full suite of open source components for both event-driven SOA architectures and Web services architectures to implement highly scalable reliable enterprise grade solutions. WSO2 is one of the only vendors that can deliver all components of the EDA and Web services  architectures. WSO2 is also open source and built to be enterprise grade throughout.

Another common use case of EDA is online shopping because it can vary considerably in complexity depending on the scale and ways in which goods can be sold or acquired, and the process of fulfillment. A typical example of an online retailer is presented in the diagram below.


In this architecture, consumers have a possibility to communicate through a mobile app or go to a website to purchase goods. When they use a mobile app it can talk directly to the ESB. When coming in through a Web service it will typically initiate a process in an app server.

All information goes through the ESB, so requests to search, look for more information, place orders, query the status of orders, etc. are all processed through the ESB and lead to initiation of business processes or directly querying the database and returning a result.

A business process will coordinate fulfillment, determine if there is inventory or where the inventory is, and kick off a back-order process if required, which may then trigger processes to inform the customer about delivery dates. Shipping may be notified in a warehouse to initiate a delivery.

In this architecture, we assume the suppliers have an API to interact with the selling merchant so they can inform the merchant of their delivery and to place orders. Real-time inventory must be managed in the RDB and product information constantly ingested and updated.

Activity monitoring is used to collect data on all activities throughout the system, including the customer, so that metrics and big data can be analyzed. A CEP processor is included so real-time offers can be made to customers if analytics determine it would be beneficial. RDB is used with MB to log transactions and other mission critical data.

Event-Driven Architecture and the Healthcare Industry

Insurance companies, state health care systems, and HMOs need to manage the health of customers and provide medical decisions. There are 4 parts of such a system, which is often referred to as an MMIS system. The key components of an MMIS system are as follows:

  1. Provider – enrollment, management, credentials, services enrollment
  2. Consumer – enrollment, service application, healthcare management
  3. Transactions, billing, and service approvals
  4. Patient health data, big data, health analysis, and analytics

Each of these systems are integrated and each requires its own event-driven architecture (EDA). Standards in the health industry include HL-7 for the message format and coding. Important standards to be supported in any system include HL-7, EHR standards, ICD coding standards, and numerous other changing specifications. Systems need to support strong privacy, authentication, and security to protect individuals privacy.

Let’s look at one particular type of healthcare transaction; the enrollment process for patients in an insurance service. A typical enrollment system for consumers would include at least the components depicted in Figure 1.

A typical enrollment system for consumers-01-01

Figure 1

When a patient requests to enroll in a medical insurance company or system they typically make an application in one form or another. To facilitate this numerous ways are provided for the applicant to submit the information.  As a best practice, this application uses an ESB to mediate and transform whatever application source is used. Mobile applications, for instance, can talk directly to the ESB. Once an application has been received it needs to be reliably stored and a business process initiated to process the application. Typically, the patient’s past data will have to be obtained from existing medical systems as well as history of transactions, payments, providers, etc. so that a profile can be created to determine if the application should be approved.

Over time, new information coming into the system may undermine an applicant’s eligibility to participate in a certain plan. Hence, the system has to continue to ingest data from various data sources including information on the applicants living address, medical conditions, and behaviors. A CEP engine can detect events that may trigger a business process to review an applicant’s status.

WSO2 offers a full suite of open source components for both EDA and Web services architectures to implement highly scalable and reliable enterprise grade solutions. It is typical to use both architectures in today’s enterprises. WSO2 is one of the only vendors that can deliver all components of both architectures. WSO2 is also open source and built to be enterprise grade throughout.

Figures 2 illustrates a view of WSO2’s connected health reference architecture.

WSO2’s connected health reference architecture-01

Figure 2

In the architecture described by the above diagram, health care organizations have integrated event driven capabilities. A Data Services Server helps collect raw information that can be processed by analytics tools for learning and detection of anomalous conditions. Healthcare privacy is a key requirement and the architecture above provides the security required.

The Use of Event-Driven Architecture in Trading Floors

One of the first use cases for publish/subscribe event driven computing was on a trading floor. If you consider the typical architecture of a trading floor, it comprises information sources from a variety of providers. These providers aggregate content from many sources and feed that information as a stream of subject-oriented feeds. For instance, a trader who focuses on the oil sector will subscribe to any information that’s relevant that will likely in the traders estimation have an impact on prices of oil securities. Each trader would have a different view on what affects oil securities or the type of trading they do; therefore, even though you may have 2,000 traders on your trading floor, it’s unlikely that two of them will be interested in the same set of information or how these are presented.

The Use of Event-Driven Architecture in Trading Floors-figure-01-01-01-01

Figure 1 (Source: Cisco)

Building a trading floor using EDA architecture involves building a high-performance infrastructure consisting of a number of services that must be able to sustain data rates well in excess of 1,000 transactions/second. As explained in Figures 1 and 2, ultra high reliability and transactional semantics are needed throughout. Every process is provided in a cluster or set of clusters and usually an active/active method of fault tolerance is employed. Message broker (MB) is used for trades and things related to auditable entities. Topics are used to distribute market data. Systems are monitored using an activity monitor and metrics produced. Data also needs to be reliably sent to risk analysis, which computes credit limits and other limits the firm has for trading operations in real-time. Complex event processing is used to detect anomalous events, security events, or even opportunities.

The Use of Event-Driven Architecture in Trading Floors-Figure-02

Figure 2

WSO2 offers a full suite of open source components for both event-driven EDA and Web Services architectures to implement highly scalable and reliable enterprise grade solutions. It is typical to use both architectures in today’s enterprises. WSO2 is one of the only vendors that can deliver all components of both architectures.

WSO2 is also open source and built to be enterprise grade throughout.

In a high-frequency-trading application (HFT), specialized MBs are used to minimize latency to communicate to the stock exchanges directly. A bank of computers will pull market information directly from sources and high powered computers will calculate opportunities to trade. Such trading happens in an automated way because the timing has to be at the millisecond level to take advantage of opportunities.

Other applications are for macro analysis that usually involves complex ingestion of data from sources that aren’t readily available. A lot of effort is put into data cleansing and a columnar time-series database that understands the state of things as they were known (prior to being modified by data improvements). These are called as-of data and involve having persistent all variations of data and modifications so the time-series can be recreated as was known at a certain time. Apple uses such notions in its Time Machine technology where calculations involve running historical data through algorithms to determine if the calculations will produce a profit or are reliable.

Online Taxi Service – A Typical Use Case of EDA

Event-driven architectures (EDAs) are sometimes called messaging systems. A message is simply an event or vice versa, an event becomes a message. The concept of an event-driven system is that everything that could benefit is notified of these events simultaneously and as soon as possible. Thus, the earliest real-time event driven systems came up with the notion of publish/subscribe.

An online taxi service is a typical use case of EDA; it has several applications that all talk directly to an ESB hub in the cloud or an API management service that deliver messages in real time between interested parties.

A sample online taxi service potential architecture is depicted in the figure below. case-study-Ufer-Taxis

As illustrated here, a message broker is added for queueing and creating a publish subscribe framework in the backend infrastructure. This allows a new pickup to alert several support services and tracking. There’s also an API store for external developers who want to integrate the Ufer service into their apps, making it easier to arrange pickups or drops from any location.

WSO2 offers a full suite of open source components for both event-driven SOA architectures and web services architectures to implement highly scalable reliable enterprise grade solutions. WSO2 is one of the only vendors that can deliver all components of the EDA and Web services  architectures. WSO2 is also open source and built to be enterprise grade throughout.

Pull/Push Data From Central Datacenter to Reduce Deployment Complexity

The Pattern we describe in this post will be useful to organizations that operate with a central master datacenter together with distributed applications in geographically diverse locations. We can take as examples the retail sector where an organization runs a chain of many stores, hospitality sector with many hotels and restaurants, or the healthcare sector with many hospitals and pharmacies.

Synchronizing data between the distributed agent repositories and the central master repository is a common requirement for businesses of this nature. Often the two-way synchronization must occur on at least a daily basis to keep all the systems up-to-date. Transaction data has to come from the agent data stores to the master store; master data and reconciled data has to go back to the agent data stores from the master data store.

A common approach to implement the above scenario is to run a periodic process within each agent data store, which connects with a process running in the central data store and creates a channel to transfer between data stores. This approach requires a large-scale system change, requiring systematic changes to both the central system and each agent store system. It may require coordination between agent stores to avoid overwhelming the central store.  Each store may even have to purchase new hardware and the associated costs can quickly scale upward depending on the number of connected stores. IT staff may be needed to look after each and every store to keep the system running smoothly. Costs and expertise requirements mount quickly with this architecture.

How can we reduce the deployment and management complexity and keep costs reasonable?  WSO2 has identified a solution pattern that pulls and pushes data from the main datacenter, without installing additional components and initiating periodic processes in the agent data stores.

Diagram 1

This pattern consists of a central process that schedules and connects to each agent data stores using a data connectivity technology (e.g. JDBC, ADO) and directly synchronizes the data (e.g. RDBMS) running in the store. The WSO2 middleware platform, specifically the WSO2 ESB and the WSO2 Data Services Server, provides OOTB functionality to implement the above pattern.  These products are deployed a the central datacenter location.

Diagram 2

WSO2 ESB scheduled tasks are configured to kick off the synchronization task, based on the frequency of the synchronization needed. These timer tasks invoke data services deployed in the WSO2 Data Services Server, which provide a CRUD (Create/Read/Update/Delete) service interface directly against the agent data repository. The WSO2 Data Services Server is capable of executing the SQL queries or calling a stored procedure of the agent data store as required to implement the required CRUD operations. WSO2 ESB will update the sub-system data store with data coming through the data services and will push the data back through to the master store through the same data services by reading from sub-systems. Built-in mediation features of the WSO2 ESB such as transformation and routing can be used to convert messages between different data models as well as route to relevant sub-systems, kick off additional events or processes, and so forth.

This pattern is suitable for both NRT (Near Real Time) and batch synchronization requirements, whichever is best suited for the organization that runs these type of distributed deployments.

Asanka Abeysinghe, Director of Solutions Architecture
Asanka’s blog:

Bus architecture to handle inbound and outbound calls with BPEL

Business processes play a major role in complex, long-running business processes in the modern enterprise. Such business processes might automate such business tasks as ordering and billing, customer or employee account provisioning, financial recordkeeping, auditing, and archiving, supply chain management, and many more.

Within SOA-based solutions a common technology for describing and executing business processes is BPEL (Business Process Execution Language). In an SOA environment, a business interaction with a user or a system results in a call to a Web service representing the business process. Such services may be implemented conveniently using BPEL deployed inside a BPEL engine such as the WSO2 Business Process Server (BPS.)

Since the BPEL engine exposes the process as a service, consumers can invoke the business process using the service interface and whichever of the bindings is most convenient. However, this integration pattern creates a point-to-point connection between the business process and the consumer – something that over time can result in “SOA spaghetti” and make management and evolution of the SOA platform difficult.

The pattern proposed here as a solution avoids this point-to-point connection by introducing a mediation layer using a bus architecture. An Enterprise Service Bus (ESB) presents a face to the consumers, takes the requests to execute the business processes and routes them to the business process services exposed by the BPEL engine. Changes to the system (either the consumers or the BPEL services) can be managed largely within the bus, simplifying versioning, new or alternate protocol deployment, monitoring, security configurations, logging and auditing, migration or scaling of services, etc. The result is more flexibility, greater robustness, and greater insight and manageability of the SOA.

Invoking external services becomes an essential part of BPEL logic. As a result, BPEL engines such as the WSO2 BPS need to connect to various other service endpoints within the service platform.

Commonly, BPEL activities are wired to service endpoints using direct partner links and service endpoint URLs. As a result, point-to-point integration is created between the business process layer and back-end services. These tightly-coupled P2P connections lead to complexity and limit system changes and enhancements, just the problem we were avoiding by fronting the BPEL service with an ESB!

To address this lack of loose coupling for our WSO2 BPS users, we’ve often used a pattern derived from the bus architecture. In a nutshell, this pattern introduces another (conceptually at least) instance of the WSO2 Enterprise Service Bus to mediate between the business processes and the back-end services.

Such a layered architecture looks like this:

Each BPS call that goes to the services layer, does so through the ESB. The ESB invokes the actual services, allowing it to manage all the endpoints and ensures traffic participates in the benefits of routing through the ESB. The diagram above shows two ESB layers. But, in a physical deployment, in most cases, it is deployed as a single ESB instance. Converting the above architecture to a bus architecture helps understand it better. Therefore, lets look at the same thing in a bus architecture.

The above diagram shows that all the upstream consumer channels, business process server (BPEL engine) and the services connect to the same ESB. The ESB wires each component.
This pattern provides a flexible and clean architecture to integrate consumer channels, business processes and backend services.

There are however a few drawbacks to this pattern which need to be balanced with the advantages discussed above. First, this will add a new component to the deployment architecture (the ESB) to be managed in the production environments. Second, two additional layers adding to the communication flows by introducing the ESB may add some latency (typically minimal) to a process invocation. Consider the consequences of these drawbacks when designing your architecture around this pattern.

Asanka Abeysinghe, Director of Solutions Architecture
Asanka’s blog:

Putting SOA in a Practical Context

I was looking at some of our download statistics and was pleasantly surprised to see that one of my favorite whitepapers, Practical SOA for the Solution Architect, is also on its way to becoming our most downloaded paper.  As of this writing it still trails our eBay case study, which is another of my favorites, but Practical SOA is quickly working its way up the leaderboard.

I mentioned this to Ganesh Prasad, the author of the paper, who has a long and broad experience as an architect.  Why is this paper so popular?  Here’s what Ganesh said:

“I think the paper has struck a chord because it addresses a long-felt need. Solution Architects have been bombarded with information about SOA for years, but a lot of it is theoretical and not something they can readily put to work. The SOA education provided by vendors is more practical, but it often turns out to be self-serving because it’s meant to sell products and not necessarily to make practitioners more effective at SOA. That’s borne out by the number of ESB-based solutions out there that are tightly coupled. So again, Solution Architects are left feeling a bit short-changed because they aren’t being given a practical methodology for SOA that they can apply to their work.

“Perhaps this paper, authored by a fellow architect who has been in the same situation, addresses SOA from exactly the angle that Solution Architects want to see it addressed. They finally have an answer to their longstanding demand, ‘Give me a dead simple and practical method of applying SOA principles to my solution designs.’”

I think that’s true.  SOA has gone through a pretty wild hype cycle in the past, and the straightforward application of loose-coupling principles has sometimes suffered.  But all through that hype cycle SOA was quietly proving itself as an effective approach when thoughtfully and consistently applied.

As shiny new targets emerge for industry hype-meisters (cough – CLOUD – cough) now is a good time to organize and filter the useful legacy of SOA into a practical, cohesive, methodology.  Now is a good time to recognize that SOA has established its place in modern enterprise solutions.  If you haven’t read the paper yet, I’d encourage you to download it now!

Read more of Ganesh’s thoughts and advice at his blog: The Wisdom of Ganesh.

Disclosure: WSO2 has engaged Ganesh to create educational materials and participate in events around the topics of SOA, enterprise integration, and applying WSO2 technologies.  Given the favorable reception of this first whitepaper, I’m sure many will be waiting to see more!

Jonathan Marsh, VP Business Development and Product Design
Jonathan’s blog: