In my last post I mentioned activities i have done before coding start in GSoC 2012. Now I am going to draw an image on your mind about my GSoC 2012 project.
you can find
full detailed description here and i have omitted some irrelevant part from original proposal.
Note: Things proposed here may be changed or and not implement all during the implementation. please keep track on my next blog posts to get an idea about current progress about the project.
Project Description:
Background and its usefulness for Airavata community:
Apache Airavata provides a software toolkit for building E-Science gateways in wide spectrum of scientific disciplines. Main design goal of Airavata is to support long running applications and workflows on distributed computational resources using Service Oriented Architecture.
Airavata XBaya workflow system is designed to provide a convenient programming model for scientists/ developers to program their experiments. It provides an interface for composition, execution and monitoring of the workflows and it hides underlying complexity of the middleware platform from users. So developers can easily construct their logic or experiment using XBaya GUI and execute the workflow on Workflow interpreter. Also it allows monitoring execute workflows in synchronous or asynchronous manner. Workflow interpreter can be used as an embedded workflow enactment engine within XBaya GUI or as an interpreter service that may run as a persistent service.
Problem:
But currently Airavata does not contain proper module to debug workflows that are being executed at the server. But there was debugging facility built on XBaya GUI to debug workflows that are being executed at embedded workflow enactment engine within XBaya GUI. This was possible since both XBaya GUI and the embedded workflow interpreter share the same JVM enabling easy communication among the components at java level. It allows to implement debugging functions without doing too much of work.
But using a simple RMI (Remote Method Invocation) mechanism can be used to extend existing XBaya debugging facility to use with Airavata server. But it is not feasible since it cannot achieve language independences of the debugging module. The debugging module should able to work with different debugging clients like XBaya GUI, a Web Client etc.
Because of these limitations and as it is a much required feature, Airavata community has proposed implementing a debugging framework that enables debugging workflows that is executed at the Airavata server. It should be language independent and support remote debugging.
Benefits
Proposed Workflow debugging framework is very similar to normal debugger applications. It allows its user to exercise some degree of control over workflows and to examine them when things go amiss. Some main functionalities of a workflow debugger are,
- Receive workflow execution data, current state data at a particular point during execution of the workflow.
- Setting and removing break points from workflow execution.
- Send commands to manipulate execution life cycle (pause/resume/single step/stop etc.)
- Modify workflow data on the fly.
etc. More details will be discussed under the solution section.
Debugging framework will give following benefits to developers;
- Easy to examine behavior of the workflow, especially when workflow execute in the Airavata server.
- Can identify errors before they manifest themselves at the end of the workflow execution.
- Modify the workflow execution data dynamically.
etc.
Finally debugging framework will help to enhance the usability of the workflow designing and help to increase the productivity of both developer and the system.
Solution
The proposed solution is to create a debugging framework at the Airavata backend. It will contain mainly two components; backend debugging module and debugging client. Once it is implemented, they should be able to do following things.
Functions of the backend debugging module
It will be capable to do following tasks.
- Provides an API to communicate with debugging clients. This API should be intuitive, language independent & support remote debugging.
- Able to communicate with workflow interpreter to retrieve status and data of a workflow which corresponds to a given topic ID.
- Notify the debugging client whenever workflow instance reaches a break point and pause the workflow instance execution.
- Able to control the paused workflow instance execution according to the debugging client’s commands.
Functions of a debugging client
Debugging client can be implemented as a new module or can be integrated into XBaya. However debugging client should be able to do following tasks;
Basic tasks
- Connect with the backend debugging module in Airavata server.
Monitoring Related tasks
- Retrieve current status & node data of a workflow execution for a given topic ID.
Debugging workflows related tasks..
- Placing, modifying and removing break points to nodes for a given topic ID.
- Able to tell Airavata interpreter to execute next node and pause again. This is similar to the single step command in normal debugging.
- Able to tell Airavata interpreter to continue execution from a break point. This is similar to the resume command in normal debugging.
- Able to tell Airavata interpreter to stop the execution of the workflow. This is similar to the stop command in normal debugging.
Implementation:
This is my proposal to implement above discussed solution.
Overall debugging system's architecture
As discussed earlier the system consists of two components; debugging client and backend debugging module. Backend debugging module consists of a web service interface and debugging API.
When a user debugs a workflow using a Debugging client (here XBaya GUI), it accesses the Debugging API through the web service interface and gives instructions to control workflow execution. According to the client’s instructions Debugging API communicates with workflow interpreter to control workflow execution or retrieve/modify workflow execution data. Then Debugging module notifies the debugging client with requested data or status using its web service interface and client will illustrate debug results/ data using debugging client's user interface.
Development of the debugging framework is divided into two main phases. Phase 1 is developing the backend of the debugging module and phase 2 is developing the client side.
First phase
- When considering requirements of backend, following activities can be identified in First phase.
- Adding necessary functions in workflow-interpreter and GFac to support modifying/retrieving node data and to control workflow etc. (if necessary)
- Design and Implementing a debugging module API and supportive functions to pause/ resume/ stop a workflow, notifying client, retrieving data of a node etc.
- Implementing a registry to store break point details, topic IDs, client details etc.
Developing a web service interface for debugging client (XBaya GUI or a web portal) to connect with backend debugging module. This ensures language independence & remote debugging support of the backend of the debugging module.
Designing a simple, robust and language independent backend module gives a huge advantage when developing a debugging client. Also security issues can be addressed using proper design. Thus designing APIs should be properly handled. Also the API should be clearly defined, because it will help someone else trying to implement the missing stuff in future based on the provided API.
Second Phase
The second phase will include developing the client side. Since existing XBaya GUI already has functions to set break points to nodes, start/stop/restart workflows, and monitoring capabilities, it is very straightforward to implement the new debugging client at XBaya GUI. Main advantage that gives to user is the ability to debug workflows either executes in workflow enactment engine within XBaya or remote workflow interpreter by using single workbench.
- When considering requirements of client side, existing XBaya GUI should be modified to support remote debugging module.
- Design and implement new interface to connect with backend debugging module.
- Implement method to call remote debugging functions.
- Do necessary changes for existing debugging system in the XBaya GUI to support new debugging system. For example modify the setting/ removing break points function etc.
- Implement new window like “parameters”, “monitoring” to show debugging information.
- Design and Implement GUI support for “single step”, “resume”, “terminate” debugging functions.
Second phase is a bit challenging section to develop since this involves lots of UI related implementations and testing.
Development Plan
This proposal covers most of the proposed features in the solution section which are discussed on issue. But as a GSOC project there are some constraint to be met. Time constraint will be the main problem when it comes to implementing the above solution.
As you can see it will take much more time and effort to complete all the mentioned tasks from the beginning in phase 1, phase 2 and Testing plan. Therefore following a better development plan will be helpful in complete this GSOC project within the GSOC time frame.
During the Community Bonding Period I would like to prepare the initial requirement specification and identify the basic components of the debugging module (Core) with help from mentor and the community. This requirement specification will contain the identified subtasks of each phase 1 and phase 2 with their priorities and dependencies. Subtasks will be prioritized according to their usefulness for the core debugging system.
In each phase, identified basic subtasks (high priority tasks) will be carried out using initial requirement specification to build the core debugging system. Also Documentation will be maintained. Leave low priority tasks with proper documentation. If necessary they will be implemented as dummy implementations with proper comments/ documentations.
In the event of a low priority feature being recognized as a hindrance to the implementation of a required feature, the blocking feature will be implemented prior to the required feature. Usually a blocker can be identified during the dependency check of the subtask.
The initial requirement specification will be updated during each phase with help from the mentor and the community. This will help in identifying and solving new blockers so that the project requirements can be fulfilled successfully. But any attempts at adding new features late in the development could result in core level changes and changes in the API.
All development needs to be properly documented in such a way that in future someone else can implement the missing components/ features using the produced documentation.
Testing Plan
Testing plan contains unit tests and integration tests. Unit tests will be carried out during both Phase 1 and Phase 2 of the development. It is very important to conduct unit tests at each phase, since they will ensure the functionality of each component and guarantee that they are working properly.
JUnit test cases will be used for automating (with maven support) test cases and checking functionality entirely of new components (eg: debugging API, Web Interface, and Client UI components)
Integration tests will be carried our after the development of the second phase. Integration tests mainly focuses on use cases which are discussed in 5 minute and 10 minute tutorials. They are,
Invoke a simple Web Service by creating a workflow.
Create a simple Web Service for a command-line Echo application. Then invoke the echo service by using a workflow.
Tests will be conducted to cover those two use cases from start to end using debugging features. Finally documenting the debugging steps of the above two use cases in the form of tutorials. Once the debugging module is added into the Airavata code base, those two tutorials can be added into Airavata documentations as well.
