Category Archives: Products

Meet WSO2 EMM 2.2.0!

We’re excited to announce yet another landmark of our EMM story:  the latest version WSO2 EMM 2.2.0! WSO2 EMM comes with a host of device management, app management and analytics features that benefit IT admins as well as device owners themselves.

Let’s explore some of the new key features of this release.

Device Management

The latest release comes with improved APIs for better extensibility, advanced WiFi profiles and supports device restrictions available in Android 5.0 – Lollipop upwards.

Advanced WiFi Profiles

Some organizations prefer to configure enrolled devices over-the-air (OTA). The previous WSO2 EMM version supported only WEP (simple profile with only SSID and password input) and with 2.2.0 organizations will be able to configure enrolled devices with advanced WiFi profile types, such as EAP, WPA2 and enabling TLS/TTLS.

Device Restrictions

WSO2 EMM 2.2.0 supports all device restrictions (e.g. network configuration, VPN configuration, volume control) available from Android 5.0 – Lollipop upwards. For the complete list of supported devices restrictions, refer to our official documentation (Note: camera setting was delivered in a previous release).

App Catalog at Your Service

In the previous WSO2 EMM distribution, when a mobile application needs to be installed on a device either the admin will have to push applications to the mobile device via the WSO2 EMM Management Console or the device owner will have to be granted access to the Management Console, which is not a practical scenario.

With 2.2.0, WSO2 EMM will have a standalone mobile app called ‘App Catalog’. The App Catalog lists all mobile apps the device owner is permitted to install. Device owners will be facilitated to install mobile apps with just a click of a button and to uninstall and remove them as well.

Whitelisting and Blacklisting Apps

With this feature admins will able to whitelist and blacklist mobile apps already installed in the App Store, so that a specific set of mobile applications are provisioned to device owners. This will also enable fencing unknown malicious mobile apps from accessing corporate data.

Room to Grow – Let’s OEM

With this release WSO2 EMM unlocks a host of features capable of underpinning OEM efforts for organizations using custom Android devices as part of their business strategy (e.g. medical devices, point-of-sale devices, kiosks). Managing custom devices is two-fold; you can either maintain custom firmware or use custom apps signed by the device vendor (or by the firmware key provided by the device vendor). The 2.2.0 distribution comes with a system service app that can be installed on the device and thereby used to perform root operations on the device.

emm 2.2

Automatic Device Enrollment

With this, admins will be able initiate the device auto-enrollment by entering serial numbers via the Management Console for the required devices. Once corresponding devices are handed over to device owners, device owners will be facilitated to select the relevant serial number from the device and generate a one-time-token (OOT), which expires within a predefined duration. To complete the enrollment, you can either type in the OOT or simply scan the QR code.

This will increase the speed of enrolling a large number of devices with a few steps with less device user intervention.

Over-The-Air Firmware Upgrade

This feature will allow admins to upgrade device firmware (apps written to device ROM) via the WSO2 EMM Management Console to one/more devices in one go (e.g. a firmware upgrade to all COPE devices). Device owners, on the other hand, need not worry about manually obtaining the latest firmware, as upgrades will be auto-installed.

Silent App Installation, Update, and Removal

In the previous WSO2 EMM version, app installations would only take place subsequent to a user confirmation. With 2.2.0, apps can be installed, updated, or even removed from the device without the device owner’s consent.

Device Hard Lock

This enables admins to completely block a device user that can only be revoked by an admin. This will help organizations to screen out device users who breach organizational policies.

Device Reboot

This facilitates admins to remotely reboot Android devices via the Management Console.

How are my Devices Doing?

WSO2 EMM 2.2.0 offers an array of features to keep you up-to-date around your device portfolio.

Analytics Dashboard

The WSO2 EMM Device Monitoring Dashboard provides admins with insights into unmanaged and non-compliant devices, device distribution by platform, and BYOD/COPE ownership and connectivity.

Device Details

Admins can view both dynamic and static device related information via the WSO2 EMM Management Console. Viewable static data include memory, CPU details, and OS version. Viewable dynamic data include CPU/memory utilization, battery level, installed apps, connectivity strength, power status (i.e. on battery or plugged into a power source), and GPS location.

Alerts on Alerts

The previous WSO2 EMM Management Console facilitated admins to send alerts to Android devices; from WSO2 EMM 2.2 onwards, admins will be notified on the alert delivery and the device owner’s response to alerts as well, i.e. be notified on whether the alert was delivered, displayed, or dismissed. In addition, admins will be able to send custom alert types as well.

WSO2 Enterprise Mobility Manager (WSO2 EMM) is a 100% open source comprehensive platform supporting iOS, Android and Windows devices, which help organizations to deal with both corporate-owned, personally-enabled (COPE) devices and employee-owned devices with the bring your own device (BYOD) program.

You can download the product here and try it out for yourself. If you come across any issues please feel free to report them via the public JIRA.

Will Google Leave On-Premise Apigee Customers Behind?

By now you all know that Google intends to buy Apigee. So what does this mean for their customers? All we can make are assumptions, but the future doesn’t seem too bright. Firstly, customers with SaaS services on Amazon Web Services will most likely have to move to Google’s cloud platform. But this isn’t the biggest issue. It seems plausible that their on-premise customers will not be the highest priority because Google doesn’t have an enterprise on-premise solution, nor does it seem they will create one now.

So what will be the fate of on-premise Apigee customers?

We offer an appealing alternative. WSO2 API Manager offers a rich feature set and adaptable architecture encompassing advanced platform capabilities such as real-time analytics, API governance, and complex back-end integration.

Our roots lie deep in open source software, we’re committed to both on-premise and cloud solutions and offer commercial support at a reasonable price. If you are an Apigee customer who’s concerned about what the future might bring, now is a great time to look at WSO2!

We are serious about helping you fulfill the promise of the API economy. Check out our limited-time offer specially crafted for you. With free subscription periods and discounts, this is an opportunity you won’t be able to refuse!

Perfecting the Coffee Shop Experience With Real-time Data Analysis

Picture a coffee shop.

The person who runs this shop (let’s call her Sam) operates an online coffee ordering service. Sam intends to differentiate her value offering by providing a more personalized customer experience.

Offering customers their favorite coffee as they walk into the store, rewarding loyal customers with a free drink on special occasions – these are some of the things on her mind.

Further the value creation is not limited to her customers but extends to business operations such as real-time monitoring and management of inventory. Sam wants:

  • A reward system where points will be calculated based on order value. Once a reward tier point value is reached, the customer will be notified in real-time about an entitlement for a free drink
  • Inventory levels are updated in real-time on order placement. An automated notification is sent to suppliers in real-time as predicted re-ordering levels are reached

Overview of the solution


Understanding the customer is the first action in  providing a personalized experience. To do this, one must collect intelligence. In today’s digital business, customers pass through many ‘touchpoints’, leaving a digital trail. For example, many would search ‘health benefits of coffee’, some would publish a review on their favourite coffee type – and so on.           

Application Program Interfaces (or APIs) come into play here. In a business context, APIs are a way that businesses could expose their services externally, so that consumers, using an app or some technological interface, can subscribe to and access these services.

For example, Sam can have an “Order API”  that provides a way for consumers to order coffee from her shop using their mobile app.

What we now need is a simple way to create and publish said API and a central place for consumers to find and subscribe for this API. We also need proper security and an access control mechanism.

Data leaving through the API needs to be collected, stored and analyzed to identify patterns. For example, Sam would like to know what the most used combination of ‘coffee and flavors’ is, at which point of the day, by which type of users – which would be helpful for targeted promotion campaigns. For this, we need to understand the data that comes through. 

In base terms, the system requirements for developing such a solution are to: 

  • Design an API for end user access
  • Publish end user attributes (API data) for analytics
  • Process API data in real-time
  • Communicate outcomes

The solution requires to integrating API Management with real time event processing ,where the API end user attributes can be published to a steaming analytic engine for real time processing. There are many offering in the market that provides separate offering, however integrating these offering has it’s own challenges.

WSO2 offers a completely integrated 100% open source  enterprise platform that enables this kind of use case – on-premise, in the cloud, and on mobile devices.

We offer both an API management and streaming analytics product, architected around the same underlying platform, which enables seamless integration between these offerings.

WSO2 API Manager is a fully open source solution for managing all aspects of APIs including creating, publishing, and exposing APIs to users in a secure and scalable manner. It is a production-ready API management solution that has the capability of managing all stages of the API lifecycle in a massively scalable production environment.

WSO2 CEP is one of the fastest open source solutions available today, find events patterns in real-time milliseconds. It utilizes a high-performance streaming processing engine which facilitates real time event detection, correlation and notification of alerts, combined with rich visualization tools to help build monitoring dashboards.

WSO2 MSF4J is a lightweight framework that offers a fast and easy programming model and an end-to-end microservices architecture to ensure agile delivery and flexible deployment of complex, service-oriented applications.

Building an API for end user access

Let’s examine how we can build this with what we’ve listed above.

WSO2 API Manager includes architectural components, the API Gateway, API Publisher and API Store (Developer Portal), Key Manager, Traffic Manager and API Analytics. The API Publisher provides the primary capability to create and publish an API. The developer portal provides a way for subscribers to access the API.

API data to the streaming analytics engine is published through a default message flow. The solution we have in mind requires changing this default flow to capture and publish custom user data.

This is implemented  as a custom ‘data publishing mediator’ (see mediation extensions).  

In a nutshell, message mediation for simplification can be described as the inflow processing of messages, which could be modified,transformed, routed and many other ‘logics’.  Mediators are the implemented component of the logic, which when linked together creates a sequence or flow of the messages.  With API Manager tooling support, a custom flow is designed using a class mediator to decode, capture and publish end user attributes.

The custom sequence extracts the decoded end user attributes passed via JWT headers. The class mediator acts as a data agent that publishes API data to WSO2 CEP. The parameters passed to the class mediator include the connection details to CEP and the published event stream.

Real-time processing of API Data

To capture API data for real-time processing, the same stream definition and event receiver  is created and mapped to the stream. WSO2 provides a comprehensive set of extensionspredictive analytics capabilities  are added via the WSO2 ML extension.

Coffee reordering

The mechanics of reordering coffee based on a real-time analysis goes thus:

An event table represents the inventory details (‘drink name’ ‘ordered quantity’ , available quantity). The API data stream is joined with the event table and the available quantity in stock is reduced using the order quantity as and when events are received. When the reorder quantity level is reached, a email notification is published.

Real-time rewards

Similar to the approach above, the API data is joined with an event table, the event table represents the end user and the reward points generated per order. The reward points are equated to the order size and reward points are added with each new order placed. A reward limit threshold is defined, and when the limit is reached for a new order a notification is sent to the end user, offering a free drink.

Communicating outcomes

To communicate the  outcome of the real time processing event processing, WSO2 CEP provides capability to generate alerts via an SMS, email, user interface  etc. through event publishers. Email notification can be generated to alert management when re-order level are reached, as well as send an SMS to the client to notify offer for a free drink.

Meanwhile, the backend service for order processing is developed as a Java Microservice using WSO2 MS4FJ, which processes the order and can respond with the order id and cost.

Why Open Source?

As a small business, Sam’s resources are limited. Her best strategy for implementing the solution is open source, which offers lower startup costs and effort compared to the high licensing fee and complications involved with the commercial vendors.

Being open source also allows Sam to download, learn and evaluate the product without a high investment, thus minimizing her business risks. Depending on the results of her evaluations, he could go forward or ‘throw away’.

To grow in a competitive business  environment requires companies to differentiate. For small scale business  it becomes more of a challenge to implement such solution due to resource limitations. The seamless integrated capability provided by the open-source WSO2 Platform provides business a low risk and cost effective technology to build and deliver real-time business value to their clients.

The code for this use case

Listed below are what you need to recreate this discussion as a demo:

 

Pre-Requisites

Down the following products and set the port offsets to run the servers on the same server. WSO2 APIM runs on the default offset (0) while the WSO2 CEP offset is 4.

Products
WSO2 API Manager 2.0.0
WSO2 Complex Event Processor 4.2.0
WSO2 MSF4J (WSO2 MicroServices Framework for Java)
WSO2 App Cloud

For simplification purposes the inventory details are stored as tables of a MySQL database.

Execute MySQL database script db_script.mysql to create ‘Inventory’ Database and ‘Rewards’ and ‘orders’ table.

WSO2 MSF4J

  1. Execute the Kopi-service’ java microservice
    1. <WSO2_MSFJ_HOME>/kopi-service/target / Java -jar kopi-service-0.1.jar

Alternatively the java microservice can be deployed in the WSO2 App Cloud.

WSO2 CEP Setup

  1. Setup email configuration for the output event publisher
  2. Copy the JDBC driver JAR file for your database to <CEP_HOME>/repository/components/lib.
  3. Startup the server
  4. Configure a data source as “CEP-DS”.  Select Mysql as the RDBMS and set the database as ‘Inventory’ created.
  5. The created datasource is referenced when defining ‘Event Tables’ when creating the Siddhi queries.
  6. Deploy “Streaming-CApp” CApp . The correct deployment should visualize an event flow as depicted.

WSO2 API Manager Setup

  1. Configure WSO2 API Manager to pass end user attributes as JWT Token.
  2. Copy the custom data publisher implementation (org.wso2.api.publish-1.0-SNAPSHOT.jar ) library to $API_MGR_HOME /repository/components/lib
  3. Startup the Server.
  4. Login to the API Publisher:
  5. Create and publish an  API with the following details
    1. Context -<context>
    2. Version – <version>
    3. API Definition
      1. GET – /order/{orderId}
      2. POST -/order
    4. Set HTTP Endpoint: http://<server-ip:port>/WSO2KopiOutletPlatform/services/w_s_o2_kopi_outlet_service
    5. Change the default API call request flow by enabling message mediation and uploading file  datapublisher.xml as the ‘In Custom Sequence’.
  6. Login to the API Store and subscribe to the created API
  7. Invoke API with an order exceeding available quantity { “Order”:{ “drinkName”:”Doppio”, “additions”:”cream”, “orderQuantity”:2000 } }

 

Predicting re-order levels

The re-order quantity is initially calculated based on a ‘re-order factor(ROF) and order quantity formula (ROF * order quantity). Siddhi provides a machine learning extension for predictive analytics. The reorder quantity can be predicted using machine learning model.  

The re-order data points calculated previously (with the formula) can be used as data sets to generate a machine learning model with WSO2 Machine Learner. A predicted re-order quantity is calculated based on the “Linear Regression” algorithm, with the “Reorder factor (ROF) and coffee type  as the features.

The siddhi query for predicting reorder quantity is commented under ‘Predict reorder quantity using Machine Learning extensions. It can be executed by replacing the query under ‘Calculating reorder quantity’.

Appendix: code

Custom Sequence

<?xml version=”1.0″ encoding=”UTF-8″?>

<sequence name=”publish-endUser” trace=”disable” xmlns=”http://ws.apache.org/ns/synapse”>

 <log level=”full”/>

 <property expression=”get-property(‘$axis2:HTTP_METHOD’)” name=”VERB”

   scope=”default” type=”STRING” xmlns:ns=”http://org.apache.synapse/xsd”/>

 <property expression=”get-property(‘transport’,’X-JWT-Assertion’)”

   name=”authheader” scope=”default” type=”STRING” xmlns:ns=”http://org.apache.synapse/xsd”/>

 <log level=”custom”>

   <property expression=”base64Decode(get-property(‘authheader’))”

     name=”LOG_AUTHHEADER” xmlns:ns=”http://org.apache.synapse/xsd”/>

 </log>

 <property expression=”base64Decode(get-property(‘authheader’))”

   name=”decode_auth” scope=”default” type=”STRING” xmlns:ns=”http://org.apache.synapse/xsd”/>

 <script description=”” language=”js”><![CDATA[var jsonStr= mc.getProperty(‘decode_auth’);

var val= new Array();

val=jsonStr.split(“}”);

var decoded= new Array();

decoded= val[1].split(“enduser\”\:”);

var temp_str= new Array();

temp_str=decoded[1].split(‘\”‘);

mc.setProperty(“end_user”,temp_str[1]);]]></script>

 <property expression=”get-property(‘end_user’)” name=”endUser”

   scope=”default” type=”STRING”/>

 <log level=”custom”>

   <property expression=”get-property(‘endUser’)” name=”Log_Enduser”/>

 </log>

 <class name=”org.wso2.api.publish.PublishMediate”>

   <property name=”dasPort” value=”7619″/>

   <property name=”dasUsername” value=”admin”/>

   <property name=”dasPassword” value=”admin”/>

   <property name=”dasHost” value=”localhost”/>

   <property name=”streamName” value=”Data_Stream:1.0.0″/>

 </class>

</sequence>

Siddhi Query

/* Enter a unique ExecutionPlan */

@Plan:name(‘Predict’)

/* Enter a unique description for ExecutionPlan */

— @Plan:description(‘ExecutionPlan’)

/* define streams/tables and write queries here … */

@Import(‘API_Stream:1.0.0’)

define stream APIStream (drinkName string, additions string, orderQuantity double, endUser string);

@Export(‘allOrder_Stream:1.0.0’)

define stream allOrderstream (drinkName string, qtyAvl double, qtyPredict double);

@Export(‘predictStream:1.0.0’)

define stream predictStream (drinkName string, qtyPredict double);

@Export(‘Order_Stream:1.0.0’)

define stream orderStream (drinkName string, orderQty double, qtyAvl double, qtyOrder double, ROF double); 

@Export(‘reOrder_Stream:1.0.0’)

define stream reOrderStream (drinkName string, qtyAvl double, qtyPredict double);

@Export(‘outOrder_Stream:1.0.0’)

define stream outOrderStream (drinkName string, qtyOrder double, qtyReorder double, ROF double);

@Export(‘ULPointStream:1.0.0’)

define stream ULPointStream (subScriber string, points double);

@Export(‘totPointStream:1.0.0’)

define stream totPointStream (subScriber string, totPoints double);

@Export(‘FreeOrderStream:1.0.0’)

define stream FreeOrderStream (subScriber string, points double); 

@from(eventtable=’rdbms’, datasource.name=’CEP-DS’, table.name=’orders’)

define table drinkEventTable(drinkName string, qtyAvl double, qtyOrder double, ROF double);

@from(eventtable=’rdbms’, datasource.name=’CEP-DS’, table.name=’rewards’)

define table pointEventTable(subscriber string, points double);

from APIStream#window.length(0)as t join drinkEventTable as d

on t.drinkName==d.drinkName

select t.drinkName as drinkName, t.orderQuantity as orderQty, d.qtyAvl as qtyAvl,d.qtyOrder as qtyOrder, d.ROF as ROF

insert into orderStream; 

/* ——Drink Reordering————- */

/* —–Calculating reorder quantity———– */ 

from orderStream#window.length(0) as p join drinkEventTable as o

on o.drinkName==p.drinkName

select o.drinkName,o.qtyAvl,(p.orderQty* p.ROF) as qtyPredict

insert into allOrderstream;

/*———————Predict reorder quantity using Machine Learning extentions—————*/

/*

from orderStream

select drinkName,ROF

insert into ROF_Incoming;

from ROF_Incoming#ml:predict(‘registry://_system/governance/ml/Reorder.Model’,’double’,drinkName,ROF)

select drinkName, qtyReorder as qtyPredict

insert into predictStream;

from predictStream#window.length(0) as p join drinkEventTable as o

on o.drinkName==p.drinkName

select o.drinkName,o.qtyAvl, p.qtyPredict

insert into allOrderstream;

*/

/*——————————————————–*/

partition with (drinkName of allOrderstream)

begin @intro(‘query3’)

from allOrderstream[qtyPredict>=qtyAvl]

select drinkName,qtyAvl,qtyPredict

insert into #tempStream2;

from e2=#tempStream2

select e2.drinkName, e2.qtyAvl,e2.qtyPredict

insert into reOrderStream

end;

from orderStream[(qtyAvl-orderQty)>=0]#window.length(0)as t join drinkEventTable as d

on t.drinkName==d.drinkName

select t.drinkName as drinkName,(d.qtyAvl – t.orderQty) as qtyAvl

update drinkEventTable

on drinkName==drinkEventTable.drinkName; 

/*——————————————– */

 /*—– Offer free drink ——-*/

from APIStream

select endUser as subScriber ,orderQuantity as points

insert into ULPointStream;

 from ULPointStream as u join pointEventTable as p

on u.subScriber == p.subscriber

select u.subScriber as subscriber ,(u.points+p.points) as points

update pointEventTable

on subscriber==pointEventTable.subscriber;

from ULPointStream[not(pointEventTable.subscriber==subScriber in pointEventTable)]

select subScriber as subscriber,points

insert into pointEventTable;

from ULPointStream as u join pointEventTable as p

on u.subScriber == p.subscriber

select u.subScriber as subScriber,p.points as totPoints

insert into totPointStream;

 partition with (subScriber of totPointStream)

begin @info(name = ‘query4’)

from totPointStream[totPoints>=100]

select *

insert into #tempStream;

 from e1= #tempStream

select subScriber, totPoints as points

insert into FreeOrderStream

end ;

/*————————————*/

WSO2 API Manager for Small and Medium Enterprises

WSO2 API Manager provides a very light-weight, robust and a scalable API management solution for organizations who want to manage APIs. WSO2 API Manager comes as a single product distribution but has five different components and can be deployed as individual components allowing greater flexibility in deployment while adhering to internal security policies of the organization. Running WSO2 API Manager as components allows more flexibility when scaling the solution and optimizes the resource usage.

WSO2 API Manager is deployed as a distributed deployment at many large organizations that expose APIs for both internal and external service consumers with millions of API calls serviced during a day. These organizations rely on WSO2 API Manager to deliver critical services to its stakeholders, which has a direct impact on their business operations. A distributed deployment can typically cater over 2500 API calls a second which is a staggering 200 million+ API calls a day.

Even though this kind of a requirement holds true for large-scale organizations, there are many organizations who need to start small and want a simple API manager deployment to support their requirements. WSO2 provides two solutions for such customers.

  1. On-Cloud – WSO2 API Cloud, which is a subscription-based API manager solution that you can subscribe to and pay based on the API usage. WSO2 API cloud offer plans ranging from 250, 000 to 50 million API calls a day.
  2. On-Premise – WSO2 offers an all-in-one API manager deployment pattern that allows you to deploy the WSO2 API Manager on-premise as a single instance. This type of on-premise deployment can support up to 500 API calls a second (nearly 43 million API calls a day). More details on this option are given below.

An all-in-one API Manager deployment has i5 components (Gateway, Key Manager, Store, Publisher and Traffic Manager) deployed inside a single product distribution. The deployment is very easy to setup and WSO2 provides a very comprehensive setup guide1 that provide step by step instructions on how to deploy the product. All-in-One API Manager can be deployed as a single active node, in Active/Passive mode or as an Active/Active node cluster. The diagrams shown below visually illustrates the 3 types of possible deployment patterns.

api-manager-for-smes-1

Fig 1: Single API Manager node

api-manager-for-smes-2

Fig 2: Active/Passive deployment

api-manager-for-smes-3

Fig 3: Active/Active API Manager deployment

It is recommended to deploy the API Manager fronted by a load balancer for all three deployment patterns. If APIs need to be exposed for external consumption it is recommended to use a Reverse Proxy or a Firewall along with the load balancer. A Reverse Proxy or a Firewall is required to route legitimate traffic from outside the network to the API Manager node that resides in the LAN. It is recommended to configure the API Manager to work with an external RDBMS to ensure reliability. If API Manager is deployed as an active/active or active/passive setup it would require a content synchronization mechanism such as Rsync2 (DeltaCopy or cwRsync for Windows) to synchronize APIs between the two nodes.

With the new all-in-one API Manager deployment pattern, there are multiple options for an organization to structure their deployment. If you are building a large-scale API Manager deployment then it would be recommended to start with a distributed API Manager deployment. However, if you want to start small and make the API Management platform available quickly this type of a deployment would be the ideal choice.

WSO2 API Manager 2.0.0: Better Statistics

Introduction

Any API management tool requires the ability to view statistics – accurately and with details essential to the operation of APIs. WSO2 API Manager 2.0.0 introduces powerful analytics features along these lines by using the capabilities of WSO2 Data Analytics Server (WSO2 DAS), bringing all API, application and subscription related statistics to one location.

image05

New additions

In order to help you make sense of these analytics, we’ve added the following graphs:

1.Published APIs Over Time

This graph can be used to check API creation rates. A user can check APIs based on the API provider or can view statistics related to all API providers.

image05

2. API Latency

The API Latency breakdown graph can be used to check time consumption for each level in the message flow. It shows total time taken to handle a request and provides the time each component spends on that request – for example, a user can check the amount of time spent on the authentication process and so on. This graph is useful for identifying delays in the API.

image013. API Usage Across Geo Locations

This graph provides statistics based on the location of the API request. It uses X-Forwarded-For header to identify the location of the user.

image06

4. API Usage Across Usage Agent

This graph provides information related to the access mechanism of the API, and helps provide insight into the kind of devices and platforms used to access the API – mobiles, computers and so on.

image08

We’ve also added an Applications Created Over Time graph under the Applications section. As with the API creation graph, this provides statistics related to application creation. Users can drill down the data based on the registered user and the API in question.

image02

In addition to these come the subscription graphs: Developer Signups Over Time and Subscriptions Created Over Time, both of  which are self-explanatory.

image00

image07

How These Statistics Work

WSO2 Analytics Server for API Manager is essentially a fully functional WSO2 DAS server.

image03

In a nutshell, WSO2 API Manager 2.0.0 sends the following event streams to API Manager Analytics:

org.wso2.apimgt.statistics.request:1.1.0

org.wso2.apimgt.statistics.response:1.1.0

org.wso2.apimgt.statistics.fault:1.0.0

org.wso2.apimgt.statistics.throttle:1.0.0

org.wso2.apimgt.statistics.workflow:1.0.0

org.wso2.apimgt.statistics.execution.time:1.0.0

org.wso2.analytics.apim.alertStakeholderInfo:1.0.0
The APIM Analytics Server process these events and writes the summarized data to a shared database. WSO2 API Manager then queries statistics from this database to display in the API Manager Publisher and Store.

Footnotes

One significant change in WSO2 API Manager 2.0.0 statistics is the removal of the graphical user interface (GUI) for configuring statistics. In WSO2 API Manager 1.10, a GUI was provided to handle this DAS-related configuration. We’ve moved this functionality back into the api-manager.xml file.

We’ve also taken out the DAS Rest client – with 2.0.0, the default and only implementation is APIUsageStatisticsRdbmsClientImpl, which uses an RDBMS client to get data from the database.

Since this is essentially a DAS server, you can use features such as gadgets and realtime analytics (using Siddhi) for better or more complex visualizations of the events sent from WSO2 API Manager.

Keep your WSO2 products up to date with WUM

We at WSO2 continuously improve our products with bug fixes, security fixes , and various other improvements. Every major release of our WSO2 products is followed by a series of periodic dot releases that roll up all these recent updates.

We want everyone evaluating, developing on, or preparing WSO2 products for production deployments to have the best experience and especially not trip over a bug that has already been fixed! WSO2 Update Manager (WUM) makes this process much easier – now you can get access to latest updates as and when we release them.

What is WUM?

WUM is a command-line application which allows you to keep WSO2 products up-to-date. It determines which updates are new and relevant for your WSO2 products, downloads and installs them. WUM builds you a new product distribution with all the relevant updates; this distribution is ready to deploy into your development or production environment. Note that WUM will not push updates into production: you have full control over when and how you want to such pushes to occur.

Updates are available for the following products and versions. We are in the process of adding more products and versions.

  • WSO2 Enterprise Service Bus 5.0.0
  • WSO2 Enterprise Service Bus 4.9.0
  • WSO2 Enterprise Service Bus Analytics 5.0.0
  • WSO2 API Manager 2.0.0
  • WSO2 API Manager Analytics 2.0.0

Note that fresh WSO2 product distributions downloaded via the wso2.com site or using WUM, are licensed under Apache 2. However, product distributions built by WUM with updates installed are licensed under WSO2 Update License 1.0. The updated product distributions are not licensed for use in production without a valid WSO2 subscription. Visit http://wso2.com/support for more information about WSO2 subscription.

Installing WUM

You can download WUM from http://wso2.com/wum. Download the binary release suitable for your operation system and processor architecture. Binary distributions are available for Linux, Mac OS, and Windows (follow installation instructions available on the same download page).

Once the installation is completed, open a new terminal and execute the following command. You should get the help page with all the available commands.

$ wum

Initialize WUM with your WSO2 credentials

You need to have a WSO2 account to get started with WUM. If you don’t have an account with WSO2, please create one here.

$ wum init
You need a WSO2 account to start using wum.
Don't have one yet? Sign up at https://wso2.com/user/register

Please enter your WSO2 credentials to continue
Username: sameera@wso2.com
Password for 'sameera@wso2.com': 
Authenticating...
Done!

-- Welcome to WUM 1.0-beta --

* Find more information at http://wso2.com/wum
* Documentation: https://docs.wso2.com/display/ADMIN44x/Updating+WSO2+Products
* JIRA: https://wso2.org/jira/browse/WUM

What's next? Have a look at the following list of wum commands:

Add WSO2 products to your product repository
  wum search  Search WSO2 products         
  wum add     Add or download WSO2 products

Update WSO2 products available in your product repository
  wum check-update Check for new updates    
  wum update       Update your WSO2 products

Manage WSO2 products available in your product repository
  wum list      List WSO2 products           
  wum describe  Show details of WSO2 products
  wum delete    Delete WSO2 products

Use "wum [command] --help" for more information about a command.

Use "wum [command] --help" for more information about a command.

Local product repository

WUM maintains a local product repository in your machine where it stores WS02 product distributions. Whenever you update a product, WUM creates a new distribution with all these updates and stores it in this repository. By default, WUM creates this repository in the user’s home directory, but you have the option to change this as well.


Search and add WSO2 products

Before you update any WSO2 product, you need to add the product to your local product repository. You can either download a product or add an already downloaded product. If you are not sure about what product name to use, you can use the ‘wum search’ command. If you run the search command without any arguments, it will list all the WUM supported WSO2 products.

$ wum search
Connecting to WSO2 Update...

wso2esb-5.0.0 - Enterprise Service Bus
wso2esb-analytics-5.0.0 - Enterprise Service Bus Analytics
wso2am-2.0.0 - API Manager
wso2am-analytics-2.0.0 - API Manager Analytics
wso2esb-4.9.0 - Enterprise Service Bus

What's next?
  use "wum add <product>" to download a product
  e.g "wum add wso2esb-5.0.0" to download Enterprise Service Bus 5.0.0

You can also search using keywords.

$ wum search api manager
Connecting to WSO2 Update...

wso2am-2.0.0 - API Manager
wso2am-analytics-2.0.0 - API Manager Analytics

What's next?
  use "wum add <product>" to download a product
  e.g "wum add wso2am-2.0.0" to download API Manager 2.0.0

If you look at the examples given in the “what’s next” section, you would see the expected format of the product name to use. Use the following command if you want to add the latest version of wso2esb.

$ wum add wso2esb
Connecting to WSO2 Update...
The following product(s) will be downloaded.
  wso2esb-5.0.0.zip
After this operation, 218.1MB of additional disk space will be used.
Do you want to continue? [Y/n]
Downloading product wso2esb-5.0.0... [2.4MB/218.1MB]

If you want to add a specific version of wso2esb then you need to specify the version as follows:

$ wum add wso2esb-4.9.0

You also have the option to add an already downloaded product distribution using the add command.

$ wum add --file ~/user/wso2/dist/wso2esb-5.0.0.zip

Now try the following command to see the list of add products.

$ wum list

Update WSO2 products

As I’ve explained earlier, WUM creates a new product zip file with all the updates installed. But if you want to check whether updates are available before you attempt to update, you can use the “check-update” command as follows.

$ wum check-update wso2esb-4.9.0
Connecting to WSO2 Update...

Checking for latest updates for wso2esb-4.9.0...
96 updates are available
[WARNING] 11 critical security updates. WSO2 strongly recommends that you install these updates now.

What's next?
  use "wum update" to install latest updates

Now let’s update the products using the “update” command

$ wum update wso2esb-4.9.0
Connecting to WSO2 Update...

Validating your subscription status for product wso2esb...
[WARNING] Your credentials are not associated with an active WSO2 subscription.
Please remember that updates are not licensed for use in production without a valid WSO2 subscription.
See: http://wso2.com/wum for more details.

Updating wso2esb-4.9.0...
96 updates are available
Downloading updates...
Installing updates...
Preparing update summary...
Building updated product...
Update summary:
  Installed updates: 96
  * [WARNING] WSO2 strongly recommends to use this updated product for production as soon as possible.
  Security updates: 11
  Updated Product: /Users/sameera/.wum-wso2/products/wso2esb/4.9.0/wso2esb-4.9.0.1472889183206.zip
  * More information about updates are available inside the above product archive
  Update summary(pdf): (product-archive)/updates/summary-2016-09-08T19-23-50/update-summary-1472889183206.pdf
  * Configuration changes are available
  Change log: (product-archive)/updates/summary-2016-09-08T19-23-50/change-log-1472889183206.txt

What's next?
  use "wum list [<product-pattern>]" to list products in your local repository
  use "wum describe [<product-pattern>]" to get more details of products

If you don’t have an active WSO2 subscription for wso2esb, you would get a warning as above. This means you can use the updated product for your development activities, but you are not supposed to use it in production.

Once the update is completed, you should be able to see the updated product files in your local repository. We version updated product distributions using the timestamp of the latest update.

$ wum list
Product        Updated              Filename                       
wso2am-2.0.0   08 Sep 16 18:01 IST  wso2am-2.0.0.1473322072976.zip 
wso2am-2.0.0   -                    wso2am-2.0.0.zip               
wso2esb-4.9.0  08 Sep 16 19:24 IST  wso2esb-4.9.0.1472889183206.zip
wso2esb-4.9.0  -                    wso2esb-4.9.0.zip

Manage your product repository

There are several WUM commands available for you to manage your local product repository. The “wum list” command lists all the available products. If you want to get more information about a product, you can use the “wum describe” command. It gives you the location of the product file and update history, among other information.

$ wum describe wso2esb-4.9.0.1472889183206.zip
Filename:  wso2esb-4.9.0.1472889183206.zip
Product Name:  wso2esb
Product Version: 4.9.0
Kernel Version:  4.4.1
Last Updated Time: 2016-09-08T19:23:55+05:30
Product File Path: /Users/sameera/.wum-wso2/products/wso2esb/4.9.0/wso2esb-4.9.0.1472889183206.zip
No Of Times Updated: 1
Installed Updates: 96
Update History:
 Date                       Installed Updates  Username        
 2016-09-08T19:23:55+05:30  96                 sameera@wso2.com

In case you want clean up your product repository by deleting files, you can use the “wum delete” command.

$ wum delete wso2esb-4.9.0
The following product file(s) will be deleted.
  wso2esb-4.9.0.1472889183206.zip
  wso2esb-4.9.0.zip
Do you want to continue? [y/N]

The above command will delete all the wso2esb-4.9.0 product files including the updated files. List, describe and delete commands accepts a product pattern; therefore you can filter out products by given a particular pattern.


We’ve released the Beta version of WUM. Try it out and let us know what you think.

CREATE-NET Discusses WSO2 and the Future of IoT

Charalampos Doukas is a researcher at CREATE-NET – or rather, the Center for Research And Telecommunication Experimentation for NETworked communities, the non-profit research center headquartered in Italy. Charalampos spoke at WSO2Con EU 2015 about his research into the world of open source in IoT and where WSO2 stands in this context.

In his 28-minute presentation, Charalampos started off by pointing out that despite the strange lack of discussion about open source in IoT conferences, to him the whole thing started with the open source community “with people connecting their Arduinos to the Internet and sharing their sensor data.” In fact, Pebble and SmartThings (the smart home platform maker acquired by Samsung) both used Arduinos for their 2012 proofs of concept; open source has always been closely tied to IoT platforms as we know them.

From a developer’s perspective, an IoT platform must be able to connect devices to each other and to users and to allow services to consume the data and control these devices, delivering interesting use cases. The main features, thus, are to communicate with and actuate devices, to collect and manage data from them, and to allow user interaction. A “spaghetti” of standardization bodies push a wide variety of protocols and standards for doing all this.

As Charalampos explained, there are over 40 IoT platforms that fulfill these requirements. Some of them, like ThingSpeak and Nimbits, are open-source; Nimbits, one of the oldest, runs on Google App Engine and even integrates with Wolfram Alpha (leading to some interesting use cases). Then there are the likes of SiteWhere, which embeds WSO2 Siddhi for Complex Event Processing and connects to WSO2 Identity Server.

“So, WSO2,” he said in his talk. “This picture is quite clear and illustrates the different layers that you need to build an IoT application and where WSO2 starts. You have the devices, you have the enterprise service bus, and message broker that enable the messaging; you can do the processing and analytics, and on top of that you can have things like a dashboard or web portal for managing data and devices. The new things that are coming – and hopefully will be more and more improved and used – are the device manager and identity server.”

Charalampos quickly sketched out what he sees as the core components of the WSO2 IoT platform: the WSO2 Message Broker, Enterprise Service Bus, Identity Server, Enterprise Mobility Manager, User Engagement Server, API Manager, Business Activity Monitor and Complex Event Processor. Yes, it’s a handful to enunciate – but the way we’ve built our platform, each component is built on the Carbon framework and provides functionality that you can add and subtract as needed. This makes it easy to not just maintain the lightweight stack that an IoT solution typically needs, but also to integrate with other software that provides similar functionality.

One of our biggest changes since then is to create an all-new product, the upcoming WSO2 IoT Server, bringing together the best of the WSO2 platform’s many capabilities into a more out-of-the-box, enterprise-grade server-side IoT device management architecture. Once integrated with WSO2 Data Analytics Server (which contains the functionality of WSO2 CEP and WSO2 BAM), it offers advanced IoT device analytics, including policy-based edge analytics and predictive analytics using machine learning. And true to the roots of IoT, this remains open source.

To explore this future addition to our IoT platform for free, visit wso2.com/products/iot-server/. To watch the full video of Charalampos Doukas’ analysis of the IoT sphere, click here.

 

Meet the WSO2 Enterprise Service Bus 5.0

The WSO2 Enterprise Service Bus is renowned as a lightweight, 100% open source ESB; it helps everything from big, digital-first companies (like eBay) to transnational governing bodies (like the Eurasian Union) achieve the kind of enterprise integration scenarios they need to work. We’ve now released version 5.0 of the WSO2 ESB – and here’s why you should take a look. 

As part of our new product strategy, the WSO2 ESB 5.0 release is composed of three key components – the runtime, tooling, and analytics. We’ve also added several new, major features:

  • Mediation Debugger for error detection in mediation flows
  • Data mapper to convert and transform data
  • Mediation statistics and tracing using ESB Analytics component
  • Support for JMS 2.0 and WebSocket transports

Interested? Let’s explore in more detail.

WSO2 ESB Tooling 5.0

The new WSO2 Developer Studio-based ESB tooling plug-in is built to work on top of Eclipse Mars2, the widely used IDE. It offers developers with improved usability and brings some new capabilities to the table:

Mediation debugging

At the operational level, a series of mediators called sequences determine the behavior of messages. Users were previously unable to figure out if these mediators -including their inputs, processing, and outputs – were operating as intended. The newly introduced Mediation Debugger allows users to debug this message mediation flow proactively, to identify any errors and rectify them in the development environment itself (figure 1).

image05Figure 1: Debugging mediation flow

Data conversion and transformation

 

WSO2 Data Mapper is one of the most awaited features by our customers. Having been built as a mediator that can be included in the mediation flow, it is capable of converting the data format of a message between JSON, XML or CSV (figure 2). It also comes with an operations palette that supports a number of operations to help users perform different functions in data mapping (figure 3). For instance, arithmetic functions enable users to add, subtract, multiply, divide or carry out other functions on data as a part of its transformation. Users can easily drag and drop operators into the mapping diagram and edit on the go.

The main categories of operations are listed below.

  • Common
  • Arithmetic
  • Conditional
  • Boolean
  • Type conversion
  • String

We’ve made it more appealing to developers by introducing a graphical mapping experience that also generates the execution files required to run on the Data Mapper Engine.

image09Figure 2: Data mapping

What’s special about WSO2 Data Mapper is that it can function independently of other WSO2 products or components.

image00Figure 3: Adding operations in data transformation

WSO2 ESB Analytics 5.0

The analytics component is a new addition to the ESB that lets users publish information on ESB processes. Previously, users had the ability to connect WSO2 DAS and define their own ESB dashboards. However, we’ve made the experience better by providing an analytics dashboard out of the box, with pre-defined statistics for ESB artifacts such as proxy services, APIs, sequences, endpoints and inbound endpoints. Users have the option here to choose which artifacts’ statistics and/or tracing should be published by enabling or disabling this through the runtime instance.

The dashboard displays a summarized view of the requests processed, their success/ failure rates, throughput, and message count over a specified time period, and top artifacts by request count (Figures 4, 4a, 4b, 4c respectively). For example, users can identify the top sequences, endpoints or the top APIs by request count in separate gadgets.

image04Figure 4: Statistics dashboard

image03Figure 4a: Overall transactions per second graph

image01

Figure 4b: Message count graph

image08

Figure 4c: Top endpoints by request count graph

The dashboard provides many features – from configurable timelines and detailed stats by artifact type to visual additions, such as theming and the customizability to portray your brand and explain statistics (figure 5).

image07

Figure 5: Dashboard with configurable timelines, theming buttons and navigation pane

Tracing mediation flows

Not only is it important to monitor statistics, but the ability to drill down into anomalies encountered in ESB processes is essential for DevOps teams, especially in production environments. Hence, we’ve introduced message tracing capabilities to provide more visibility into message mediation flows so developers can identify problems in live environments.

For a particular artifact type such as an API or proxy service, operational teams can dive into obtaining overall message count, latency and processing details of each message. Consider a scenario where messages pass through a REST API: the message gadget (figure 6) helps DevOps teams proactively identify which messages failed, as shown below.

image06Figure 6: Messages and their status

We’ve also made it possible to further scrutinize into the message flow (figure 7), and dive into a mediator and view its properties in relation to a payload, transport properties and context properties (figure 8), both before and after the mediator. It provides a mechanism by which operational teams can verify if message flows operate as they are intended, and fix any errors.

image02Figure 7: Message flow detailed view

image10Figure 8: Mediator properties

These features also are useful in testing environments to evaluate changes done to artifacts (sequences, APIs, endpoints etc ) or message mediation flows, as a feedback mechanism prior to moving into production.

Support for JMS 2.0 and Websocket

Last but not least, we’ve also added two transports – JMS 2.0 and WebSocket – to be able to support more integration use cases.

With JMS 2.0, the WSO2 ESB supports new messaging features – shared topic subscription, getting the JMSX delivery count and specifying message delivery delays. A typical scenario would be using the JMS endpoint to act as a shared topic listener so that it can connect to shared topic subscribers and help share the workload. We’ve also introduced WebSocket as a transport and inbound protocol to support bidirectional message mediation mostly advantageous in near-real-time communication for IoT, web, and mobile scenarios.

We’ve bumped the product quite a bit in this release and we’d love to hear what you think about the all new WSO2 ESB 5.0.

Go ahead and try it yourself – it’s free to download and use!

Managing Identity Across the Internet of Things

 

network-782707_960_720 (1)

It’s estimated that at least 50 billion devices will be connected to the Internet by end-2020. That’s more than six times the entire population of the world! With this rapid increase of the Internet of Things (IoT), the concept of identity management has extended to the Identity of Things (IDoT).

WSO2 Director of Security Architecture Prabath Siriwardena wrote a white paper that explores the benefits, risks and challenges of implementing an IDoT solution based on the concept of “connected identity”.

He explains that through IDoT, organizations can assign unique identifiers with associated metadata to devices, enabling them to connect and communicate securely and effectively with other entities over the Internet. Your ultimate goal is to reach out to as many customers, partners, distributors, and suppliers as possible that would result in more business interactions and revenue growth. This would greatly increase the number of external digital identities that interact with your enterprise. An external identity provider can be treated as an identity silo that shares its identity data or IDoT via APIs. You first need to trust the identity provider in order to accept the given user identity. Beyond this, you need to speak the same language to transport the identity data. If not, you need to either fix the identity provider’s end to speak the same language or do the same for your own enterprise.

This is not a scalable approach, and will eventually end up in a spaghetti identity anti-pattern. To avoid this, you should build a protocol-agnostic security model. With the identity bus or identity broker pattern, your enterprise isn’t coupled to a specific identity provider or a given federation protocol. The broker maintains the trust relationships between each entity as well as identity tokens between multiple heterogeneous security protocols. This creates a common, connected identity platform that enforces controlling, auditing and monitoring of identities.

Some benefits of this pattern include

  • Frictionless approach to introducing new service and identity providers and removing existing ones.
  • Easy enforcement of new authentication protocols.
  • Ability to perform claim transformations, role mapping, and just-in-time provisioning.
  • Centralized monitoring, auditing and access control.
  • Easy introduction of a new federation protocol.

When implementing an identity broker you need to follow certain fundamentals. It needs to be federation protocol, transport protocol, and authentication protocol agnostic. Additionally, it should provide the ability to perform claim transformations, home realm discovery, and multi-option and multi-step authentication, among others.

WSO2 helps you solve identity management needs across your enterprise applications, services, and APIs by utilizing the full breadth of the WSO2 platform. By combining WSO2 Identity Server’s comprehensive security model based on OAuth 2.0 with WSO2 API Manager, you can easily build an end-to-end API security ecosystem for your enterprise. Avoid vendor lock-in and enable integration across systems with WSO2’s open source model, which acts as a fully functional enterprise identity bus.

To learn more, download Prabath’s white paper here.

What’s new in MSF4J 2.0?

The MSF4J team is excited to announce the latest release of WSO2 Microservices Framework for Java (MSF4J) 2.0!

MSF4J is essentially a lightweight, high performance framework for developing and running microservices.

This release comes with a number of major enhancements and features:

  • An improved thread model and transport architecture
  • Spring and Swagger support
  • ExceptionMapper and StreamingOutput support
  • More powerful form submission commands
  • Circuit Breaker state management based on Nygard’s pattern

Let’s examine these in more detail.

Improved thread model and transport architecture

The default thread model in MSF4J 1.0 included the Netty boss threads handing over the requests to Netty worker threads, and the microservice requests being executed using the Netty worker threads. However, this leads to the problem of the Netty worker thread pool getting exhausted if the threads took long to execute or were blocked. That results in requests being dropped.

With the new thread model, service requests are executed using a separate executor thread pool (application thread pool) by default. There is also the option of handing over the incoming request to an LMAX disruptor which is useful in certain scenarios. As a user, you will have full control over configuring these thread pools.

image05

MSF4J thread model. S in the diagram is your MSF4J service.

MSF4J 1.0 also had a direct dependency on Netty, but with 2.0, we’ve brought in an abstraction called CarbonMessage. CarbonMessage will represent the request and response messages, irrespective of the underlying transport technology.

Spring support

image01

Spring is a popular framework among developers because it provides a very simple dependency injection (DI) mechanism which makes life easy for developers. We decided to support Spring owing to popular user demand for dependency injection support.

MSF4J now supports a Spring-native programming model. You can now write your MSF4J microservices, Interceptors, ExceptionMappers and configuration as Spring beans and wire them up at runtime.

The standard Spring configuration annotations such as @Component, @AutoWired and other Spring features work with MSF4J, making it easy to bring in other 3rd party libraries and wire them in at runtime. For example, those who are familiar with Spring-JPA can use the Spring-JPA library to integrate the Hibernate ORM framework with a MSF4J service. The Spring sample demonstrates this feature in action.

Swagger support

image00

Swagger is a standard, language-agnostic interface to REST APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.

This feature allows you to add Swagger annotations to your microservices to enrich the Swagger definition of your service. Please note that if Swagger annotations have not been used, the feature will still generate a basic Swagger definition by going through other JAXRS annotations in your service.

The stockquote service example demonstrates Swagger annotations in action. After running that sample, you can retrieve the Swagger definition of the service by going to http://localhost:8080/swagger?path=/stockquote.

javax.ws.rs.ext.ExceptionMapper support

An ExceptionMapper maps a Java exception to an HTTP response that is to be sent back to the invoker of the MSF4J service. This feature allows Java developers to throw business logic exceptions from their MSF4J services, and if there are ExceptionMappers registered to handle such exceptions, the toResponse method in those mappers will be invoked.

image03

Directly returning Java stacktraces to clients is a bad practice. As  a best practice, a properly designed HTTP response which doesn’t expose critical internal implementation details or security details should be returned.

ExceptionMapper allows Java developers to write their code using Java best practices, i.e. throw exceptions when exceptional conditions are encountered, and also follow best practices in service design by not exposing internal details by returning stacktraces.

The stockquote service example demonstrates ExceptionMapper in action.

javax.ws.rs.core.StreamingOutput support

image02

Streaming file download

StreamingOutput gives the developer full control over how the response from your microservice is going to be streamed. You can choose the size of the chunks that are going to be streamed. Depending on the available resources to the JVM, you may select your chunk sizes. For example, smaller chunk sizes will allow you to operate with a lower server side memory footprint. However, note that this may cause the clients to experience higher latencies. The idea is that you can choose a chunk size that is a good tradeoff between memory footprint and latency.

A practical example could be streaming a large file to a client or reading a large number of records from a database and streaming data based on those records.

The FileServer example demonstrates StreamingOutput in action.

FormParam and FormDataParam annotation support

The @FormParam annotation supports HTML form submission with application/x-www-form-urlencoded and multipart/form-data MIME types. The value will be automatically converted to the corresponding parameter type and assigned to that parameter in the MSF4J service operation.

The difference between @FormParam and @FormDataParam is that FormParam can support only Java Strings and primitive types (int, long, Integer, Long etc). The @FormDataParam annotation, on the other hand, can support complex types and Collections, with multipart/form-data content type and support for files along with form field submissions. These can be directly submitted to a MSF4J service and will be handled seamlessly.

The form service sample demonstrates this feature in action.

FormParamIterator

In certain case, a user may want to have full control over the incoming message stream from form submissions, for performance optimization reasons. This can be achieved using the FormParamIterator. When a FormParamIterator is declared as the only parameter of your service operation, MSF4J will hand over full control of the stream to you. The FormParamIterator is injected via the @Context annotation.

This feature is demonstrated in the form service sample.

CircuitBreaker support

Nygard’s circuit breaker pattern defines that rather than wasting valuable resources trying to invoke an operation that keeps failing, the system backs off for a period of time, and later tries to see whether the operation that was originally failing works. This is now supported supported in MSF4J using the Netflix Hystrix library.

image04

Circuit breaker lifecycle

In the context of microservices, a typical usage of circuit breakers would be when one microservice calls another or when a microservice calls out to an external system. In such cases, these calls will be wrapped in Hystrix commands which will take care of handling the circuit breaker state management. The circuit breaker parameters can be configured as per the configurations listed athttps://github.com/Netflix/Hystrix/wiki/Configuration.

This feature is demonstrated in the MSF4J circuit breaker sample.

As you can see, we’ve added quite a bit to the second version of MSF4J. Try out MSF4J 2.0 and let us know what you think – it’s free and open source.