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!  appserver_logo_h23With 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/

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/

Welcome to the New WSO2 Corporate Blog

Happy New Year and welcome to the new WSO2 Corporate Blog!

Five years into the WSO2 journey, the WSO2 company and community continue to grow rapidly. This past year marked a number of significant milestones in our growth:

  • completing another year of 100% growth in customers, revenue and bookings
  • the WSO2 employee count surpassed 100
  • the WSO2 OxygenTank user community passed 30,000 registered members and 300,000 indexed pages
  • the pace of innovation remains high, with nearly 50 product and 20 service releases this last year

You can imagine the amount of documentation, articles, tutorials, and so forth this much activity generates! And WSO2 is unique in the openness and transparency with which we develop our products – with forums, mailing lists, code bases, and building an immense, fully-open knowledge base day by day.

And not just on the OxygenTank! Many bloggers including lots of WSO2 employees are regularly publishing valuable content elsewhere on a huge variety of WSO2 and industry topics. That includes me, Paul, and others of the executive team. Currently there are over 50,000 links back to the OxygenTank. Sometimes it seems impossible to keep up!

So today we’re inaugurating a simpler and more manageable way to share important technical and business milestones, executive viewpoints, and high-level commentary about industry trends. You’ll see posts from me, from co-founder & CTO Paul Fremantle, VPs Lavi De Silva, Jonathan Marsh, and Samisa Abeysinghe, and others. By consolidating and moderating contributions in a single place, we hope to make this corporate blog a concise, insightful, and entertaining way to track WSO2’s progress as we roar into our second half-decade.

Please subscribe or check back often!

Sanjiva Weerawarana, WSO2 CEO

Sanjiva’s blog: http://sanjiva.weerawarana.org/

WSO2 Workshop tours: an easy intro to an easy platform

The workshop series just completed in the US (San Jose, Salt Lake City, Orlando) was attended by a diverse set of people having interests in the platform and on particular set of products. I had the pleasure of meeting people who were there to build their own skills in imageSOA, Cloud, and WSO2 technology and those who were looking to evaluate and potentially deploy WSO2 platform in the enterprise.

Since the workshops run pretty much like a discussion with lots of white boarding and demonstrations, everyone is able to pose their questions and get a clear understanding of the platform. It was quite interesting to hear from people who have already used WSO2 as well as from those who have not.  The questions ranged from “What exactly does an ESB provide to an enterprise?” to “What mechanisms support LDAP within the WSO2 Identity Server?” to “Tell me in concrete terms what is Cloud?”

One particular message that echoed throughout this workshop series was the fact that WSO2 technology is very easy to understand. Within the short span of one day, the audience learns the product well enough to run a basic end-to-end scenario and literally start to answer each others questions! That is a pleasant moment to experience. :-)

I’m sure as much as the audience learned from WSO2, we learned from them as well. Nothing like a teaching moment to bring home both the great ease of use of the product — and what can be even easier to achieve the same effect. The simplicity and straightforwardness of the product are prime ingredients on which the WSO2 platform is built, and we continually strive to improve on these goals through user contact opportunities like the workshop.

My thanks to everyone who came to visit us and give us the time to share the world of WSO2. We’re planning many more workshops this year, on a wider array of topics, and we hope to meet even more of you through these great events.  Keep an eye on the WSO2 events calendar — and let us know where you’d like to see a workshop!

Devaka Randeniya, Director of Sales
Devaka’s Blog: http://devakar.blogspot.com/

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.

image

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.

image

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.

Tomcat LogoBut 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/