In my last two Blogs (WSO2Con 2013 US – Customer Adoption of Open Source Middleware, Analysts View of WSO2 Open Source Middleware), I discussed: 1) enterprises that have adopted WSO2 middleware and 2) analysts view of WSO2 as it stacks up against the other major enterprise middleware vendors such as IBM and Oracle. Assuming 1) and 2) convince you to investigate further, the question is “How should I start evaluating a commercially supported, open source middleware solution?”. But more importantly, how is open source software evaluated against commercial products to determine technical functionality and fit for a development project? The real question is how open source software alternatives can be included as part of an evaluation process. It is common practice to implement a Proof of Concept (POC) in order to choose the most appropriate technology for a project. Commercial vendors view POC’s as a normal part of their business, where pre-sales efforts are provided at no cost in order to demonstrate the vendor’s capabilities. Open source software is licensed at no cost to the customer so there is financial incentive to evaluate the use of open source software for a project. So, you get into the situation of “for fee” or “for free” in order to go through a POC implementation evaluating open source solutions alongside commercial solutions. A consultant or system integrator is not in business to provide POC services at no cost. Evaluating open source software solutions as part of a POC will be hard to justify since commercial vendors will perform POC’s “for free” and consultants or system integrators, by the nature of their business, need to perform a POC “for fee”. Even with the benefit of no software license costs for open source software, there is no assurance that an open source solution for a specific project would be evaluated. There needs to be a different starting point such that the functionality of the open source software is known and there is enough information to justify the inclusion of open source as part of the evaluation process.
How to Start
At the core, how can a customer determine the viability of an open source software solution in general? Are you willing to invest in the effort to evaluate open source solutions? I went through the process of evaluating the WSO2 open source middleware technology stack for my company in order to determine its technical integrity. From previous Blogs, I was convinced that if large customers were adopting it and the analysts were saying good things about it, the next step was to evaluate technical integrity of the WSO2 technology. Whether it’s from a project perspective or a study to evaluate alternatives for reducing software license costs, a good place to start is the implementation of a “reference application”. The implementation of a reference application will foster a good understanding of the capabilities of an open source technology stack and how it can support the needs of the enterprise from a technology perspective.
Most applications that are developed today are based on a service-oriented architecture (SOA) style and use REST and SOAP services to provide business functions to create composite business applications where consumers and providers exchange information with each other. WSO2 has developed an integrated open source middleware technology stack based on several open source projects that are part of the larger Apache project. Use of a reference application provides sufficient introduction to the technology in order to accelerate the knowledge curve around the technologies used to implement it. It is used as the first filter to determine potential applicability of the middleware stack to those offered by other commercial vendors. See Analysts View of WSO2 Open Source Middleware that summarizes the WSO2 technical capabilities as evaluated in several Gartner and Forrester studies. Technical analysis of a reference application is a smaller investment than going through a “for fee” POC implementation because the reference application can be delivered as a training and laboratory exercise by WSO2 subject matter experts (either from WSO2 directly or companies like mine that provide services around WSO2). Most technical POC’s can last from a week to months, depending on the size and complexity of the process. The reference application approach provides enough information (and interaction with the technology) to make a judgment decision about the capability of the middleware technology. The customer can engage with a consultant or systems integrator to implement the POC in parallel with the commercial vendor’s implementation. The investment in engaging with a consultant or system integrator to implement a POC is offset by the potential commercial software license costs of the commercial vendors.
Reference Application
To quickly accelerate knowledge about the WSO2 open source middleware stack, the reference application was selected to understand and demonstrate the design, deployment, governance, API management and runtime monitoring capabilities of the WSO2 middleware technology stack. If you like coffee, you’ll like the reference application. The application that is used was originally developed by Jim Webber, et. al., and subsequently updated by Hiranya Jayathilaka for implementation on WSO2 middleware technology. The Coffee application uses a RESTful and SOAP services and relies on the WSO2 Enterprise Service Bus to perform mediation between the REST and SOAP services. The SOAP service is the Order Management System and is deployed on WSO2 Application Server. In today’s terms, these services are known as API’s and are managed (published API, subscribers, API monitoring and API store) through WSO2 API Manager. Yes, even internal API’s such as these should be managed as if they were external or public API’s. Like the Apple or Google App Store, an enterprise should have an internal App Store in order to expose existing services to more people, socializing their use in other applications. There are two applications (consumers) that interact with the backend Order Management System: 1) Customer application and 2) Barista application. These two applications are state machines because they need to maintain state of an order in process and whether the order has been paid for and subsequently made and delivered to the customer by the Barista. You can visualize exactly how this works if you have purchased coffee at many of the popular retail outlets.
Reference Application Lifecycle Activities
For new applications that are developed, lifecycle activities as shown in Figure 1 will be followed. Wrapped around the application lifecycle is Governance that provides design-time and runtime policies and processes for developing and delivering applications.
Figure 1. Application Lifecycle
So, given an application and the application lifecycle, the usage of various WSO2 technology components help you to understand various aspects of installing, administering and using the individual technologies. The lifecycle stage activities focus on the develop, deploy and run stages addressing the Coffee application lifecycle.
Design-time and Runtime
Given the goal of developing and deploying the Coffee application, what technologies should be used from a design-time and a runtime perspective? From Figure 1., the part of the application lifecycle that will be the starting focus is the “Develop” activity. It is assumed that appropriate planning and design activities have been completed which result in a runtime solution architecture as shown in Figure 2. The business requirements for the Coffee application are not discussed here but from the figure, it can be assumed that visibility into the performance and use of internal API’s (REST or SOAP) is an important part of the overall strategy of implementation of the Coffee application.
If the goal is to develop and deploy the Coffee application, what technologies should be used from a design-time and runtime perspective? From Figure 1., the part of the application lifecycle that will be the focus starts at the “Develop” activity. It is assumed that appropriate planning and design processes have been conducted to develop a solution architecture for the application. The runtime solution architecture is shown in Figure 2. The business requirements for the Coffee application are not discussed here but from the figure, it can be assumed that visibility into the performance and use of internal API’s is an important part of the overall strategy for the Coffee application. planning and design has been conducted to develop a solution architecture for the application. The runtime solution architecture is shown in Figure 2. The requirements for the Coffee application are not discussed here but from the figure, it can be assumed that visibility into the performance and use of internal API’s is an important part of the overall strategy for the Coffee application.
Figure 2. Coffee Application Solution Architecture
The WSO2 middleware technologies that are required to implement the Coffee application include API Manager, Enterprise Service Bus, Application Server, Business Activity Monitor and Complex Event Processor. A discussion of the rationale behind the solution architecture is beyond the scope of this Blog.
The design-time technologies that are part of the WSO2 middleware stack include WSO2 Developer Studio and WSO2 Governance Registry. WSO2 Governance Registry is both a design-time and runtime registry and repository. In this case, Governance Registry is also an important technology used in the runtime environment and the reason why Business Activity Monitoring is included as part of the solution architecture. Figure 3. shows the full Application Lifecycle architecture.
Figure 3. Coffee Application Lifecycle Technology Architecture
Figure 3. shows how the WSO2 technologies can be integrated with each other to streamline the application lifecycle activities. Governance is a key process used to manage the design-time and runtime of the application lifecycle activities since an adopted governance model defines the processes and functions that bridge between development and runtime activities. With the integrated nature of the WSO2 stack, efforts to integrate other technologies (e.g., build systems continuous integration systems, etc.) although the WSO2 stack does an excellent job of supporting many integration standards.
Accelerate the Knowledge Curve
I am quite impressed with the WSO2 approach to and technologies included in their open source middleware stack. An objective of the lifecycle process is to reduce time and effort in delivering applications to the business. Using the WSo2 stack of middleware design-time and runtime technologies, one can quickly get all of the components installed and take advantage of the technology functions to accelerate your knowledge curve around WSO2 middleware. Using the approach of evaluating a reference application such as the Coffee application helps to quickly ramp up knowledge on the WSO2 open source middleware stack in a cost-effective and timely manner and makes the decision to engage in a “for fee” POC with a system integrator or consultant much easier.
David Ching
David has founded or co-founded companies that delivered cutting edge monitoring and management products. He spearheaded the development of one of the first business transaction monitoring products in the APM market. David currently is the founder of iBIT, a consultancy that delivers application consulting, implementation and managed services using an open source middleware platform from WSO2. He believes that the use of open source software will become mainstream among both enterprise and small medium business organizations. He has Bachelor of Science, Master of Civil Engineering and Doctorate in Civil Engineering degrees from the University of Minnesota.
Follow Me:
If you enjoyed this article, please consider sharing it!
