Tag Archives: Integration

WSO2Con Insights – Spectrum Health Evolves Healthcare System with Custom SOA Infrastructure Solution Powered by WSO2 Carbon Middleware

As a leading not-for-profit, integrated, managed care health care organization, Spectrum Health’s subsidiaries include hospitals, treatment facilities, urgent-care facilities, as well as physician practices that serve the western Michigan area. In healthcare today, uptime is critical and there is an increasing demand for real-time results.

In his presentation at WSO2Con US 2013, Paul Tjapkes, Spectrum Health SOA architect discussed how the company is addressing these and other healthcare industry demands through its service-oriented architecture (SOA). The SOA, which takes advantage of WSO2’s open source middleware stack, has helped to merge Spectrum Health’s internal IT departments and optimize information sharing and security.

A Custom SOA Infrastructure Stack

An SOA training session served as the initial introduction to WSO2 Enterprise Service Bus, Tjapkes recalled: “We brought in because it was easy to put into a virtual machine and on users’ laptops. It worked great in training, so we ended up using it in production.”

Spectrum Health had worked with other ESB products, Tjapkes noted, but some of them required thousands of lines of code and hundreds of files just for a simple proxy to pass through. By contrast, he said that using WSO2 ESB, he and a colleague could create ten lines of configuration and a full proxy with security enabled. Since then, WSO2 ESB has become one of the company’s primary integration points.

Following its success with WSO2 ESB, Spectrum Health has implemented other WSO2 middleware products. WSO2 Governance Registry is used to communicate and manage service deployments across different environments, Tjapkes explained.

The company also uses WSO2 Business Activity Monitor (BAM), said Tjapkes, noting, “It’s important to know who’s doing what. My favorite use case is it gives us capacity planning info. We can see if a service spikes up in usage, so you potentially build out better capabilities there.”

Additionally, Spectrum Health relies on WSO2 Identity Server for its healthcare-focused XACML Policy Decision Point (PDP).

Insights for Success

In his presentation, Tjapkes also reflected on lessons that Spectrum Health learned in building its SOA infrastructure. The most important lesson was following a SOA roadmap to keep goals on track. Tjapkes explained that defining a multi-year plan, understanding the benefits and costs involved, and securing company executive support for the project are crucial for executing an effective roadmap.

“If you don’t have a plan, you’re not going to be happy with the results,” Tjapkes said. At the same time, he said, “Standards are what makes SOAs work, and it’s important to have vendors follow them as well.”

Tjapkes noted that an advantage of the open source community is that it’s founded on standards such as Simple Object Access Protocol (SOAP), Web Service Definition Language (WSDL), XML/XSD, WS-Security, Transport Layer Security (TLS), and the X.509 ITU-T standard for a public key infrastructure (PKI) and privilege management infrastructure (PMI). These technologies need to become part of the business.

Tjapkes then highlighted the importance adhering to SOA principles and having a team dedicated to supporting the SOA, explaining that it’s important for the team to organize outside of projects, so that service development doesn’t become project-driven.

Tjapkes concluded, “We’re solving problems in a different way in healthcare than we have been traditionally. Our goal is to give our patients and members a better experience. I recently met with one of the VPs, and she told me we never could’ve accomplished what we did this year without the investment we made in SOA. After doing all the heavy lifting, we can finally focus on innovation.

For more information about how Spectrum Health created its custom SOA infrastructure solution, see Tjapkes’ WSO2Con 2013 full presentation.

WSO2Con Insights – West Interactive Solves Multichannel Communications Challenge With Cloud Solution Powered by WSO2 Carbon Middleware

As the leading provider of technology-driven communication services, West Interactive has developed and managed large-scale, mission-critical transactions for clients’ communications needs for more than 25 years. However, Pranav Patel, West Interactive vice president of systems development, explained in a presentation at WSO2Con US 2013, past solutions deployed by the company weren’t flexible enough to support today’s dynamic business needs.

For West Interactive, the solution was to create West Connect, a cloud solution powered by WSO2 Carbon middleware that enables organizations to provide an improved, personalized experience for their customers.

The Multichannel Challenge

The primary business of West Interactive is to provide contact center solutions, which include cloud-based interactive voice recognition (IVR) and speech automation, mobile applications for customer care, and a hosted contact center—all based on carrier grade, scalable and reliable platform. The company now handles some 4 billion minutes of customer engagement annually.

“Today’s challenge is that there are multiple channels available,” Patel observed. “It’s no longer just a phone call or an IVR that people use to get in touch with your enterprise or customer care.  You have mobile apps, text messages, social media, email, the Web—and enterprises have to manage those and provide customer care solutions across all these channels.”

Patel then explained that, because today’s consumers demand anytime and anywhere access to data and services, across more channels of communication than ever before, it is not enough to simply provide the channels.

“These channels have to be wholly integrated,” Patel said. “The systems that provide these should be very intelligent—that’s the business challenge at hand.”

In seeking to address these business demands, West Interactive realized that the solution would rely, not on extending its existing legacy systems, but by taking advantage of a service-oriented architecture (SOA) based on modern middleware technologies.

West Connect for Modern Communications Demands

The resulting solution was West Connect, a cloud-enabled middleware platform based on a SOA, which is equipped with a set of technologies and core services that are open and flexible. It sits between the top layer of the architecture where there are applications across different channels, and the West Manage API services below, which is where the company can expose services or APIs for customers to use.

Describing West Connect, Patel noted, “The vision here is to build several services on top, as it provides for multichannel communication, multi-tenancy and services like identity management, context awareness, analytics, notifications, rules engine, and more.”

West Connect is based on several products within the cloud-enabled, fully multi-tenant and 100% open source WSO2 Carbon enterprise middleware platform. These include WSO2 Application Server, WSO2 Data Services Server, WSO2 Enterprise Service Bus (ESB), WSO2 API Manager, WSO2 Identity Server, WSO2 Governance Registry, and WSO2 Business Activity Monitor (BAM)

In describing the roles of the products, Patel explained that, “The API will need WSO2 API Manager and Identity Server for exposing the APIs out. West Connect is essentially WSO2 ESB, Governance, and BAM. A lot of the services reside on the Application Server, and when you talk to databases you use the WSO2 Data Services Server.”

The WSO2 Advantage

Patel recounted the factors behind West Interactive’s decision to work with WSO2; “We wanted something we could do a POC with, that would start out quickly and wanted a low cost of entry. The flexible, pluggable architecture made it even much better; we can choose and pick only the products we want. And a low infrastructure footprint—we can run several of these products on a VM.”

WSO2 API Manager was also a major selling point for Patel. “API Manager really gives our business the ability to go outside, not just internally, cataloging the APIs and providing the APIs with documentation as part of the API store.”

Looking ahead, West Interactive is evaluating how other WSO2 products can contribute to expanded capabilities within West Connect.

According to Patel, “We still continue to evaluate all the WSO2 products out there and we can easily see some fitting right here, business rules, complex event processing, and also how to use things like App Factory. The work continues.”

For more information about how West Interactive uses WSO2 products to power West Connect, view Patel’s WSO2Con 2013 presentation.

WSO2Con Insights – Algar Telecom Delivers Innovation Through Next-Gen Server-Side JavaScript Framework

As telecommunications continue to compete on service, they look at new ways to enrich the customer experience. For Algar Telecom, one of those ways is enabling customers to create their own Web applications using the popular JavaScript language.

At WSO2Con US 2013, Cesar William Alvarenga, front-end engineer at Algar Telecom, described how the company  is taking advantage of Jaggery, WSO2’s server-side JavaScript framework for composing Web applications.

Building on Initial Success

Before describing the company’s use of Jaggery, Alvarenga began by talking about the company’s first project using WSO2 software: Algar Telecom OCS (online charging system). OCS is used to charge customers in real-time, based on their service usage, and all mobile and fixed line traffic will run through this platform. The traffic is passed through WSO2 Enterprise Service Bus (ESB), transforming the data and integrating with legacy services.

“Today we are processing over 200,000 transactions per day and this number will increase every day,” Alvarenga said. “The performance of the ESB is agreeable and it supports our telecommunication requirements.”

Algar Telecom also uses WSO2 products to support its Coreo platform, which is used to deliver a range of applications. For example, Alvarenga noted, an application could let a user send in the airport and flight number and receive the flight information—all using SMS.

Currently Algar Telecom deploys WSO2 ESB and WSO2 Business Activity Monitor (BAM) across the Coreo platform, Alvarenga explained. WSO2 ESB is used to create an interface between all the Coreo modules and transform the data, while the company uses WSO2 BAM to collect and present all of the platform’s data. The company is now testing Jaggery to facilitate Web app development.

The Jaggery Advantage

“Web developers love JavaScript, but typically must alternate between two languages when they want to build applications on the server side,” Alvarenga said. “Using Jaggery allows our developers to work strictly with JavaScript to build Web applications across the Coreo platform.”

With Jaggery, users can generate HTML and they can exchange messages with JSON, Alvarenga observed; “Another benefit is you can reduce the number of layers in your solution. You can access directly the ESB or database for example, and this helps the developer to build a small solution, accessing directly the main services.”

Working in JavaScript using Jaggery also supports Algar Telecom’s vision of a mobile platform that inherently supports Web-native applications.

“I think the future evolution shows that the mobile platform will support these Web  applications,” Alvarenga said, “Today we have some operating systems that support only this type of application, like Ubuntu phone, HP WebOS. Tizen from Linux, and Firefox OS from Mozilla. Using Jaggery, you have a lot of functionality, so if you know JavaScript, for the server-side application, you don’t have to do much. It’s very easy.

Alvarenga wrapped up by providing a detailed explanation of how Jaggery is used with the Coreo platform—using the Jaggery template to generate HTML for the user, granting access to the user with Jaggery and an OAuth module, executing the application using the WS-Request module, and using the ActiveMQ module to get the result back to the user.

For more information about how Algar Telecom is using Jaggery and other WSO2 solutions to develop web and mobile applications, view Alvarenga’s WSO2Con 2013 presentation here.

WSO2Con Insights – How WSO2 Middleware Powers Deutsche Telekom’s Connected Car Platform

Like many telecommunications companies, Deutsche Telekom is seeking new ways to drive revenue and business growth. One of those initiatives, the “connected car” program, is being driven by the company’s T-Systems unit, which delivers information and communication technology (ICT) solutions.

As Thomas Wieger, solutions architect for T-Systems International GmbH, explained to WSO2Con US 2013 attendees, connected car is a modular, service-oriented architecture (SOA) based platform that integrates vehicles with the Internet and enterprise processes. For instance, trucks can be connected with a back-end infrastructure, or fleet management software can be used to monitor vehicle maintenance and driver efficiency. Electric vehicles, which are also growing in popularity, also require technology such as mobile applications that provide monitoring and control of energy usage.

“The great thing about connected car in the activities here is that it leverages all capabilities of Deutsche Telekom,” Wieger observed. “So we can provide connectivity, especially mobile Internet; we can provide worldwide operations in our data centers; provide platform development with T-Systems system integration; and application management with T-Systems. All these capabilities are already in place and we want to put these together to do new and exciting things.”

Seeking a Single Platform

T-Systems has several types of clients for its connected car business, and several use cases—for example, big car manufacturers want to provide mobility service to their fleets, and auto dealers want to improve customer satisfaction by remotely diagnosing car problems.

However, Wieger told attendees, “If we do everything like a solitary project, we would get a lot of different software with different components. We would be reinventing the wheel, re-developing the same component over and over again.”

Instead, Wieger explained, T-Systems recognized early on the need for a single platform to enable solution development and services across all of its customers and services, using common components as well as a modular, SOA.

Open source middleware at the core of the platform was a requirement, Wieger observed, since T-Systems was building a platform to serve millions of cars and customers and wanted to avoid the burden of licensing costs. In addition, the company wanted the ability to troubleshoot and fix solutions on its own if the vendor was not addressing the issue.

Working with WSO2

T-Systems first decided to work with WSO2 in 2011 after evaluating WSO2 Enterprise Service Bus (ESB) and choosing the software for its scalability and cost-effectiveness. Today, everything in the connected car platform is connected to WSO2 ESB, Wieger said.

“One ESB is used as a device gateway or vehicle gateway for data from the car; all that is exchanged between the embedded side and the backend side goes through the device gateway,” Wieger explained. “We are also using the ESB for integrating all services in our platform, so all end user services and platform services are using the ESB to work together, and we also use the ESB for integration of third-party content end services.”

In addition to WSO2 ESB, T-Systems also uses WSO2 Identity Server for access management—since security is a high concern for many customers, WSO2 Application Server to host services in the connected car platform, WSO2 Business Activity Monitor (BAM) for monitoring and control, and WSO2 Governance Registry.

With an eye to the future T-Systems is currently evaluating WSO2 Complex Event Processor (CEP), Wieger said; “It’s very interesting to have fast reactions on events from devices—to get continuous streams of data in the backend—so we can react on data.”

Using the WSO2 middleware with components that we have enhanced for the domain of connected car, we have an operating system for connected car solutions,” Wieger concluded. “We have the first cornerstones of our platform already in action and running, and are enhancing it continuously to implement the vision”

For more information about T-Systems development of its middleware platform, view Wieger’s WSO2Con 2013 presentation.

WSO2Con Insights – How APIs are Driving StubHub’s Business

Transforming a business to an API-centric architecture is a major undertaking, but it’s one that yields many benefits, most notably the ability to grow the business by extending processes to partners. In his keynote presentation at WSO2Con US 2013, Sastry Malladi, chief architect for StubHub, explained how the company has implemented an API-centric architecture to capitalize on this opportunity.

According to Malladi, adopting an API-centric architecture was driven by two factors. First, the company wants to expand from an online marketplace for tickets to become an end-to-destination for fans, including sharing their event experiences and getting information about things to do in event locales. Second, StubHub, which currently has a presence in three countries, plans to expand worldwide.

He observed that to achieve this goal, StubHub needed to build a developer community and enable partners to bring their content and services to the StubHub audience.

For example, Malladi noted, “If you’re at a hotel, and say you want to do something this evening to a concierge—how do we integrate those? You need to go to places where people are instead of expecting them to come to your site.”

Reusable Components Are Key to API Architecture

Before StubHub could extend APIs to partners, Malladi told attendees, the company first had to break down StubHub’s monolithic, hardwired application into shared, usable components, or services. This was necessary, he explained, because an API is an externally exposed “service,” which includes a developer program and typically has a “functional” contact as well as a “non-functional” contract, such as a service-level agreement (SLA). Moreover, the API potentially maybe orchestrated across multiple services, he said.

As part of this effort, Malladi explained, StubHub has established a domain meta model in which each domain is separate and independent and has one or more functions; each of these functions can have one or more APIs, but there is a one-to-one relationship between an API and an endpoint. Additionally, he said, the StubHub team does dependency modeling, so when someone is developing a function or API, the dependency is understood. Finally, he explained that domains are done in such a way that the entities belonging to a domain are owned by that domain, and the only way to access those entities is by going through the domain.

“Bottom line,” Malladi noted, “These APIs are giving us the business agility that we need and the operational excellence.”

API Architecture Opportunities Vs. Challenges

Malladi observed that an API-centric architecture offers several benefits for StubHub in addition to business agility:

  • Sellers have the flexibility to build their own customized solutions, and systems scale well to inventory and traffic.
  • Buyer experiences are enhanced, since it allows the developer community to extend the StubHub fan experience.
  • API brands serve to drive revenue and increase visibility.
  • Developers are encouraged to explore the APIs and see what they can accomplish with them.

However, becoming an API-centric organization presents challenges as well.

Malladi noted that while a new business could start from scratch, an established company, such as StubHub needed to balance the re-architecture with meeting other commitments to the business and customers.

A second challenge according to Malladi is that consumption patterns are not fully “baked” at the time of building an API; you won’t know fully who is going to consume them and what their patterns will be. Similarly, chargeback models and SLAs will not be clearly baked at first.

That is why it is important to build the API in such a way that it is flexible and can adapt to changes, he said. Moreover, exposing APIs to a lot of partners is not free, so architects and developers need to incorporate capacity planning and accountability into their models, he added.

At the same time, fraudsters are looking to make money off of Internet business sites. For this reason, companies need to be able to detect and prevent them from leveraging the API, and impersonating and collecting confidential data, Malladi advised.

The Role of WSO2 API Manager

For its own API architecture, StubHub is using the Store and Publisher in WSO2 API Manager, API Gateway based on WSO2 Enterprise Service Bus, and WSO2 Identity Server, Malladi said. The Publisher is where internal team members publish their APIs and manage the lifecycle of the APIs, he explained.

The Store is where an API is exposed both to the external and internal consumers, so they can create their applications. Malladi noted that the Store works the same way both internally and externally on both the website and mobile apps. He also invited attendees to visit StubHub’s implementation of the Store, the Developer Portal, at https://developer.StubHub.com.

WSO2 Identity Server manages user authentication, key management, JSON Web Token (JWT) assertion, Malladi said. Meanwhile, the WSO2 ESB-based API Gateway routes all incoming requests and works with WSO2 Identity Server to authenticate them.

Malladi noted that the combination of WSO2 API Manager and WSO2 ESB has enabled StubHub to address the need to manage APIs across Web and mobile domains. This is an important feature, since mobile is where StubHub sees the biggest growth, he explained.

Big Data Insights into APIs

To support StubHub and its expanded business model, the company is creating a big data platform to answer key questions, Malladi said. For example: How does the API manage social data and business analytics? How do StubHub APIs use these data sources, process the data, and bring it back in real time?

“It’s not just about creating an API but how it works on the backend,” Malladi observed. ““It’s so important to understand who your customer is and what they are doing.”

As Malladi then closed his session, he noted that building an API-centric architecture is a key driver for business growth, but as with any initiative there are challenges as well.

“The good news is you aren’t alone,” Malladi said. “And there are solutions.”

For more information about StubHub’s process for creating APIs, you can view Malladi’s WSO2Con US 2013 keynote address.

 

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: http://asanka.abeysinghe.org/

After Sonic ESB Pioneered, WSO2 ESB Continuously Innovated

After Sonic ESB pioneered the Enterprise Service Bus market and created technology to more readily integrate applications using Enterprise Integration Patterns, WSO2 continually added innovations to the core ESB pattern and created the highest performance, lowest footprint, fully interoperable and flexible ESB, WSO2 ESB.

Progress Software recently lowered their sights on supporting enterprise integration developers, and Progress is has publicly announced intent to sell Progress Sonic ESB, Actional services management, and FuseSource. Progress’ recent strategy shift places Sonic ESB, Sonic MQ, Actional, and FuseSource customers at risk of further obsolescence.

Where did Progress’ corporate strategy fail? By growing through ad-hoc acquisition and superficial integration instead of organic platform development. Progress played a failing game espoused by IBM, Oracle, and Software AG. Progress acquired competitive threats and then invested the minimal amount required to create a ‘SOA Suite’. As often the case, the strategy led to multiple overlapping products, competing business units, lost internal talent,
and a disjointed customer experience.

At WSO2, we have consistently taken a different approach. Our complete, composable, and cohesive platform was built through organic development, which continually enhances our core platform, incorporates market-leading innovations, and delivers a seamless customer experience. Our WSO2 Enterprise Platform enables complete data to screen enterprise integration, SOA, BPM, API management, web application development, and Cloud.

Our WSO2 ESB, WSO2 Governance Registry, WSO2 Business Activity Monitor, and WSO2 Identity Server provide a production proven, high performance SOA middleware foundation. We welcome you review our case studies and learn how WSO2 ESB processes more than 1 billion transactions per day for eBay, streamlines the development and maintenance of smart power grids, supports T24 core banking systems, and enables consolidated reporting across
enterprise applications.

Our Offer to Progress Sonic ESB and Progress FuseSource Customers

WSO2 desires to assist Progress Sonic ESB and Progress FuseSource customers choose a viable, stable, and supported middleware platform. We are offering free Evaluation Support to current Progress Sonic ESB and Progress FuseSource customers, and would be pleased to demonstrate how our market leading WSO2 Enterprise Service Bus and WSO2 SOA Platform meets your evaluation criteria. Feel free to contact us via our Progress customer offer landing page, our contact form or send us an email note.

Chris Haddad, VP Technology Evangelism Chris’s blog: http://blog.cobia.net/cobiacomm/

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: http://asanka.abeysinghe.org/

Smart Endpoint Registry Finds the Best Service for a Particular Client

Architects at WSO2 recently built a Smart Endpoint Registry solution for a large electronic media distributor. The driving force was the efficient routing of requests to the service best suited for that particular request.  To provide the lowest latency the request should be routed to the closest geographical data center.  Based on the processing requirements a particular message might be routed to a specialized service.  Or requests from premium customers can be routed to higher-capability servers.  In addition, services also move regularly between data centers for operational reasons.  The solution developed routes requests based on logic matching the message to a list of registered services using metadata such as the type of service requested, the geographical location of the service, the business group the service belongs to, the API version, and so forth.

In this solution, the service definitions and endpoint addresses are stored as resources in a centralized WSO2 Governance Registry. Properties can be associated with each service resource to indicate the geography etc.  Routing logic examines these property values to determine the address of the optimum endpoint.

The WSO2 ESB does the actual message routing, picking up message headers (such as the source IP) and comparing it with information in the registry to locate the most appropriate service and determine it’s endpoint address. With endpoint lookup complete, the message can be successfully routed to the optimum service for processing.

As services come online, each service registers itself with the WSO2 Governance Registry by writing it’s details directly to the registry during it’s initialization (in WSO2 Application Server, the “init” method).  When they go offline (the “destruct” method) they remove their entries from the Registry. There are two available APIs that can be used to create the appropriate entries and to register the service metadata as properties – a Web services API or the RESTful ATOM-based API. Setting properties is an easy and flexible way to associate structured metadata with a resource as name-value pairs.

A housekeeping task periodically checks that registered services remain online and removes service entries for those that may have gone down without proper destruction.

Composite services (in this case BPEL-based services executed in the WSO2 Business Process Server) can also route their dependent services through the ESB to find the most appropriate match – or they can look up service endpoints directly from the Governance Registry in cases where the full matching logic isn’t necessary.

The Smart Endpoint Registry scenario has similarities with other discovery mechanisms such as WS-Discovery. In both the Smart Endpoint Registry pattern and in WS-Discovery, services coming online are automatically made available to the system. But beyond the surface similarities lie significant differences. This scenario goes beyond WS-Discovery with more sophisticated property matching and searching logic to match services and clients. WS-Discovery also is appropriate for a subnet that supports multi-cast IP, providing standard “hello” and “goodbye” messages to register. But in this case the data centers are widely dispersed and a multi-cast-based discovery mechanism can’t span the network range, and so a customized init/destruct process had to be used.

The WSO2 Carbon platform is an excellent platform for implementing this pattern. The ease and flexibility of adding look-up logic in the ESB using logic control and look-up mediators, the convenient APIs for writing to the Governance Registry and structured properties on each resource, and support for init/destruct in the WSO2 Application Server all combine to offer a straightforward implementation of the solution.

Asanka Abeysinghe, Director of Solutions Architecture
Asanka’s blog: http://asanka.abeysinghe.org/

New: WSO2 Named a Leader in New ESB Analyst Report

In the latest Forrester Wave on ESBs, they declared that WSO2 was a “Leader” and scored WSO2 a 4.47 out of a possible 5.0 for “Current Offering.”

This follows two recent Gartner SOA Magic Quadrants that listed WSO2 as a Visionary. Whether or not you follow Gartner, Forrester, or more specialized analysts such as Redmonk or the 451 Group, this is a great sign for WSO2 – we are gaining not just customer traction but also visibility from the wider industry. I often think that we are one of the IT world’s best-kept secrets: a 120 person company that competes head-on with Oracle, IBM and Tibco in the middleware space; that is used by one of the world’s biggest e-tailers to do more than 800m transactions a day; that has a complete multi-tenant, elastic Platform-as-a-Service; and that does this all completely as a Modular, Open Source, and Lean codebase.

image

Focusing just on the ESB I recently heard from a customer that they have run their WSO2 ESB cluster with zero downtime for more than 2 years. What does that mean? They run a cluster for continuous availability: even during updates, the cluster remains up and active – using a graceful restart model they can push configuration updates through the system without affecting any clients or losing any messages. So despite multiple updates and even hardware changes the cluster has been live continuously for more than two years with not a single second of downtime.

Our ESB is strongly based on Apache Synapse, and generally, analysts do not evaluate Apache projects, because their clients are looking for a complete supported commercial solution. That is ok, but I think that Apache Synapse deserves a strong mention at this point. I submitted the proposal for Apache Synapse to Apache in August 2005. Some of the initial discussion around Synapse avoided the use of the word ESB – but the reality of the development from the very first line of code is that we were (and are) building an ESB. WSO2 has had a strong commitment to Synapse from day one, but there are other excellent contributors and I want to thank the whole Apache Synapse team – in my mind this rating by Forrester is not just a rating for WSO2 but for the underlying Apache Synapse ESB as well.

Here is hoping that this wider exposure helps turn WSO2 from the best kept secret to the best known alternative to bloated, costly and proprietary platforms!

Paul Fremantle, WSO2 CTO

Paul’s blog: http://pzf.fremantle.org/