Versions Compared

Old Version 82

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

  Table of ContentsmaxLevel3

Table of Contents
maxLevel3
printablefalse

 

...

 

Proposal 1: Native inbound and connector for IBM MQ 7.5

Description

Currently with WSO2 Enterprise Service Bus recommended way to connect to IBM MQ is using JMS transport. But this has limitations and sometimes gives issues when integrating. 

...

[3] http://mrmalakasilva.blogspot.com/2013/10/connecting-mechanisms-other-than.html

[4] Creating a Third Party Connector and Publishing in WSO2 Connector Store

 

Possible Mentor/s

Malaka Silva

...

Microservice Framework for Java (MSF4J) [1]  is a l ightweight, fast runtime that can host annotation based services, such as JAX-RS in a micro service architecture[2]. Microservices developed using WSO2 MSF4j can start in just a few milliseconds in a Docker container and can easily be added to a Docker image definition.

  MSF4J requires development tooling to make it appealing to the Java Development Community. It requires end-to-end tooling that helps developer to implement a microservice, run and unit-test a microservice in the integrated development environment itself.

Deliverables

  • IntelliJ IDEA Plugin for running a Java Service in MSF4J

  • Eclipse Plugin for running a Java Service in MSF4J

...

  • Java

  • Eclipse plugin development

  • IntelliJ plugin development

References

[1] http://wso2.com/products/microservices-framework-for-java/

[2] http://martinfowler.com/articles/microservices.html

Possible Mentor/s

Dimuthu Leelarathne

...

In Machine Learning, Ensemble learning is a combining of multiple learning algorithms/models to obtain better predictive accuracy  than what could be obtained from a single learning algorithm. Final prediction is done by taking a weighted vote of the predictions of the combined algorithms. Currently WSO2 machine learner does not facilitate this. The main tasks of the project is to:

...

In the real world scenarios, many different types of data are acquired sequentially. Traditional way of waiting for data to be collected and identifying patterns is a one time process. As the new data arrives, these patterns change and the learned patterns need to be evolved accordingly and the decisions based on these models change as well. Concept of machine learning algorithms with streaming data has been emerged under these circumstances.

The idea of incremental learning with streaming data focuses on two objectives:

...

Proposal 13: [ESB/Tooling]  Automated tests for ESB Graphical editor using SWTBot

Description

Currently we do not have automated tests for ESB graphical editor[1] which is a GMF based drag and drop tool to develop ESB configurations. We can use Eclipse SWTBot[2] to implement automated tests for these kind of GMF editors. Idea is to implement an automated test suite to cover graphical functionalities of ESB editor by composing mediation flows which involves Proxy services, APIs, Sequences, Endpoints, mediators and their properties etc.

...

Proposal 14: [ESB/Tooling] Support JSON, CSV, Java, Excel and Web services formats in Data Mapper tool.

Description

Today, enterprise applications use different data formats and different data structures. WSO2 Data Mapper tool can be used to map different data formats/structures between two systems/applications while system integrations. WSO2 Data mapper tool is based on Eclipse GMF and builds graphical input data model and output data model using provided Apache Avro[1] schemas.

Developers can extend Data mapper tool to support any data format by adding a data type transformer to generate Avro schema based on the relevant data format(Eg: JSON, CSV etc). This project is to write data format transformers to transform CSV, JSON, Java, Excel, Web services formats to Avro format. 

Deliverables

  • Components for generating Apache Avro schemas for data formats such as JSON, Java, Excel, Web services.

...

  • Java
  • Knowledge on WSO2 CEP

References

[1]  http://dl.acm.org/citation.cfm?doid=2370816.2370826  

[2]  http://dl.acm.org/citation.cfm?doid=2528412

Possible Mentors

Miyuru Dayarathna (miyurud AT wso2 DOT com)

...

Chathura Ekanayake (chathura AT wso2 DOT com)

 

Proposal 20: [IS]

...

SAML Assertion Query/Request Profile support for WSO2 Identity Server

...

Description

...

Security Assertion Markup Language (SAML) is an

...

Deliverables

  • Making WSO2 Identity Server fully compliant with SCIM 2.0

Skills Needed

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

References

[1] - http://www.simplecloud.info/
[2] - https://tools.ietf.org/html/rfc7643
[3XML based data format for exchanging authentication and authorization data between business entities and it is one of the most widely used open standards to perform browser based single-sign-on. SAML Assertion Query/Request Profile is a profile which defines a protocol for requesting existing assertions by reference or by querying on the basis of a subject and additional statement-specific criteria. 
WSO2 Identity Server supports SAML based single-sign-on in compliance the SAML2 Web Browser SSO profile and the Single Logout Profile. The objective of the project is implement SAML Assertion Query/Request Profile support for Identity Server.
The following documents contain some information which will help to understand the scope of the project.
Introduction to SAML - [1]
SAML web sso and Identity Server - [2]
SAML Assertion Query/Request Profile - [3] (section 6) & [4]
Detailed information about SAML specifications - [5] & [6]

Deliverables

  • SAML Assertion Query/Request Profile support for Identity Server with test automation and documentation.

Skills Needed

  • Java
  • Designing Restful APIs Apache CXF

References

SCIM+APIs

Possible mentors

Omindu Rathnaweera (omindu AT wso2 DOT com) 

Darshana Gunawardana (darshanaAT wso2 DOT com)
Johann Nallathamby (johann AT wso2 DOT com)
 

Proposal 21: [IS] Document Based NoSQL Support for WSO2 Identity Server Database

Description

WSO2 Identity Server out of the box supports LDAP, Microsoft Active Directory and Relational Databases as User Stores. With the fast growth of enterprise level NoSQL databases, it is important to support NoSQL [1] user stores to improve the value that WSO2 Identity Server can deliver to enterprises in terms of user data management.
In order to support NoSQL, It is expected to customize or write a new User Store Manager [2] that supports storing/retrieving data from NoSQL databases.
The database architecture has to be completely redesigned for optimizing the performance of operations. Initially, new document collections can be created for each database table referring the current relational database schema. Some of the document collections can be combined together as embedded documents or new data models [3] should be created for performance improvement considering the following facts.  
- Document size considerations
- Complexity of data structures
- Data Consistency
The performance has to be further improved by creating appropriate indexes. 
Initially the project should be done on MongoDB 3.2 [4] which is a Document based NoSQL database that is widely used [5]. Test automation should be done appropriately as Unit Tests or Integration Tests for all the operations in the userstore manager. 
Based on completion, other Document based databases such as CouchDB, RavenDB can be considered for implementation.

Deliverables

  • Database Architecture Diagrams
  • Custom Userstore Manager
  • Automated Tests
  • Developer documentation
  • Articles/blog posts on using the custom userstore manager

Skills Needed

  • Java
  • Database knowledge and SQL
  • Understanding of NoSQL
  • MongoDB 3.2
  • Using MongoDB with Java [6]
  • Test Automation (Junit, Selenium)

References 

[1] http://www.planetcassandra.org/what-is-nosql/
[2] https://docs.wso2.com/display/IS500/Writing+a+Custom+User+Store+Manager
[3] https://docs.mongodb.org/manual/data-modeling/
[4] https://www.mongodb.com/mongodb-3.2
[5] http://db-engines.com/en/ranking
[6] https://docs.mongodb.org/ecosystem/drivers/java/

Possible mentors

Tharindu Edirisinghe (tharindue SAML+2.0+Web+SSO

Possible mentors

Omindu Rathnaweera (omindu AT wso2 DOT com)  

Darshana Gunawardana (darshanaAT wso2 DOT com)
Johann Nallathamby (johann AT wso2 DOT com)
 

Proposal 21: [IS] Document Based NoSQL Support for WSO2 Identity Server Database

Description

WSO2 Identity Server out of the box supports LDAP, Microsoft Active Directory and Relational Databases as User Stores. With the fast growth of enterprise level NoSQL databases, it is important to support NoSQL [1] user stores to improve the value that WSO2 Identity Server can deliver to enterprises in terms of user data management.
In order to support NoSQL, It is expected to customize or write a new User Store Manager [2] that supports storing/retrieving data from NoSQL databases.
The database architecture has to be completely redesigned for optimizing the performance of operations. Initially, new document collections can be created for each database table referring the current relational database schema. Some of the document collections can be combined together as embedded documents or new data models [3] should be created for performance improvement considering the following facts.  

- Document size considerations
- Complexity of data structures
- Data Consistency

The performance has to be further improved by creating appropriate indexes. 
Initially the project should be done on MongoDB 3.2 [4] which is a Document based NoSQL database that is widely used [5]. Test automation should be done appropriately as Unit Tests or Integration Tests for all the operations in the userstore manager. 
Based on completion, other Document based databases such as CouchDB, RavenDB can be considered for implementation.

Deliverables

  • Database Architecture Diagrams
  • Custom Userstore Manager
  • Automated Tests
  • Developer documentation
  • Articles/blog posts on using the custom userstore manager

Skills Needed

  • Java
  • Database knowledge and SQL
  • Understanding of NoSQL
  • MongoDB 3.2
  • Using MongoDB with Java [6]
  • Test Automation (Junit, Selenium)

References 

[1]  http://www.planetcassandra.org/what-is-nosql/
[2]  https://docs.wso2.com/display/IS500/Writing+a+Custom+User+Store+Manager
[3]  https://docs.mongodb.org/manual/data-modeling/
[4]  https://www.mongodb.com/mongodb-3.2
[5]  http://db-engines.com/en/ranking
[6]  https://docs.mongodb.org/ecosystem/drivers/java/

Possible mentors

Tharindu Edirisinghe (tharindue AT wso2 DOT com)
Darshana Gunawardana (darshana AT wso2 DOT com)
Johann Nallathamby (johann AT wso2 DOT com)

 

Proposal 22: [IS] RESTful Fine Grained Authorization-as-a-Service (AZaaS)

Description

This is to implement “REST Profile of XACML v3.0 Version” specification[1] from OASIS on WSO2 Identity Server[2]. WSO2 Identity Server already have a XACML implementation based on WSO2 Balana engine[3]. Currently the implementation is based on SOAP services. This needs to be accessible in REST manner and integrated to WSO2 Identity Server in this project scope.  

Deliverables

 

  • REST implementation for XACML policy decision point of WSO2 Identity Server
  • Test automation for the implementation
  • Documentation    (For Dev and Users)

Skills Needed

  • Java
  •   Basic understanding of REST and SOAP
  •   Understanding written code

References

[1] - http://docs.oasis-open.org/xacml/xacml-rest/v1.0/xacml-rest-v1.0.html

[2] - http://wso2.com/products/identity-server/  

[3] - https://github.com/wso2/balana

[4] -   Access Control

[5] - http://xacmlinfo.org/category/balana/

[6]- http://pushpalankajaya.blogspot.com/search/label/XACML

Possible mentors

Pushpalanka Jayawardhana (lanka AT wso2 DOT com)
Darshana Gunawardana (darshana AT wso2 DOT com)
Johann Nallathamby (johann AT wso2 DOT com)

 

Proposal 23: [IS] Policy Administration and Delegation Profile for XACML

 

Description 

This is to implement “XACML v3.0 Administration and Delegation Profile” specification[1] from OASIS on WSO2 Identity Server[2]. WSO2 Identity Server already have a XACML implementation based on WSO2 Balana engine[3]. It's policy administration point(PAP) needs to be improved to have authorization and delegation support when defining, modifying XACML policies.

Deliverables  

  • Implementation of XACML policy administration and delegation in WSO2 Identity Server
  • Test automation for the implementation
  • Documentation   (For Dev and Users)
 

Skills Needed  

  • Java
  • Understanding written code
  • Analytical thinking
 

References

 

[1] - http://docs.oasis-open.org/xacml/3.0/administration/v1.0/xacml-3.0-administration-v1.0.html  

[2] -  http://wso2.com/products/identity-server/  

[3] -  https://github.com/wso2/balana

[4] -   Access Control  

[5] - http://xacmlinfo.org/category/balana/

[6]- http://pushpalankajaya.blogspot.com/search/label/XACML


Possible mentors

Pushpalanka Jayawardhana (lanka AT wso2 DOT com)
Darshana Gunawardana (darshana AT wso2 DOT com) 
Johann Nallathamby
(johann AT wso2 DOT com)

 

Proposal 22: [IS] RESTful Fine Grained Authorization-as-a-Service (AZaaS)

Description

This is to implement “REST Profile of XACML v3.0 Version” specification[1] from OASIS on WSO2 Identity Server[2]. WSO2 Identity Server already have a XACML implementation based on WSO2 Balana engine[3]. Currently the implementation is based on SOAP services. This needs to be accessible in REST manner and integrated to WSO2 Identity Server in this project scope. 

Deliverables

 

  • REST implementation for XACML policy decision point of WSO2 Identity Server
  • Test automation for the implementation
  • Documentation  (For Dev and Users)

Skills Needed

  • Java
  •  Basic understanding of REST and SOAP
  •  Understanding written code

References

[1] - http://docs.oasis-open.org/xacml/xacml-rest/v1.0/xacml-rest-v1.0.html

[2] - http://wso2.com/products/identity-server/ 

[3] - https://github.com/wso2/balana

[4] - Access Control

[5] - http://xacmlinfo.org/category/balana/

[6]- http://pushpalankajaya.blogspot.com/search/label/XACML

Possible mentors

Pushpalanka Jayawardhana (lanka AT wso2 DOT com)
Darshana Gunawardana (darshana AT wso2 DOT com)
Johann Nallathamby (johann AT wso2 DOT com)
 

Proposal 23: [IS] Policy Administration and Delegation Profile for XACML

 

Description 

This is to implement “XACML v3.0 Administration and Delegation Profile” specification[1] from OASIS on WSO2 Identity Server[2]. WSO2 Identity Server already have a XACML implementation based on WSO2 Balana engine[3]. It's policy administration point(PAP) needs to be improved to have authorization and delegation support when defining, modifying XACML policies.

Deliverables 

  • Implementation of XACML policy administration and delegation in WSO2 Identity Server
  • Test automation for the implementation
  • Documentation  (For Dev and Users)
 

Skills Needed 

  • Java
  • Understanding written code
  • Analytical thinking
 

References

 

[1] - http://docs.oasis-open.org/xacml/3.0/administration/v1.0/xacml-3.0-administration-v1.0.html 

[2] - http://wso2.com/products/identity-server/ 

[3] - https://github.com/wso2/balana

[4] - Access Control 

[5] - http://xacmlinfo.org/category/balana/

[6]- http://pushpalankajaya.blogspot.com/search/label/XACML

Possible mentors

Pushpalanka Jayawardhana (lanka AT wso2 DOT com)
Darshana Gunawardana (darshana AT wso2 DOT com) 
Johann Nallathamby (johann AT wso2 DOT com)

Proposal 24: [CDMF] [EMM] Device Policy Merging

Description

Existing policy implementation in EMM only supports policy priority order where the applicable highest priority policy is appliedona device.
For exampleif there are two policies as given below (in-order).
1. Disable camera on all android devices
2. Disable wifi on all devices which belong to role "user-group A"
If we take an android device which belongs to a user in user-group A, ideally both policies should be applicable.
But due to the limitations in existing policyimplementationonly the policy 1 will be applied based on priority.
This behaviourshould be changed to merge options (i.e camera disable, wifi disable) in both policies and send as a one applicable policy to the device. 

Deliverables

Extension point for current EMM policy module  

Skills Needed

Essential Java development skills

References

Introduction to WSO2 EMM Policies(johann AT wso2 DOT com)



Proposal 24: [CDMF] [EMM] Device Policy Merging

Description

Existing policy implementation in EMM only supports policy priority order where the applicable highest priority policy is appliedona device.
For exampleif there are two policies as given below (in-order).
1. Disable camera on all android devices
2. Disable wifi on all devices which belong to role "user-group A"

If we take an android device which belongs to a user in user-group A, ideally both policies should be applicable.
But due to the limitations in existing policyimplementationonly the policy 1 will be applied based on priority.
This behaviourshould be changed to merge options (i.e camera disable, wifi disable) in both policies and send as a one applicable policy to the device. 

Deliverables

  • Extension point for current EMM policy module   

Skills Needed

  • Essential Java development skills

References

  1. Introduction to WSO2 EMM Policies
  2. WSO2 Connected Device Management Framework (CDMF) Policy Module Source Repositary

Possible mentors

Prabath Abeysekara ( prabatha@wso2.com )
Geeth Munasinghe (geeth@wso2.com)


Proposal 25: [CDMF] [EMM] Location and Time-based Device Policy Enforcement

Description

WSO2 EMM is periodically monitoring the behavior of enrolled/registered devices using policies.
These policies will be enforced  by administrators to the device with a set of predefined configurations.
Current criteria of policy enforcement is based on device platform, ownership type (BYOD, COPE) and allocated user or role.
   
Enabling policy enforcement of a device based on Location and Time will be two more applicable conditions to the Device.
Enabling the policies to be activated on given time periods and predefined locations is the main objective of this project.  
 

Deliverables

  • Extension point for current EMM policy module with location and time based policy publishing capability

Skills Needed

  • Mobile Application Development skills
  • Web Service Development skills
  • Geo Fencing know-how
  • Essential Java development skills

References

  1. Development of Location Based Services in Mobile Commerce
  2. Next Generation Location Based Services for Mobile Devices

Possible mentors

Kamidu Punchihewa (sachithp@wso2.com)
Prabath Abeysekara ( prabatha@wso2.com )
Geeth Munasinghe (geeth@wso2.com)
Kasun Delgolla (kasund@wso2.com)

   

Proposal 26: [CDMF] Dynamic Server side Policy Enforcement to the Users and Devices

Proposal 25: [CDMF] [EMM] Location and Time-based Device Policy Enforcement

Description

WSO2 EMM is periodically monitoring the behavior of enrolled/registered devices using policies.
These policies will be enforced by administrators to the device with a set of predefined configurations.
Current criteria of policy enforcement is based on device platform, ownership type (BYOD, COPE) and allocated user or role.
  
Enabling policy enforcement of a device based on Location and Time will be two more applicable conditions to the Device.
Enabling the policies to be activated on given time periods and predefined locations is the main objective of this project. 
 

Deliverables

Extension point for current EMM policy module with location and time based policy publishing capability

Skills Needed

  • Mobile Application Development skills
  • Web Service Development skills
    • Geo Fencing know-how

    Description

    This should be a dynamic policy creation and enforcement mechanism based on the functionality of the devices.
    The functionality of the devices should ideally be monitored and matched against a pre-set “rule” enforced via the UI.
    Upon reaching the rule’s triggering point, a dynamically generated policy should be applied and picked up in PDP (Policy Decision Point) [1].
    Subsequent operation attempts pertaining to the policy enforced device must be validated and restrictions must be added according to the policy in action.
     
    Eg: If a device is shaken then restrict the access to users to whom the device is been shared with from 10 am to 11 pm.

    This will trigger and create a policy that will be used for authorization in the key validation service.
    In here the input for the rule will be the sensor data and action triggering will be either group of devices/users that needs be restricted.
    The policy will be triggered while monitoring the sensor stream in CEP [2].
     

    Deliverables

    • A UI to create and map rules and an extension point for the key validation service.

    Skills Needed

    • Essential Java development skills
    • Essential Javascript development skills

    References

    1. WSO2 Connected Device Management Framework (CDMF) Policy Module Source Repositary

    Possible mentors

    Prabath Abeysekara (prabatha@wso2.com)
    Geeth Munasinghe (geeth@wso2.com)
    1. W SO2 Complex Event Processor

    Possible mentors

    Ayyoob Hamza (ayyoob@wso2.com)
    Geeth Munasinghe (geeth@wso2.com)

     

    Proposal 27: [CDMF] Calculate Device Health Status using Analytics and API Calls

    Description

    There should be a common approach to decide the status of the device in CDMF[1], whether it is active or not.
    A possible approach to decide this would be combining the information from the data publishing calls and
    device bound API calls and then this information can be combined to predict the status of the device.
     

    Deliverables

    • An extension point to be created in device communication port such as a tomcat valve and in the event receivers.


    Skills Needed

    • Essential Java development skills

    References

  • Development of Location Based Services in Mobile Commerce
    • Next Generation Location Based Services for Mobile Devices
    Prabath Abeysekara (prabatha@wso2.com)
    Geeth Munasinghe (geeth@wso2
    Ayyoob Hamza (ayyoob@wso2.com)
    Kasun Delgolla ( kasund@wso2.com )

      

    Proposal

    26

    28: [CDMF]

    Dynamic Server side Policy Enforcement to the Users and Devices

    Description

    This should be a dynamic policy creation and enforcement mechanism based on the functionality of the devices.
    The functionality of the devices should ideally be monitored and matched against a pre-set “rule” enforced via the UI.
    Upon reaching the rule’s triggering point, a dynamically generated policy should be applied and picked up in PDP (Policy Decision Point) [1].
    Subsequent operation attempts pertaining to the policy enforced device must be validated and restrictions must be added according to the policy in action.
     
    Eg: If a device is shaken then restrict the access to users to whom the device is been shared with from 10 am to 11 pm.
    This will trigger and create a policy that will be used for authorization in the key validation service.
    In here the input for the rule will be the sensor data and action triggering will be either group of devices/users that needs be restricted.
    The policy will be triggered while monitoring the sensor stream in CEP [2].
     

    Deliverables

    A UI to create and map rules and an extension point for the key validation service

    [IOT] IOT SDK for creating Device Agents

    Description

    An SDK for IOT - Device specific agents to connect to the IoT Server using languages such as C, C++, java, python.
    A subsequent phase would be auto generating code using tooling for agents written in specific languages.

    Eg: arduino, raspberrypi, android, beaglebone, Intel, IOS.
      In addition, through tooling we should enable the capability to decide
    which transport such as MQTT, XMPP, HTTP to be used.
     

    Deliverables

    • An extension point to the device plugin indicating the firmware specific language used for the device in concern.


    Skills Needed

    • Essential Java development skills
    • Essential Javascript Essential  C, C++ and Python development skills

    References

  • WSO2 Connected Device Management Framework (CDMF) Policy Module Source Repositary
    • WSO2 Complex Event Processor

    1. Reference Code generation tools: swagger-codegen

    Possible mentors

    Ayyoob Hamza (ayyoob@wso2.com)
    Geeth Munasinghe (geeth@wso2Shabir Mohamed ( shabir@wso2.com )
    Rasika Perera (rasikap@wso2.com)
     

    Proposal

    27

    29: [

    CDMF] Calculate Device Health Status using Analytics and API Calls

    Description

    There should be a common approach to decide the status of the device in CDMF[1], whether it is active or not.
    A possible approach to decide this would be combining the information from the data publishing calls and
    device bound API calls and then this information can be combined to predict the status of the device.
     

    Deliverables

    An extension point to be created in device communication port such as a tomcat valve and in the event receivers.

    Skills Needed

    Essential Java development skills

    References

    1. WSO2 Connected Device Management Framework (CDMF)

    Possible mentors

    Ayyoob Hamza (ayyoob@wso2.com)
    Kasun Delgolla (kasund@wso2.com)

     

    Proposal 28: [CDMF] [IOT] IOT SDK for creating Device Agents

    Description

    An SDK for IOT - Device specific agents to connect to the IoT Server using languages such as C, C++, java, python.
    A subsequent phase would be auto generating code using tooling for agents written in specific languages.
    Eg: arduino, raspberrypi, android, beaglebone, Intel, IOS.
     In addition, through tooling we should enable the capability to decide
    which transport such as MQTT, XMPP, HTTP to be used.
     

    Deliverables

    An extension point to the device plugin indicating the firmware specific language used for the device in concern.

    Skills Needed

  • Essential Java development skills
    • Essential C, C++ and Python development skills

    References

    1. Reference Code generation tools: swagger-codegen

    Possible mentors

    Ayyoob Hamza (ayyoob@wso2.com)
    Shabir Mohamed (shabir@wso2.com)
    Rasika Perera (rasikap@wso2

    Cloud] Native Cloud Support for Running WSO2 Middleware on Microsoft Azure

    Description

    WSO2 middleware can be deployed on Microsoft Azure either using virtual machines or containers. In this project will focus on Virtual Machine approach as container support is still primitive on Azure (except for running Kubernetes on Azure). To do this we need implement a Carbon Membership Scheme for providing automatic cluster discovery similar to Kubernetes Membership Scheme [1].

    In addition, we need to demonstrate how following areas would work on Microsoft Azure with native Azure features:

    • Auto healing
    • Autoscaling
    • Automatic cluster discovery
    • Dynamic load balancing
    • VM/Container support
    • Multi-tenancy
    • Configuration orchestration
    • Artifact distribution
    • Software update distribution
    • Multi-region/cloud deployments
    • Centralized logging
    • Monitoring
    • Metering

    Deliverables 

    • Carbon Membership Scheme for Microsoft Azure

    • Artifacts needed for deploying WSO2 products on Microsoft Azure

    • A document explaining steps for deploying WSO2 products on Microsoft Azure

    Skills Needed

    • Java development skills

    • Platform as a Service (PaaS) concepts

    • Basic features of WSO2 Carbon (Deployment patterns, clustering)

    References

    1. Kubernetes Membership Scheme

    2. Microsoft Azure

    Possible mentors


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

     

    Proposal

    29

    30: [Cloud] Native Cloud Support for Running WSO2 Middleware on

    Microsoft Azure

    RedHat OpenShift

    Description

    WSO2 middleware can be deployed on Microsoft Azure either using virtual machines or containers. In this project will focus on Virtual Machine approach as container support is still primitive on Azure (except for running Kubernetes on Azure). To do this we RedHat OpenShift with Docker. The latest OpenShift release is built on top of Kubernetes and Docker. We need implement a Carbon Membership Scheme for providing automatic cluster discovery similar to Kubernetes Membership Scheme [1]. 

    In addition, we need to demonstrate how following areas would work on Microsoft Azure with native Azure featuresRedHat OpenShift for running WSO2 Middleware products:

    • Auto healing
    • Autoscaling
    • Automatic cluster discovery
    • Dynamic load balancing
    • VM/Container support
    • Multi-tenancy
    • Configuration orchestration
    • Artifact distribution
    • Software update distribution
    • Multi-region/cloud deployments
    • Centralized logging
    • Monitoring
    • Metering

    Deliverables 

    • Carbon Membership Scheme for Microsoft AzureRedHat OpenShift

    • Artifacts needed for deploying WSO2 products on Microsoft AzureRedHat OpenShift (scripts, JSON/YAML files, etc)

    • A document explaining steps for deploying WSO2 products on Microsoft AzureRedHat OpenShift  

    Skills Needed

    • Java development skills

    • Platform as a Service (PaaS) concepts

    • Basic features of WSO2 Carbon (Deployment patterns, clustering)

    References

    1. Kubernetes Membership Scheme

    2. Microsoft AzureRedHat OpenShift Architecture

    Possible mentors

    Lakmal Warusawithana Isuru Haththotuwa (lakmal isuruh AT wso2.com)
    Imesh Gunaratne Sajith Kariyawasam (imesh sajith AT wso2.com)


     

    Proposal

    30

    31: [

    Cloud] Native Cloud Support for Running WSO2 Middleware on RedHat OpenShift

    Description

    WSO2 middleware can be deployed on RedHat OpenShift with Docker. The latest OpenShift release is built on top of Kubernetes and Docker. We need implement a Carbon Membership Scheme for providing automatic cluster discovery similar to Kubernetes Membership Scheme [1]. 

    In addition, we need to demonstrate how following areas would work on RedHat OpenShift for running WSO2 Middleware products:

    • Auto healing
    • Autoscaling
    • Automatic cluster discovery
    • Dynamic load balancing
    • VM/Container support
    • Multi-tenancy
    • Configuration orchestration
    • Artifact distribution
    • Software update distribution
    • Multi-region/cloud deployments
    • Centralized logging
    • Monitoring
    • Metering

    Deliverables 

    • Carbon Membership Scheme for RedHat OpenShift

    • Artifacts needed for deploying WSO2 products on RedHat OpenShift (scripts, JSON/YAML files, etc)

    • A document explaining steps for deploying WSO2 products on RedHat OpenShift 

    Skills Needed

    • Java development skills

    • Platform as a Service (PaaS) concepts

    • Basic features of WSO2 Carbon (Deployment patterns, clustering)

    References

    1. Kubernetes Membership Scheme

    2. RedHat OpenShift Architecture

    Possible mentors

    Isuru Haththotuwa (isuruh AT wso2.com)
    Sajith Kariyawasam (sajith AT wso2.com)
     

    Proposal 31: [ML] Deployable artefact model for WSO2 Machine Learner

     

    Description

     

    WSO2 Machine Learner provides a user-friendly wizard type interface where you could configure machine learning analyses and generate models. However, we do not have a concept of deployment artefacts, where you could deploy a dataset, project, analysis simply by dropping a file artefact into respective deployment directories. 

    The main tasks of the project is to:

    • Define the architecture
    • Define artefact definitions
    • Implement deployers
    • Refactor ML back-end
     

    After introducing this model;

     
    • We should be able to deploy ML artefacts via a Carbon Application (CApp) - increase the portability 
    • We should be able to build an automated model creation system. i.e. we configure an analysis to run periodically that would pick the latest dataset version and build a new model and deploy it if it's more accurate.
    • We should be able to hot deploy artefacts
      

    Deliverables

     
    • Deployable artefact model for WSO2 Machine Learner.
    • Artefact definition file/s
    • Tests and documentation

     

    Skills Needed

     
    • Basic Machine Learning knowledge
    • Java

     

    References

     

    [1] https://docs.wso2.com/display/ML110/About+Machine+Learner

     

    [2] https://github.com/wso2/product-ml

     

    ML] Deployable artefact model for WSO2 Machine Learner

     

    Description

     

    WSO2 Machine Learner provides a user-friendly wizard type interface where you could configure machine learning analyses and generate models. However, we do not have a concept of deployment artefacts, where you could deploy a dataset, project, analysis simply by dropping a file artefact into respective deployment directories. 

    The main tasks of the project is to:

    • Define the architecture
    • Define artefact definitions
    • Implement deployers
    • Refactor ML back-end
     

    After introducing this model;

     
    • We should be able to deploy ML artefacts via a Carbon Application (CApp) - increase the portability 
    • We should be able to build an automated model creation system. i.e. we configure an analysis to run periodically that would pick the latest dataset version and build a new model and deploy it if it's more accurate.
    • We should be able to hot deploy artefacts
       

    Deliverables

     
    • Deployable artefact model for WSO2 Machine Learner.
    • Artefact definition file/s
    • Tests and documentation

     

    Skills Needed

     
    • Basic Machine Learning knowledge
    • Java

     

    References

     

    [1] https://docs.wso2.com/display/ML110/About+Machine+Learner

     

    [2] https://github.com/wso2/product-ml

     

    [3] https://github.com/wso2/carbon-ml

      
     

    Possible Mentor/s

     

    Supun Sethunga (supuns AT wso2 DOT com)

    Nirmal Fernando (nirmal AT wso2 DOT com)

     

    Proposal 32: [CEP] Visual Query Composer for WSO2 CEP 

    Description

    WSO2 Complex Event Processor is a realtime analytics engine that supports SQL like queries and with WSO2 CEP 4.1 it has the capability of visualizing Siddhi Queries as a graph. Idea of the project is to build a visual query composer for Siddhi language that provides an easy way of constructing the query graph. 

    Composer must be developed with D3 or libraries based on D3 E.g dagre-d3. 

    Deliverable

    Query Visual Composer.

    Skills Needed

    References

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

    [2] http://d3js.org/

    [3] https://github.com/

    wso2

    cpettitt/

    carbon-ml  
     

    dagre-d3

    Possible Mentor/s

     Supun Sethunga (supuns AT

    Suho (suho AT wso2 DOT com)

    Nirmal Fernando

    Mohan (

    nirmal AT

    mohan AT wso2 DOT com)

     

    Proposal

    32

    33:

     

    [

    CEP] Visual Query Composer

    Docker] Integration Test Framework for WSO2

    CEP 

    Dockerfiles 

    Description

    WSO2 Complex Event Processor is a realtime analytics engine that supports SQL like queries and with WSO2 CEP 4.1 it has the capability of visualizing Siddhi Queries as a graph. Idea of the project is to build a visual query composer for Siddhi language that provides an easy way of constructing the query graph. 

    Composer must be developed with D3 or libraries based on D3 E.g dagre-d3. 

    Deliverable

    Query Visual Composer.

    Skills Needed

    References

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

    [2] http://d3js.org/

    [3]

    Create a suitable integration test framework for the WSO2 Dockerfiles repository [1]. A developer working on the WSO2 Dockerfiles repository should be able to locally run the integration test suite to check if there are no regressions introduced by the changes. Additionally, WSO2 is considering the possibility of integrating the same integration test suite with Pull Requests to verify them, and integrating with a Continuous Integration system such as Jenkins. 

    Deliverable

    • An integration test framework and relevant artifacts

    Skills Needed

    • Puppet
    • Docker
    • Scripting
    • Java
    • Maven
    • TestNG

    References

     

    Possible Mentor/s

    Suho

    Chamila (

    suho

    chamilad AT wso2 DOT com)

    Mohan

    Vishanth (

    mohan

    vishanthb AT wso2 DOT com)