Category Archives: Products

WSO2 Mashup Server: Where to Now?

You may have noticed the WSO2 Mashup Server link has been retired from our menus, and seen that the WSO2 Mashup Server page on wso2.com directs you to the WSO2 Application Server product page.  Curious as to what’s going on?  Here’s the whole story, from inception to the present and looking towards the future.

Where the WSO2 Mashup Server led the way

I joined WSO2 back in 2006 as Director of Architecture for Mashup Technologies to explore ways to make the emerging stack of WS-* specifications approachable and efficient for the average Web developer.  The result was the WSO2 Mashup Server, which introduced a number of valuable ideas and features:

  • Expose simple Javascript functions as full-fledged SOAP Web services, bringing Web developer skills into the enterprise.
  • Simplify access to SOAP Web services from within Javascript (mashups or browser).
  • Make dealing with XML payloads easier.
  • Interface with other systems that Web developers are interested in, particularly feeds, data sources, and other web pages.
  • Build a try-it functionality allowing developers to point at a WSDL and get a usable form-based user interface to explore a Web service (or to provide a default user interface for any service.)
  • Make the results available in forms a Web developer cares about: web pages, gadget portals, feeds, instant messages, email messages.
  • Seed an ecosystem of reusable mashups by building community features into a multi-tenant environment, where each mashup exposes services that can be reused and recombined.
  • Host a public site (mooshup.com) for the mashup community.

The resulting product, the WSO2 Mashup Server, broke new ground and gained a lot of interest in the community, proving the value of
many of these ideas.  Here’s what the 1.x version looked like back then:

image

These core features and ideas have over time influenced the WSO2 Carbon platform.  As more of these ideas have been incorporated broadly into the platform, the layer unique to the Mashup Server has become increasingly small.  Here are some ways the Mashup Server informed WSO2 Carbon platform evolution:

  • Multi-tenancy.  The early multi-tenancy (really more of multi-user than full isolation) in the Mashup Server allowed many users to register, author and share their own mashups with others, has evolved into a full multi-tenant architecture across the Carbon system, and has been a core feature cloud-enabling the WSO2 Stratos Platform-as-a-Service.
  • Social enterprise.  Enabling community features like tags, ratings, comments, granular feeds and search embedded those capacities into the underlying WSO2 Governance Registry.  They remain a key part of our governance capabilities and continue to evolve through initiatives such as the WSO2 API Manager’s API Store interface.
  • Try-it. Try-it for SOAP services has been integrated into all our products that focus on exposing services.  I personally think we have lost a bit of the “default user interface” focus over time and hope to push us back to regain and extend that aspect of developer experimentation, but an increasing preference for RESTful services which can be readily explored through simple tools like Curl is making that less urgent.
  • Gadgets.  The Google gadget dashboard and gadget generators made their first appearance as a component of the WSO2 Mashup Server, but were fairly quickly spun out into a separate product.
  • WSO2 Carbon.  It’s my view that WSO2 Mashup Server became in large part the straw that broke the back of the camel of a suite of related, but separately developed, products.  With many capabilities and shared components between WSO2 Mashup Server, WSO2 Data Services Server, WSO2 Governance Registry, WSO2 Gadget Server, coordinated development and releases across these products became untenable and helped motivate the hard but incredibly valuable work of moving towards the world’s first fully componentized middleware platform.
  • WSO2 StratosLive.  The multi-user publicly hosted WSO2 Mashup Server branded as mooshup.com site became redundant as the whole WSO2 Carbon platform emerged through WSO2 StratosLive as a solid public middleware PaaS encompassing the whole range of WSO2 products.  Mooshup.com was retired quite a while back when StratosLive came online.

What remains unique to the Mashup Server at this point is limited to the hosting of Javascript Web Services.

As our WSO2 Application Server product has expanded to encompass a platform for hosting a larger variety of web service and web application types, it makes sense to simply include Javascript services among that set.  So even though there is no longer a separate download for the WSO2 Mashup Server, the capabilities available in the final release remain present in the WSO2 Application Server.

Where the WSO2 Mashup Server missed the boat

It’s worthwhile to review some of the areas where the Mashup Server failed to reach the mainstream.  As a SOAP-centric and XML-centric model, it lost some relevancy as RESTful services and JSON have dominated the API ecosystem targeted at Web developers.  The Mashup Server’s focuses on APIs didn’t provide an easy environment for developing Web Applications – many Web Apps I built on as mashups were comprised of static HTML pages, AJAX and XML, without dynamic HTML creation and relying completely on AJAX to invoke any kind of server-side processing.  Not always the most straightfoward solution.

To address these needs, we’ve got a new approach. Jaggery is a server-side Javascript framework, that allows the Web App or mobile developer to use the same models on the client and server sides: HTML, Javascript, and JSON.  Jaggery makes it easy both to generate dynamic web pages, but also to expose RESTful services.  It brings native JSON processing to the server side and thus makes it much easier to author Web/mobile clients and services and for them to work seamlessly together.

So if you’re using the WSO2 Mashup Server, you’ll find an easy transition to the WSO2 Application Server and I’m confident you’ll find this aggregation to be a straightforward and positive move.  And we encourage you to expand your ability to leverage the advantages of Javascript server-side development with Jaggery.

Jonathan Marsh
Vice President of Business Development
blog: http://jonathanmarsh.net/blog

WSO2 Products: Summer Release Round-up

Couple of weeks ago, CTO Paul Fremantle and Tech Evangelist Chris Haddad, conducted a webinar on the innovative advancements of the WSO2 Carbon middleware and WSO2 Stratos cloud platforms. Here are some highlights from their presentation

  • WSO2 Carbon core 4.0 released with many improvement and new features
    • Enhanced Deployment Synchronizer
    • Deployment performance improvements
    • Managements and worker node separation
    • JDK 1.7 support
    • Better integration with Tomcat 7
    • Upgrading Equinox SDK (OSGI Runtime) to v3.7
    • P2 Repository: Features grouped by product
    • Multi Tenancy in Carbon
“The Carbon platform is your reconfigurable modular middleware. Recently we’ve seen lots more customers actually wanting to de-couple different parts of a product to vertically scale while at the same time horizontally scaling. This capability is proving to be a major benefit of the Carbon platform.”
– Paul Fremantle  
“We are rapidly evolving all of our products simultaneously on top of single cohesive code base. This is unparalleled in the industry to have such coordinated releases on a single platform.”
– Chris Haddad
  • WSO2 Stratos 2.0 Platform as a Service will include
    • Support for multiple languages and runtimes
    • Support for more IaaS providers (vmWare, EC2, OpenStack, CloudStack, Rackspace etc.) via Jcloud
    • Enhanced manageability
“We are embracing a heterogeneous environment were you can run PHP in the cloud environment and take advantage of the rich set of PaaS foundation services that Stratos offers. Also you can plug-in any application server or asynchronous  server and cloud-ify  the application environment by having an mechanism that ties back into the pass foundation and Startos controller services.”
– Chris Haddad
“The key differentiator for Startos is its inherent multi-tenancy. There are other PaaS offering that have the polyglot language support but what they don’t have is the concept and modeling of multi-tenancy. That plus the richness of the set of Stratos services that the cartridges have available to you make us really stand out.”
– Paul Fremantle

You can watch the full recording of the webinar here: http://wso2.org/library/webinars/2012/09/wso2-carbon-wso2-stratos-summer-release-roundup

 – Hasmin AbdulCader, Director, Communications

Re-invigorate Your SOA Initiative with Internal API Service Adoption

You’ve heard the benefits of managed APIs when enterprises extend their data, processes and services out to customers and partners via APIs. Consumer self-service, automated key management, and monetization opportunities are just a few of them.

But have your considered API management as a strategic component within your SOA initiatives?

Ten years after the rise of SOA, many enterprises have identified and published services as shared assets, however teams and partners often continue to invest considerable time and resources when building new solutions.  Many teams experience rapid portfolio proliferation and sprawl, but not enhanced portfolio efficiency or business agility.  Achieving business agility requires the growth of development partnerships and interactions, which should span both internal and external teams.

The WSO2 API Manager enables your internal development teams to extend data, processes and services across projects, departments, or divisions. Using WSO2 API Manager, your teams will be able to:

  • Establish their own API marketplace and promote APIs
  • Manage the API across lifecycle phases and enforce API Governance best practices
  • Use the API Store and OAuth 2.0 key model to self-subscribe applications, authorize subscribed applications, and provide a self-service key management and revocation environment.
  • Deploy a composable and componentized platform architecture enabling extreme scalability, flexible deployment configuration, and feature expansion.

To learn more about  internal API services adoption download the recently published white paper –  “Promoting service reuse within your enterprise and maximizing SOA success”

If you still need help to get going, consider our special APIStart package.

– Chris Haddad, WSO2 Technology Evangelist

API Management: The Missing Link for SOA Success

[This post first appeared on my blog at http://sanjiva.weerawarana.org/2012/08/api-management-missing-link-for-soa.html.]

Nearly 2 years ago I tweeted:

Well, unfortunately, I had it a bit wrong.

APIs and service do have a very direct and 1-1 relationship: an API is the interface of a service. However, what is different is that one’s about the implementation and is focused on the provider, and the other is about using the functionality and is focused on the consumer. The service of course is what matters to the provider and API is what matters to the consumer.

So its clearly more than just a new name.

Services: If you build it will they come?

One of the most common anti-patterns of SOA is the one service – one client pattern. That’s when the developer who wrote the service also wrote its only client. In that case there’s no sharing, no common data, no common authentication and no reuse of any kind. The number one reason for SOA (improving productivity by reusing functionality as services) is gone. Its simply client-server at the cost of having to use interoperable formats like XML, JSON, XML Schema, WSDL and SOAP.

There are two primary reasons for this pattern being so prevalent: first is due to a management failure whereby everyone is required to create services for whatever they do because that’s the new “blessed way”. There’s no architectural vision driving proper factoring. Instead its each person or at least each team for themselves. The resulting services are only really usable for that one scenario – so no wonder no one else uses them!

Writing services that can service many users requires careful design and thinking and willingness to invest in the common good. That’s against human intuition and something that will happen only if its properly guided and incentivized. The cost of writing common services must be paid by someone and will not happen by itself.

That’s in effect the second reason why this anti-pattern exists: the infrastructure in place for SOA does not support or encourage reuse. Even if you had a service that is reusable how do you find out how well it works? How do you know how many people are using it? Do you know what time of day they use it most? Do you know which operations of your service get hit the hardest? Next, how do others even find out you wrote a service and it may do what they need?

SOA Governance (for which WSO2 has an excellent product: WSO2 Governance Registry) is not focused on encouraging service reuse but rather on governing the creation and management of services. The SOA world has lacked a solution for making it easy to help people discover available services and to manage and monitor their consumption.

API Management

What’s an API? Its the interface to a service. Simple. In other words, if you don’t have any services, you have no APIs to expose and manage.

API Management is about managing the entire lifecycle of APIs. This involves someone who publishes the interface of a service into a store of some kind. Next it involves developers who browse the store to find APIs they care about and get access to them (typically by acquiring an access token of some sort) and then the developers using those keys to program accesses to the service via its interface.

Why is this important? In my opinion, API Management is to SOA what Amazon EC2 is to Virtualization. Of course virtualization has been around for a long time, but EC2 changed the game by making it trivially simple for someone to get a VM. It brought self service, serendipitous consumption, and elasticity to virtualization. Similarly, API Management brings self service & serendipitous consumption by allowing developers to discover, try and use services without requiring any type of “management approval”. It allows consumers to not have to worry about scaling – they just indicate the desired SLA (typically in the form of a subscription plan) and its up to the provider to make it work right.

API Management & SOA are married at the hip

If you have an SOA strategy in your organization but don’t have an API Management plan then you are doomed to failure. Notice that I didn’t even talk about externally exposing APIs- even internal service consumption should be managed through an API Management system so that everyone has clear visibility into who’s using what service and how much is used when. Its patently obvious why external exposition of services requires API Management.

Chris Haddad, WSO2’s VP of Technology Evangelism, recently wrote a superb whitepaper that discusses and explain the connection between SOA and API Management. Check out Promoting service reuse within your enterprise and maximizing SOA success and I can guarantee you will leave enlightened.

In May this year, a blog on highscalability.com talked about how “Startups Are Creating A New System Of The World For IT”. In that the author talked about open source as the foundation of this new system and SOA as the load bearing walls of the new IT landscape. I will take it to the next level and say that API Management is the roof of the new IT house.

WSO2 API Manager

We recently introduced an API Management product: WSO2 API Manager. This product comes with an application for API Providers to create and manage APIs, a store application for API Developers to discover and consume APIs and a gateway to route API traffic through. Of course all parts of the product can be scaled horizontally to deal with massive loads. The WSO2 API Manager can be deployed either for internal consumption, external consumption or both. As with any other WSO2 product, this too is 100% open source. After you read Chris’ whitepaper download this product and sit it next to your SOA infrastructure (whether its from us or not) and see what happens!

Sanjiva Weerawarana, WSO2 co-founder and CEO
Sanjiva’s blog: http://sanjiva.weerawarana.org

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/

WSO2 API Manager Beta Program Launched

Chris Haddad, Vice President of Technical Evangelism for WSO2, has introduced the new WSO2 API Management beta program in his blog.  At the end of the post he reveals that…

WSO2 has begun recruiting beta customers for the new WSO2 API Manager product scheduled to launch this summer.  Ideal candidates for the WSO2 API Manager beta program are enterprise IT professionals who are planning or evaluating infrastructure to offer APIs to third parties—whether externally or within the organization. WSO2 requests participant commitment to provide use cases and feedback. For more information please visit the product Web site at http://wso2.com/products/apimanager and contact us at mailto:bizdev@wso2.com to join the beta program.

WSO2 API Manager will enable enterprises to extend their data, processes and services out to customers, partners and other business units via APIs while providing the ability to secure, protect and monitor API resource interactions. WSO2 API Manager also will enable developers to rapidly find, subscribe to, and evaluate the APIs that enterprises make available.  Using WSO2 API Manager, enterprises will be able to:

  • Offer APIs to their customers and partners, as well as other internal users.
  • Display and promote APIs in an API store
  • Enable developers to sign up and subscribe to APIs.
  • Collect usage, performance, and quality of service metrics to analyze and understand how APIs are being used.
  • Use a policy-based approach to securing APIs, managing access, and throttling usage.

Re-invent your software delivery and re-invigorate your SOA initiative by adding WSO2 API Manager and encouraging API adoption.

Read the full post, explaining the importance of API management to SOA adoption, “WSO2 API Management Platform Re-invents Software Delivery” at http://blog.cobia.net/cobiacomm/2012/03/22/wso2-api-management-platform-re-invents-software-delivery/.

The related news release is at http://wso2.com/about/news/wso2-begins-recruiting-beta-customers-for-new-wso2-api-manager-product.

Jonathan Marsh, VP Business Development and Product Design
Jonathan’s blog: http://jonathanmarsh.net/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: http://asanka.abeysinghe.org/

Loosen Up with WS-Discovery

At the foundation of Service Oriented Architecture (SOA) lies the concept of loose coupling. Modeling a complex system as a web of interacting services each of which are independent in their implementation, hardware, environment, physical location, and qualities of service, provides many advantages for internet-scale application development. Such as: the ability for parts of the system to scale independently. The ability of each service to be implemented and operated in the best environment, based on it’s own criteria analysis be it weighted towards leveraging established legacy to adopting the latest trend or even outsourcing to the best service provider. The ability to evolve and change internally without adverse affect on the system.

In a good SOA design, a Web service is typically coupled to others over a very small surface — the actual message formats (typically a neutral standards such as XML, SOAP, WS-*), the communication protocol (such as HTTP), and the network address. The items comprising the minimal coupling details constitute the “service contract” — everything a consumer needs to know to interact successfully with the service. The service contract details are often captured in a WSDL description.

One of the key unavoidable items of coupling is the endpoint address to which the service responds. This information is often part of the WSDL — but hard wiring addresses also fixes a service to a particular address and thus limits its options for movement to a new location. If for instance a service moves from one server to another (perhaps in another data center) even though the service itself hasn’t changed all the clients have to be updated with the new address.

A common pattern for addressing the mobility of services is with proxy services, a simple-to-configure feature of the WSO2 ESB. Basically, instead of communicating directly with a service, one can route requests through a stable endpoint provided and maintained by the ESB. If a service moves to a new address, only the ESB needs to be reconfigured — all the clients send their requests to the ESB itself.

Discovery mechanisms make this even easier, allowing the ESB to automatically reconfigure itself when a service moves or comes online. Discovery mechanisms also typically can help choose among several appropriate services to send the message to.

WS-Discovery is a standard for many SOA-based systems to look-up endpoints dynamically. The standard uses multi-casting and UDP to find and notify endpoints within a local network. More information about WS-Discovery can be found in the 2004-05 specification.

Scenarios where automated discovery is valuable include: a datacenter where a cluster of well-known production services are undergoing regular creation and destruction (for elasticity or other operational reasons), a local subnet which includes mobile resources (leaving and joining the subnet frequently), or a cloud where the creation and destruction of services is automated by the cloud management system.

WS-Discovery has a well-defined scope and thus doesn’t address all the desirable scenarios of automated discovery of services. It’s designed to locate services in a local network, not across the global network. It has some ability to match services based on properties, but one must be careful that services are stable and well-defined. If for instance WS-Discovery is used to dispatch messages to a set of services, and a new service comes on board that has a different API version, is a development version, or other discrepancy, it must be clearly marked as different from the other services to prevent clients from using it in the same service pool as the production services.

The WSO2 Platform supports WS-Discovery using the following model. The WSO2 Governance Registry includes a WS-Discovery proxy which periodically both broadcasts to and listens for services that have joined the local network. Once found, they endpoint information is collected in the registry so routing systems (such as the WSO2 ESB) can use this endpoint to route messages. Services deployed using WSO2 Carbon products such as the WSO2 Application Server respond to the WS-Discovery messages to advertise their availability. Other services such as Microsoft Windows Communication Foundation also support the WS-Discovery standard and participate in the system.

Thanks to Asanka and his Smart Endpoint Registry post for planting the seed for this post, and his review and creation of the nice diagram!

Jonathan Marsh, VP Business Development and Product Design
Jonathan’s blog: http://jonathanmarsh.net/blog

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/