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 imageor 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.

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/

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.

image

 

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/

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

Open Conversations on the New Business of Enterprise Software