This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Skip to end of metadata
  • Created by Former user, last modified by Former user on Feb 26, 2015
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 35 Next »

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/

[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. 

  1. Develop a REST API that has operations a) reportSale(user, item), b) reportView(user, item), c) getRecommendations(user).
  2. 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. 
  3. 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 

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

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:

  1. 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.
  2. Develop a deep learning back-end using Deeplearning4J [2] library. 
  3. 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)

  • No labels