Project Proposals for 2015

Proposal 1: Siddhi Process Monitor for WSO2 CEP

Description

A GUI tool to represent and monitor the event flows of Siddhi[1] in WSO2 CEP[2]. This will be a Web based solution which allows users to view the Siddhi Execution Plans and the Streams as a graph, get statistics at each component of the event flow. This will be some thing like the CEP Event flow [3]

Deliverables

A web based graphical representation of the event flow graphs of Siddhi.
Embed monitoring capability to the flow. E.g event flow rate, memory consumption, queue size

Skills Needed

UI/UX skills
APIs
Some knowledge in HTML, js

References

[1] https://github.com/wso2/siddhi

[2] http://wso2.com/products/complex-event-processor/

[3] https://docs.wso2.com/display/CEP400/CEP+Event+Flow

Possible Mentor/s

Suho (suho AT wso2 DOT com), Srinath (srinath AT wso2 DOT com), Mohan (mohan AT wso2 DOT com)

Proposal 2: Siddhi Editor for WSO2 CEP

Description

A GUI text editor for writing Siddhi[1] queries in WSO2 CEP[2]. This will be a web based solution which allows users to write Siddhi Queries which have code highlighting, code completion and showing syntax errors

Deliverables

A web based text editor for Siddhi.
Code highlighting,
Code completion and
Syntax errors highlighting

Skills Needed

UI/UX skills
APIs
Knowledge in HTML, js

References

[1] https://github.com/wso2/siddhi

[2] http://wso2.com/products/complex-event-processor/

Possible Mentor/s

Suho (suho AT wso2 DOT com), Srinath (srinath AT wso2 DOT com), Mohan (mohan AT wso2 DOT com)

Proposal 3: ESB - Netty transport enhancements

Description

In future WSO2 ESB versions, we are planning to include a non-blocking HTTP transport based on Netty. The current implementation of Netty transport only support pass-thru scenarios. The purpose of this project is to expand its capabilities to support content aware scenarios and supporting WebSockets in ESB transport layer. It is also required to do a performance comparison and obtain a signification performance gain in the new implementation.

Deliverables

Netty transport with content aware support
WebSockets support
Performance test results

Skills Needed

Fundamental knowledge on WSO2 ESB message flow, Java NIO and Netty

References

[1] http://netty.io/
[2] http://wso2.com/products/complex-event-processor/

Possible Mentor/s

Isuru Ranawaka ( isurur AT wso2 DOT com)

Kasun Indrasiri (kasun AT wso2 DOT com)

Proposal 4: ESB - JMS 2.0 support for transports and inbound endpoint

Description

Supporting JMS 2.0 in ESB JMS transport and JMS inbound endpoint. This need to be verified with JMS 2.0 specific use cases.

Deliverables

JMS transport with JMS 2.0 support
Inbound Endpoint with JMS 2.0 support
Integration tests with JMS 2.0 specific use cases
Performance test results

Skills Needed

Fundamental knowledge on WSO2 ESB message flow, JMS

References

[1] http://download.oracle.com/otndocs/jcp/jms-2_0-fr-eval-spec/index.html

Possible Mentor/s

Buddhima Wijeweera (buddhima AT wso2 DOT com)

Shafreen Anfar ( shafreen AT wso2 DOT com)

Proposal 5: ESB - AS2 Support

Description

Currently AS2 is the defacto standard for EDI transmission over the internet. AS2 (Applicability Statement 2) is a specification used for secure and reliable transmission of EDI data in Business-to-business (B2B) communication.

At a minimum, B2B commerce requires:

Partners to use common data formats

Secure document delivery, so that only the intended recipient receives the message

Secure document transmission, so that no one can read the document in transit

Non-repudiation, so that the recipient can be sure that a document was actually sent by the claimed sender

Reliable document status, so that a sender knows exactly what has happened to a document

The ability to manage partner relationships, control with who information is shared with, and what kind of information can be shared with different types of partners

The ability to convert data into a form acceptable to the recipient

It is required to add AS2 to the long list of protocols that are already supported by the WSO2 ESB.

Deliverables

Ability to receive AS2 messages from partners to the WSO2 ESB
Send synchronous/asynchronous message delivery notices to partners from the ESB
Send AS2 messages to partners and receive mdns
Trading partner management

Skills Needed

Java, Http, Ability to research

References

[1] http://www.edibasics.com/types-of-edi/edi-via-as2/
[2] http://www.ietf.org/rfc/rfc4130.txt

Possible Mentor/s

Sandamal Weerasinghe ( sandamal AT wso2 DOT com)
Chanaka Fernando (chankaf AT wso2 DOT com)

Proposal 6: AppFactory - Command Line Tool

Description

Build a command line tool to interact with appfactory. This feature target developers who are interested in working on command line interface like git client command for git operation.

As an example,

Create Application, build, branching, get build status, deployment status, build history, health check of the servers, and more wrapping things to get the job easy to developers and the other users.

Deliverable

A command line tool compatible with linux/windows/mac which can perform appfactory related user operations.

Skills Needed

Java, Shell Scripting

References

[1] http://wso2.com/landing/app-factory/
[2] https://docs.wso2.com/display/AF200/WSO2+App+Factory+Documentation

Possible Mentor/s

Anuruddha Premalal ( anuruddha AT wso2 DOT com)
Dimuthu Leelarathne (dimuthul AT wso2 DOT com)

Proposal 7: User-Managed Access (UMA) Profile for OAuth2

Description

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP services, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and HTTP service, or by allowing the third-party application to obtain access on its own behalf.

User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policies.

WSO2 Identity Server is an open standards based Identity and Access Management system. It fully supports the OAuth 2.0 specification and some of its extended profiles such as OpenID Connect, SAML2 Bearer, etc. The objective here is to implement UMA 1.0 support for WSO2 Identity Server by extending the OAuth 2.0 authorization framework implementation.

Deliverables

UMA 1.0 implementation for WSO2 Identity Server, based on WSO2 Carbon platform.

Skills Needed

Java
Designing Restful APIs Apache CXF
Skill to read and understand specifications, and translate it to working code

References

[1] http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol

[2] https://tools.ietf.org/html/rfc6749

Possible Mentor/s

Prabath Siriwardana (prabath AT wso2 DOT com), Johann Nallathamby (johann AT wso2 DOT com), Dulanja Liyanage (dulanja AT wso2 DOT com)

Proposal 8: WSO2 CEP Based Throttling for API Manager

Description

Currently API throttling in the WSO2 API Manager is handled via an in-house built component. This has its limitations since it can only process standard throttling policies such as throttling by request count and time frame, throttling by IP address or IP range, etc.

Offloading the throttling decision to CEP would enable to dynamically define throttling polices as siddhi queries. This enables us to support many more throttling scenarios and makes it easier to configure notifications, alerts, etc as well. It also makes distributed throttling easier to handle. For example, today the API Manager keeps the throttle counts in a shared cache. When there are a cluster of API Gateways, this shared cache is read from/written to by all nodes in the cluster. By bringing in CEP, the throttle decision is made by solely by CEP and hence reduces complexities.

Deliverables

A new throttling handler for the WSO2 API Gateway.
A set of default throttling policies (as siddhi queries) to be deployed on CEP

Skills Needed

Java
Some knowledge on CEP/Siddhi
Some knowledge on WSO2 API Manager and its throttling capabilities.

References

[1] https://github.com/wso2/siddhi

[2] https://docs.wso2.com/display/AM170/Managing+Throttling+Tiers

[3] https://docs.wso2.com/display/AM170/Adding+New+Throttling+Tiers

[4] https://docs.wso2.com/display/CEP310/Siddhi+Language+Specification

Possible Mentor/s

Nuwan Dias (nuwand AT wso2 DOT com), Amila De Silva (amilad AT wso2 DOT com), Suho (suho AT wso2 DOT com), Mohan (mohan AT wso2 DOT com)

Proposal 9: Implementing Policy Driven Storage Provisioning for WSO2 SS

Description

The WSO2 Storage Server (SS) is an open source, multi-tenanted server for system administrators and developers to easily provision and manage relational databases, NoSQL stores and File systems. In this project it is required to enable users to create storage structures (databases, keyspaces, etc) based on a template-driven model. The main requirement is to allow users to enter values such as capacity and number of instances and thereby make SS provision DB instances accordingly.

Deliverable

Policy Driven storage provisioning module

Skills Needed

Java
RDBMS knowledge
C++ basic knowledge

Possible Mentor/s

Prabath Abeysekara
Deependra Ariyadewa
Dhanuka Ranasinghe

Proposal 10: Google Wallet based Billing System for WSO2 Private PaaS

Description

The Private PaaS is an open source Platform as a Service (PaaS) solution implemented on Apache Stratos. It is a multi-tenant, self-service, metered, middleware cloud for complex, enterprise-ready projects. It can be run on Google Compute Engine (GCE), Amazon EC2, OpenStack, CloudStack and Google Kubernetes. Currently WSO2 Private PaaS has a RDBMS which contains cloud service usage information, however it does not have a billing system. In this project it is required to implement a web based billing system which could integrate Google Checkout for generating invoices and making payments for cloud service usage.

As the first step of this project a literature review needs to be done analyzing existing billing models of PaaS solutions and design a billing model. This should be configurable via the Web application according to custom billing requirements. Once the billing model is in place the web application needs to be implemented to generate a detailed invoice based on the Infrastructure as a Service (IaaS) resource usage and PaaS service usage. Finally an aggregated invoice needs to be generated for the cloud user. PaaS administrator should be able to login to the billing system and view detailed billing information of each PaaS user.

Steps to Follow

Do a literature review on billing patterns of cloud services
Do a literature review on existing open source billing systems
Find information on Google Wallet API
Find information on WSO2 Private PaaS usage data model
Prepare a project proposal with the above information and share it with the mentor
Use WSO2 Dev mailing list for the communication

Deliverables

A web application that can integrate Google Wallet for generating Invoices for cloud usage.

Skills Needed

Java
Web services
SQL

Possible Mentor/s

Imesh Gunaratne (imesh AT wso2 DOT com)
Lakmal Warusawithana (lakmal AT wso2 DOT com)

References

[1] http://wso2.com/cloud/private-paas/

[2] http://stratos.apache.org

[3] https://www.google.com/wallet/

Proposal 11: Recommendation Solution for WSO2 Machine Learner

Description

WSO2 Machine Learner is a Machine Learning Server. Recommendations systems takes item sales and item views as input and recommend items for users based on their interest. (see 1). Goal of this project is to add a recommendation system to WSO2 Machine Learner so that a Retail web site can easily add recommendations support using WSO2 Machine Learner.

Project would involve following steps.

Develop a REST API that has operations a) reportSale(user, item), b) reportView(user, item), c) getRecommendations(user).
Develop a Java Script based client for REST API and set of html code that can be added to a web site just like Google Analytics scripts.
In the REST API, for a) and b) save events to WSO2 Machine Learner. Then use the Spark Recommendation algorithm 2 to make recommendations and expose those results though operation getRecommendations( ..)

When this is done, a retail web site can add the java script code into the site in the same manner as Google analytics scripts and receive recommendations based on the sales and item views.

Deliverables

REST API to report user interactions with the Retail Web Store.
REST API to get recommendations for a given user.
Java script based API client to be used in the Website.
Integrate Spark's recommendation algorithms into ML.

Skills Needed

Java
JAX-RS (can be learned)
Java Script and HTML

Possible Mentor/s

Srinath Perera (srinath AT wso2 DOT com)
Nirmal Fernando (nirmal AT wso2 DOT com)

References

[1] infolab.stanford.edu/~ullman/mmds/ch9.pdf

[2] https://spark.apache.org/docs/latest/mllib-guide.html

Proposal 12: Deep Learning for WSO2 Machine Learner

Description

Deep learning refers to neural networks that consist of more than one hidden layers. Goal of this project is to add a new extension to analytics workflow of WSO2 Machine Learner, so that end users can build deep learning models without going through the details of training deep learning algorithms.

Project consists of following steps:

Develop a Jaggery [1] interface, end-users will use this interface to interact with deep learning algorithms. Interface should includes a) facility to choose algorithms and hyper-parameters b) According to the selected algorithm and hyper-parameters, network architecture should be displayed c) When training, activities of hidden-layers should be inspected via the user interface.
Develop a deep learning back-end using Deeplearning4J [2] library.
Evaluate the performance using few well-known datasets such as MNIST handwritten recognition dataset [3], Caltech 101 [4].

Deliverable

A new extension to the analytics workflow of the WSO2 Machine Learner.

Skills Needed

Machine learning
Java
User interface designing using HTML, JavaScript and d3.js

Possible Mentor/s

Srinath Perera (srinath AT wso2 DOT com)
Nirmal Fernando (nirmal AT wso2 DOT com)
Upul Bandara ( upul AT wso2 DOT com)

References

[1]. http://jaggeryjs.org/
[2]. http://deeplearning4j.org/
[3]. http://yann.lecun.com/exdb/mnist/
[4]. http://www.vision.caltech.edu/Image_Datasets/Caltech101/

Proposal 13: ESB - End-to-end Message Tracing Support

Description

The end-to-end message tracing of message mediation flow need to be implemented based on WSO2 ESB and WSO2 BAM. The project requires changes at ESB core engine level as well as to write a new data publisher to BAM. Also, at BAM level, we need to have the UI level support for tracing the entire message flow with BAM gadgets.

Deliverables

ESB Core engine level support for tracing/dumping the messages
Mediation tracing data agent.
Message Tracing dashboard.

Skills Needed

Fundamental knowledge on WSO2 ESB message flow and WSO2 BAM, hive and Jaggery.

References

[1] https://docs.wso2.com/display/BAM230/User+Guide

Possible Mentor/s

Isuru Udana ( isuruu AT wso2 DOT com)

Kasun Indrasiri (kasun AT wso2 DOT com)

Proposal 14: Integrating nginx to WSO2 App Manager

Description

WSO2 App Manager has several key profiles. Namely, App Store, App Publisher, Identity Provider(IdP) & App Gateway. App Gateway is currently implemented using WSO2 Enterprise Service Bus. This proposal is to integrate nginx as App Gateway in WSO2 App Manager. Main functionalities of App Gateway includes receiving all web application requests, calling Identity Provider (IdP) for authentication requests, applying throttling policies & publishing statistics.

Deliverables

Set of nginx extensions that would convert a standard nginx server into WSO2 App Gateway

Skills Needed

Fundamental knowledge in WSO2 App Manager, WSO2 Enterprise Service Bus & WSO2 Identity Server

References

[1] https://docs.wso2.com/display/APPM100

Possible Mentor/s

Sumedha Rubasinghe (sumedha AT wso2 DOT com)
Dinusha Senanayake (dinusha AT wso2 DOT com)
Ruwan Yatawara (ruwan AT wso2 DOT com)

Proposal 15: Integrating Apache HTTP Server to WSO2 App Manager

Description

WSO2 App Manager has several key profiles. Namely, App Store, App Publisher, Identity Provider(IdP) & App Gateway. App Gateway is currently implemented using WSO2 Enterprise Service Bus. This proposal is to integrate Apache HTTP Server as App Gateway in WSO2 App Manager. Main functionalities of App Gateway includes receiving all web application requests, calling Identity Provider (IdP) for authentication requests, applying throttling policies & publishing statistics.

Deliverables

Set of Apache HTTP Server extensions that would convert a standard Apache HTTP server into WSO2 App Gateway

Skills Needed

Fundamental knowledge in WSO2 App Manager, WSO2 Enterprise Service Bus & WSO2 Identity Server

References

[1] https://docs.wso2.com/display/APPM100

Possible Mentor/s

Sumedha Rubasinghe (sumedha AT wso2 DOT com)
Dinusha Senanayake (dinusha AT wso2 DOT com)
Ruwan Yatawara (ruwan AT wso2 DOT com)

Proposal 16 : Enable selenium testing in Appfactory test stage

Description

Applications created in wso2 appfactory has a testing lifecycle stage. Idea of this project is to facilitate this stage with selenium testing capabilities.

Users should be able trigger the selenium tests against a deployed web application and retrieve the test results. And they will be given with the option to run test either in headless mode or not, depending on the mode; will have to run the test on a compatible server.

Skills Needed

Java, Basic Knowledge in Selenium

References

[1] http://wso2.com/landing/app-factory/

[2] https://docs.wso2.com/display/AF200/WSO2+App+Factory+Documentation

Possible Mentor/s

Anuruddha Premalal ( anuruddha AT wso2 DOT com)

Dimuthu Leelarathne (dimuthul AT wso2 DOT com)

Proposal 17 : Data Wrangler extension for WSO2 Machine Learner

Description

WSO2 Machine Learner is a Server which provides Machine Learning on Big data. Wrangler [1] [2] is an interactive tool for data cleaning and transformation. Goal of this project is to add an extension for WSO2 Machine Learner for interactive data cleaning and transformation using Wrangler.

This project requires to:

Develop a Jaggery [3] user interface to interactively perform tasks (a selected subset of operations) on data cleaning and transformations.
Connect Wrangler with the Jaggery User Interface.
Develop a back-end to convert the scripts generated from Wrangler to Java.

Deliverable

A new extension to the analytics workflow of the WSO2 Machine Learner.

Skills Needed

Java
HTML, JavaScript.

References

[1] http://vis.stanford.edu/wrangler/

[2] https://github.com/StanfordHCI/wrangler

[3] http://jaggeryjs.org/

Possible Mentor/s

Srinath Perera (srinath AT wso2 DOT com)

Nirmal Fernando (nirmal AT wso2 DOT com)

Supun Sethunga (supuns AT wso2 DOT com)

Proposal 18 : Extensible Visual Composer Siddhi Language

Description

WSO2 Complex Event Processor is a relatime analytics engine that support SQL like queries. Idea of the project is to build a visual composer for Siddhi language that provides a palette of operators and let users drag and drop those operators to a canvas and visually compose queries. We will provide a JSON description of operators, and the project involve developing a palette initialised with those operators and develop the canvas for visually composing queries.

Composer must be developed with D3 or libraries based on D3.

Deliverable

Visual Composer.

Skills Needed

HTML, JavaScript.
D3

References

[1] http://wso2.com/products/complex-event-processor/

[2] http://d3js.org/

Possible Mentor/s

Srinath Perera (srinath AT wso2 DOT com)

Suho (suho AT wso2 DOT com)