Category Archives: Products

How Much Should You Care?

A couple of weeks ago, I recorded a podcast with Paul O’Connor and Dana Gardner. Paul O is someone I’ve worked with on and off for about four years now, first as he helped customers navigate SOA and now as he leads their thinking in Cloud. It was immense fun recording the podcast with Paul, but, if anything, we only scratched the surface of Paul’s thinking. He is one of the real visionaries of how Cloud is going to affect large businesses IT and completely rewire it.

Paul O believes that the end-game of true cloud computing is the ability for a business to completely focus on the business and have the IT from infrastructure to development completely available as a Service. Paul calls this the Grand Unified Theory of Cloud: consuming IT entirely as a service.

I personally don’t agree: I think that there needs to be a sliding line that divides IT from the pieces I have to care about to the pieces I don’t. Twenty years ago I cared about processor instruction sets and assembly code. Today I don’t. Today, I don’t care what actual hardware my Amazon images run under — there is a rough measure and the details don’t bother me. On the other hand, if I was doing algorithmic trading, I care even about the clock frequency I can rack the machine up to. I don’t believe that we will ever get to a line where the business doesn’t care about any of the details — that simply opens up an opportunity for another business to find competitive advantage by finding something to care about. But I do agree with Paul: at the moment we are forced to care about too many aspects.

Here at WSO2 we are trying to create a platform where you can stop caring about 99% of the middleware issues and we can provide a platform that just takes care of that for you. The real Grand Unified Theory of Cloud for me is being able to choose exactly what to care and focus on in your IT, and have the other parts just work — as a service.

Paul Fremantle, WSO2 CTO

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

Defining a Generic API

With a premium placed on loose coupling, a typical SOA deployment displays a high degree of heterogeneity. Different service platforms run in scattered datacenters on a variety of server hardware, operating systems, and development platforms. The services expose different communication and security standards. Individual SOA implementation and maintenance teams will become acclimated to the level of heterogeneity with exposure to the environment, but when an external or internal consumer tries to access the SOA, they will come face to face with this complexity.

A common way to simplify and normalize interactions with a heterogeneous environment is to provide a unified API for service consumers — a unified, generic service layer.

One of our commercial bank customers with multiple service platforms began a project of defining a unified services layer, generalizing the multiple service platforms active in the bank. At first, they approached the problem in the traditional way: writing wrapper/proxy services in front of each of the existing services.  As part of an engagement with WSO2 they changed to a “Generic API” solution pattern which dramatically simplified the project by hiding the internal complexity of each service behind a user-friendly API, a common URL for service access, and unified security policies.

The “Generic API” pattern installs a common API for the existing service infrastructure, converts traditional applications to services exposed over a normalized set of communication and security protocols, and provides a foundation supporting the easy addition of future service platforms.

When implemented with WSO2 products, the Generic API pattern leverages the WSO2 Enterprise Service Bus (ESB) and WSO2 Governance Registry. The WSO2 ESB connects with the back-end service layers and legacy applications, and exposes them through a new service layer.  This is easily accomplished with the proxy service capability of the WSO2 ESB.  Supporting a wide variety of the transports and message formats, the WSO2 ESB provides a central hub for protocol switching and security mediation between the heterogeneous systems.

With sophisticated transformation capabilities, the WSO2 ESB extends the Generic API pattern to the problem of unifying data models, by converting or mapping messages representing different data models into a common and easily consumed model.

Storing and publishing common metadata such as service descriptions and policies describing the generic API also aids new developers interacting with the system.  In the deployment above, the WSO2 Governance Registry provides a common repository for storing and sharing all the necessary SOA artifacts.

The Generic API pattern provides the foundation for other other solution patterns as well. In future posts we’ll discuss solution architectures for a Public Services Gateway and an Internal Services Gateway pattern.

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

WSO2 in Banking and Finance

We have had a number of recent engagements using the WSO2 Carbon platform in the banking and finance industries, and I thought it would be useful to talk about some of them and highlight the ways in which we are working with financial institutions.

Our platform has currently been used by a number of financial institutions, in both retail and wholesale banking. For example, one financial institution uses our ESB in Asset Management, several others use us for FIX support in various areas (e.g. Bond Trading, FX Trading) and meanwhile we have several retail banks that are using a variety of components from Carbon for full SOA enablement including Governance, ESB, distributed Identity Management and Data Services – for example two institutions in the mortgage and lending space.

image

The deployments include several in the US (both East and West Coast), Switzerland, Germany, Mexico and Ukraine.

One of the factors here is the strong uptake of SOA in the Banking and Finance sector and the unique position WSO2 has as a leading Open Source SOA Platform provider. Another key factor is the fact we are pretty much the only ESB that comes with out-of-the-box support for FIX (with no additional cost either). But I also like to think that one of the success factors is simply success: we are very good at helping our customers succeed in their endeavors.

If you want further information, we published a nice case study this week.  Or come along to http://wso2.com/contact/ and one of our Account Managers will help kick off the discussion.

Paul Fremantle, WSO2 CTO
Paul’s blog: http://pzf.fremantle.org/

WSO2 Message Broker Beta Leaked by CTO

Ok, not a completely truthful headline.  As an open source company with a completely open development model, the source code has been hosted publicly for some time and the roadmap for it has been discussed on our public architecture mailing list.  How can you leak something that’s already public?

But the real story is still interesting: WSO2 CTO Paul Fremantle has posted a blog entry helping early adopters download, install, and configure the soon-to-be-released product.

The WSO2 Message Broker marries Apache QPid with the Carbon OSGi architecture for JMS (Java Message Service) support and AMQP protocol support.  It is designed to help SOA adopters and those building on the WSO2 Carbon/Stratos platform to easily add messaging patterns to their toolkit of best practices for enterprise integration.

Look forward to more announcements soon, or follow Paul’s directions for your early adopter investigation!

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

What We Mean by “No Gimmicks” Open Source Licensing

At our regular WSO2 Workshop series, I’ve noticed special interest in a slide I developed for the wrap-up presentation.  The slide is titled “Open-Source Licensing” and clarifies some of the differences between licensing models and why we think customers are wise to choose the Apache License (or similar) for their software deployments.  We believe this so strongly, we’ve built our business on it!

Here’s the diagram from the slide:

image

We believe the Apache License is superior for enterprise customers to the other models listed above.  Here’s why:

Public domain

Public domain software is completely free and has no encumbrances in terms of copyright or use, but it also lacks two important qualities.

First, there isn’t a clear trustworthy owner motivated to keep the software going.  In fact, experience has shown that “it takes a village,” and a vibrant open source community is essential to the long-term health of any software technology.  Open source licenses encourage such vital communities.

Secondly, just because software is in the public domain does not mean it doesn’t violate anyone’s patents.  There are no guarantees from anyone that the use or resale of the software won’t incur liability.

Apache License

The Apache License is “permissive.”  That is, it allows you not only to use the software, or to resell the software, but also to modify it and sell those modifications as you wish.  It’s not uncommon that software customers with innovative ideas evolve into software vendors.  The Apache license keeps your future options as wide open as does the public domain.

But in addition, the Apache 2.0 license grants some level of patent protection.  When you contribute code to an Apache-licensed project you also grant a license to any patents you hold that are necessarily infringed by your contribution.  Thus as a user you have some assurance that the creators won’t come after you.  When the creators represent a broad community, that assurance gets even stronger.  The strong Apache Software Foundation brand itself acts further as an informal deterrent to patent claims.  It’s not 100% protection but better than nothing (public domain) and roughly equivalent to GPL 3’s protection provisions.

The Apache license also tracks the provenance of the code, important in establishing it’s trustworthiness, through required attribution notices.  Just as in art, provenance of code establishes trust and value.

GPL

The other popular open source license is the GPL.  The GPL is what’s called a “copyleft” license.  It is designed primarily to protect the rights of the software developer, not the end user.  (Gee, isn’t that the goal of a proprietary license?)  GPL ensures the software is free, but includes the provision that derivatives must also remain free.  That limits your options to change direction and profit from your innovations in the future.  GPL instead ensures that the original developer, in return for contributing his code, can benefit from your improvements.  But let’s face it, that altruistic attitude won’t survive most enterprise legal review.  Especially in the face of fears that GPL, like Midas, turns everything it touches free.

Dual License

Because GPL’s copyleft provisions can be scary, many GPL-based open source companies have evolved a profitable workaround.  In many cases you can acquire GPL software under a separate commercial license.  That alternative license removes the viral copyleft feature, and replaces it with normal commercial restrictions – including license fees.

For many enterprises, this negates the advantages of open source software in the first place – avoiding lock-in to a specific vendor, having no control over pricing, and so forth.  What originally appeared as a free open source license has become in effect a paid proprietary license.  We classify that bait-and-switch as a gimmick.

It annoys us even more that many companies offer some products as open source (the “community edition”) and then reserve the real product (the “enterprise edition”) completely under a commercial license.  For serious users that’s not free software – just a free taste.  Often turning your proof of concept into a production deployment involves installing new software instead of flipping a switch – what a drag!

No Gimmicks

So when WSO2 claims we have a “no gimmicks” approach here’s the commitment we make:

  1. Our software line is available completely under the Apache license.
  2. There are no “community”, “light”, or “demo” versions – every edition is enterprise ready from day one.  Even our WSO2 Stratos cloud platform is Apache-licensed – the obvious high-value candidate for a dual-licensed model.
  3. We welcome you to join the community, ask questions on our forum, even become a committer.  If you don’t want or need a commercial support relationship with WSO2, we are still happy you are using our technology.  Just please tell your friends!
  4. We have to work consistently for your business, not lock you in.  Our success and business model is based entirely on providing the highest quality support services and doing everything we can to ensure your project is successful.
  5. Our support includes creation of patches for your deployed version of the product – so you don’t have to upgrade to the latest version to get a critical fix.  While these patches are created specifically for you under the terms of our Production Support agreement and are not redistributable, you are free to continue to keep them installed should you discontinue Production Support services.

Comments or questions?  I’d love to hear your thoughts on the matter.

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

Twice the Capabilities, Half the Name

Not every Web Application has a corresponding Web API, and not every Web Service has a corresponding Web interface, but we’re seeing steady growth among customers who are building Web Applications and their APIs together.  These APIs are invaluable for leveraging advanced users and integrating with partners, but also are driven by a demand for rich applications such as native iPhone, iPad, and Android applications.

In response to this growing demand, we’ve added an exciting new feature to the WSO2 Carbon family: full support for Apache Tomcat, the leading open source servlet container. We’ve added this feature to the WSO2 Web Services Application Server — our Apache Axis2-based platform for hosting Web Services and APIs.

image_thumb[4]

As demand grows for Web APIs side by side with Web sites, a unified server provides a powerful and convenient way to provision and host both capabilities on a single server runtime, manage them through a unified console, with a single set of administrator privileges.  This unified approach offers double the benefits but at much less than double the complexity — all the benefits of the WSO2 Carbon framework, and all the skills you have in managing them, can now be applied to Web Applications.  Even multi-tenancy for deployment in the cloud — more on that in a subsequent post!

What better way to celebrate the lean nature of the product than with a new, leaner name!

With version 4.0, the WSO2 Web Services Application Server, now no longer limited to just Web Services, is now called simply the WSO2 Application Server.  Download it today or try it out as a service at https://appserver.cloud.wso2.com!

Afkham Azeez, Senior Architect and Senior Manager

Azeez’s blog: http://blog.afkham.org/

Public Services Gateway and Internal Services Gateway Patterns

I wrote earlier about defining a Generic API in your SOA by encapsulating the heterogeneous service platforms that you find in your infrastructure. The two patterns I’ll discuss today are sub-patterns that we can refine from the features provided by the Generic API pattern.

The Internal Services Gateway (ISG) pattern exposes services in the underlying service platforms to internal service consumers by using the Generic API pattern. The WSO2 Enterprise Service Bus (ESB) is deployed in the local area network (LAN) and exposes backend services as proxy services. This aggregates the backend services into a unified services layer and simplifies the backend service contracts.

Security policies for authentication and authorization can be designed appropriately for the context that only internal consumers will be allowed access to the services. Some ISG deployments only consider network level security provided by the infrastructure, others leverage Single Sign-On (SSO) through an internal user store hosted by Active Directory, LDAP, and RDBMS, or Windows-based Kerberos tokens.

The Public Services Gateway (PSG) pattern exposes select services to external service consumers. In a normal infrastructure this is achieved by deploying a WSO2 ESB in a “DMZ” (demilitarized zone where security is carefully managed – I’ll provide more information about DMZ practices in a future post) and exposing the services to external service consumers. The DMZ ESB pre-processes service requests coming from the public service gateway, and thus originating outside the core network, and routes only valid and authorized messages to the actual service platforms deployed in the LAN.

Pre-processing steps typically consist of message validation, filtering, and transformation. Compared with the ISG, a PSG should maintain a higher level of security due of course to the origin of service requests coming from outside. The PSG should be configured to use the relevant security policies and bridge into the internal security policies by using the security protocol switching capabilities of WSO2 ESB. SSO support for external consumers can be implemented using SAML2 tokens or any other Secure Token format (such as OpenID).

Two implementation models are popular: a PSG consuming services through an ISG or a PSG directly consuming the backend services. In addition to message-level validation the PSG can extend validation to the attachments coming with the message, for example executing virus checks by configuring WSO2 ESB to execute a virus check program.

In summary these two patterns provide clean, proper control of services exposed variously to the internal and external consumers. Security policies appropriate to each type of customer can be developed, deployed, and managed simply through the internal registry in the ESB or through and external WSO2 Governance Registry instance.

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

Adding the Dynamism of Events to a Master Data Management Solution

The WSO2 platform provides all the capabilities to address two common architecture patterns — Master Data Management (MDM) and Event Driven Architecture (EDA).

The integration of these two powerful ideas allowed a System Integrator (and WSO2 customer) to refactor and modernize their architecture in their latest release, and roll that out smoothly to their customers.  The new architecture centered around the MDM and EDA patterns.  Built-in facilities enabling MDM and EDA patterns played a factor in choosing the WSO2 SOA-based Middleware Platform.

The existing application software includes a number of RDBMS data repositories, exposed through application-level APIs from various systems. Requirements for the new architecture included the reuse of the existing data as well as support for updates to the existing data stores from messages originating in the new architecture. Even though existing data was reused, the existing data model was not proving a good fit with the new architecture. Therefore converting the data to a new data model also became a key requirement. The MDM pattern fulfilled these two requirements by connecting to the data repositories and converting the data into a universal data model.

The WSO2 platform sports a number of features useful for implementing MDM.  The OxygenTank article Implementing MDM Patterns on WSO2 SOA Platform describes a pattern called Service Adapters that applied neatly to this situation, leveraging the legacy APIs for data access.  The adapters were coded in Java and deployed in the WSO2 Application Server.  WS-Transfer facilitated transformation of the data models and exposed the new universal data model through XML Web Services.

The message exchange pattern (MEP) used to integrate the application components was pub-sub (publish and subscribe), bringing EDA into the picture. Pub-Sub extends the loose coupling of a SOA, allowing new data sources to be integrated by a simple publish/subscribe operation.  The WSO2 Enterprise Service Bus’s native support for the WS-Eventing standard allows it to act as an event broker, while extending mediation capabilities to any pub-sub interaction as well as providing all the QoS controls available within the ESB.

By introducing a controller into the architecture, more sophisticated event flows are possible, controlled by business processes and rules. In this architecture, the controller was implemented by using WSO2 Application Server and WSO2 Business Process Server, and combined standard JAX-WS based services and rules defined in BPEL.

Dynamic discovery emerged as a key requirement to avoid tightly coupling of service endpoints.  The combination of WS-Discovery support and a compatible service deployer, endpoint availability is published as each service is deployed.

Integration of a Registry/Repository was identified as a key requirement to store service and configuration metadata as well as to enable dynamic metadata look-up. These facilities are provided by the WSO2 Governance Registry, which in addition to a metadata store hosts the topic store for topic-based event subscriptions.

The logical architecture solution above maps to a variety of deployment patterns for different clients of the system integrator, meeting their individual demands for scalability, high availability, infrastructure constraints, and so forth.

The application of aspects of Event Driven Architecture to the problem of Master Data Management adds flexibility and increases the advantages of loose coupling so prized in modern SOA solutions.  We hope the pattern described above gives you some ideas of how your current integration challenges can be approached.

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

A WSO2 First: Multi-Tenant Tomcat WebApps

In a previous post I talked about the advantages of unifying Web Applications and Web Services or APIs into a single server runtime.  And about some of the advantages of making Apache Tomcat part of the WSO2 Carbon family.

But there possibly isn’t any aspect of a Carbon-based Tomcat more exciting than combining it with the power of WSO2 Stratos, the WSO2 Carbon-based cloud middleware platform.  Stratos provides hosting on the cloud with all the advantages that implies: the agility of instant self-service provisioning, elasticity to automatically scale up with business peaks and down as demand subsides, the efficiencies of multi-tenant architecture, and greater intelligence through full monitoring and metering.

As a WSO2 Carbon family product, this means Tomcat Web applications can be deployed on the cloud!  Either on your private cloud infrastructure, or on the WSO2 public cloud, relieving your businesses of the chore of maintaining their own IT infrastructure.

We’re very proud to offer the first commercial release of Tomcat available as either server-based software, a virtual machine image, or as a multi-tenant platform as a service (PaaS) on private or public clouds.

You can try the Tomcat WebApp samples, deploy your own WebApp, and more at https://appserver.cloud.wso2.com.

Afkham Azeez, Senior Architect and Senior Manager

Azeez’s blog: http://blog.afkham.org/