The "Lego Story" of Middleware

on
While playing with google translate, by converting paragraphs from English to Portuguese, I realized that the chance of proper translation becomes higher when shorter sentences are used rather than having lengthy explanations (that would bring more complexity). Therefore, I wish to improve the readability of the posts by using shorter sentences, (may be with more diagrams). However, this blog post describes something special about deployment flexibility of WSO2 solutions, which you might not find with other known middle-ware products.

"Lego-blocks" for the Serious people

Middle-ware is a popular term on these days; especially in an era, where large organizations look for "lego-blocks" to construct their solutions. WSO2 middleware stack can be considered as a rich / comprehensive set of such lego-blocks. Based on your organizational requirements, you can form the WSO2 middleware products to construct solutions following a lego-blocks approach. (What about the "Barbie doll"? Yes, she's pretty; but let's think about a day that you grow bigger).


Why "Lego"?

  1. Loosely-coupled & Independent
  2. Extensible
  3. Simple & Lightweight
  4. Freedom of use (as you wish)
  5. Portability ?

Yes, I mentioned that word Portability! With lego-structures it is possible; would it be even possible with Solutions you build? The answer still is Yes!

My programming life started with Java. Then I saw everybody was talking of platform independance. Now I am working with solutions. Now I am hearing about the same concept—but in this case, the scope is much wider. Today's large organizations have ideas about potential areas that their technological environments would grow in future. But in reality; it is hard to make a detailed plan on implementation of a 100% perfect solution for next 10 years. Because, business needs change, concepts change and technology updates. Therefore, it is worth to consider the agility, flexibility and extensible nature of the technology stack that you select to construct your organizational solutions.

With WSO2 products, you can think of a solution that can be,

  1. Built using your laptop (probably a PoC setup)
  2. Deploy the same on your existing production servers / VMs
  3. Deploy the same on Cloud, when required
This almost is a matter of copying the same binary installation to different places. Depending on growth of the capacity requirements, more nodes can be added to the component clusters.

Start with your laptop

Take your laptop and start with a small PoC (Proof-of-Concept) setup for fun. You may have several concerns such as the below (which are already answered in-line).
  1. How do I get the production ready versions of products?
    • Visit http://wso2.com/products and download. No requests and approvals; just download the production ready version of each product.
  2. How much would it cost?
  3. How much time would take for downloads? 
    • Each binary pack (zip archive) weighs around 250~350 Mb
  4. What are the prerequisites
    • Oracle JDK 1.7
  5. What is the effort/time required to kick it off?
    • Download the binary package (a zipped archive)
    • Extract it
    • Find the start-up script (*.sh or *.bat) inside the 'bin' directory
    • Run the start-up script

Let's consider requirements of building a solution such as what is depicted below.


To construct this, the following WSO2 products can be used as your Lego-Blocks.

  1. WSO2 API Manager [API-M]
  2. WSO2 Enterprise Service Bus [ESB]
  3. WSO2 Data Analytics Server [DAS]
  4. WSO2 Identity Server [IS]
  5. WSO2 User Engagement Server [UES]
  6. WSO2 Data Services Server [DSS]
  7. WSO2 Application Server [AS]

The above solution is only an example based on some hypothetical requirements. WSO2 products do have more capabilities than what is discussed here, which you can use based on your use cases. For example, the WSO2 ESB provides rich integration capabilities more than service / API mediation (which is depicted here). This includes—but not limited to —support on integration scenarios based on files, JMS, specific transports/message formats (HL7 etc) and connectors third-party systems

After this stage, we need to plan the deployment of the solution. When think about a sample deployment, we can consider the same example solution. To explain this more, we may assume the below mentioned.

  1. Expected throughput of the solution is δ
  2. δ is marginally handled by having 1 instance each of above products
  3. High-availability(HA) of the solution is expected
  4. Dashboards and microsites consume less resources, hence run on same instance

At a given time, there is a chance that an instance of the above setup can run out-of-order. In order to take over the load in such a moment, we can

  1. Cluster the above components by duplicating instances
  2. Maintain such duplicated instances
    • either in Active mode
    • or in Passive mode
By having the duplicated instances in active mode, the solution becomes capable of handling an occasional load rising upto 2δ and better high-availability.

However, now we can calculate the instances counts as below, by multiplying each component (in the diagram) by 2 as below.

  1. (API-M + API-M + API-M) × 2 = 6 API-M
    • (API administration + API subscription + API traffic handling) × {high-availability}
  2. ESB × 2 = 2 ESB
    • Mediation × {high-availability}
  3. DSS × 2 = 2 DSS
    • Data Wrapper (Data-as-a-Service) × {high-availability}
  4. AS × 2 = 2 AS
    • Services/API hosting × {high-availability}
  5. IS × 2 = 2 IS
    • Security × {high-availability}
  6. DAS × 2 = 2 DAS
    • Analytics × {high-availability}
  7. UES × 2 = 2 UES
    • Dashboards+Microsites × {high-availability}

Each WSO2 product instance would run on it's own JVM. Therefore—in deployment—any WSO2 Server instance is called a JVM instance in general. The production hardware specification and Production Support pricing of WSO2 products are generally presented against the number of such JVM instances.

With our example scenario, we have 18 JVM instances to consider. Let's discuss the deployment in another blog-post, to keep things simpler and isolated.

Comments

Post a Comment