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/library/articles/2013/12/demystifying-wso2-esb-pass-through-transport-part-i/
[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. This also needs to consider the profit margin of the PaaS provider. 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.
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/
[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
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)