Graphical representation generation for a WS-BPEL business process

This blog post is focused on one of my project I contributed to during my internship. This post will also be helpful on who are interested in SVG (Scalable Vector Graphics), BPEL (Business Process Execution Language) and BPM (Business Process Management).

WS-BPEL (Web Services Business Process Execution Language) is XML based programming language used for develop business and scientific work-flows.
It can be used to define Abstract and Executable business processes. Work-flows, implemented in WS-BPEL exchange information by using Web service interfaces.

As previously mentioned WS-BPEL is a XML based language, it does not define a graphical representation for the process or provide any particular design methodology for processes. So there is no any standard graphical notation for WS-BPEL. But most persons find visual notations easier to learn and apply, perhaps because they process visual information more efficiently than textual information, which led some vendors to define their own graphical notations.
The Business Process Modeling Notation (BPMN) is a standardized graphical notation for drawing business processes in a work-flow.

My project was to design and develop a software component that extrapolate the necessary information for displaying a WS-BPEL work-flow instance as an SVG representation. Before get-in to the design phase I researched on the following key-areas.

• Familiarizing with WS-BPEL language, with the existing BPEL-supporting software and with the Web Service stack

• Familiarizing with the SVG libraries and features

• Analyzing the previously done BPMN work-flow and BPEL work-flow viewers and understanding its design and functionalities

• Analyzing how the BPEL process engine can capture instance-related information in terms of work-flow status

The project was targeted on WSO2-BPS and Apache-ODE which are open source Java-based BPEL engines, released under Apache License 2.0.

I used Apache Batik libraries for manipulate SVG documents.
SVG is a XML-based specification to describe two-dimensional vector graphics. SVG is also well-suited to smart phones and mobile devices. All major modern web browsers except Microsoft Internet Explorer support and render SVG markup directly. To view SVG files in Internet Explorer, users have to download and install a browser plug-in.

Final outcome is similar to something like this.



This post is still to be completed and more information on design, the source repository locations and some original screen-shots will be published soon.

My first hands on experiences on Google Summer of Code

This blog post is focused on my Google summer of code project and some tips for folks who are interested in involving with GSoC as students.

GSoC is a annual program held globally that offers student developers stipends(around $4500) to contribute to various open source projects. Historically, the program has brought together over 2,400 students with over 230 open source projects, to create millions of lines of code. Students can get a good exposure to real-world software development scenarios, like distributed development, software licensing, mailing list etiquette, etc.

But having an idea on the above scenarios as early as possible, everything will be a lot more easier in successfully completing the GSoC project.
As there are hundreds of organizations which focus on different aspects, first of all the students need to select a organization based on their preference.
If you are not much familiar with the org. domain you may need to read the articles, tutorials published by the org. As well you need to subscribe to the mailing list or IRC channel for asking more details.
Then you need to come up with an project idea In this case it's much better the ideas comes from the student's side. Then in the mailing list those ideas need to be discussed and get some feedbacks from the org. (Do not worry! Your ideas are not gonna be stolen by others). If there's no feedback for a reasonable time, then reply to that thread with more details.
When discussing on mailing lists there are some etiquette that needed to be concerned. Sometimes the etiquette depends on the org. But there are some common things, anyone needed to understand on open source mailing list etiquette.
Here is an example specific to GSoC went under Apache ODE mailing list.

Open and early communication with the org. will be beneficial for you as all most all the org.s appreciate it.

After that student application period opens. To win a competitive stipend program like the Summer of Code, you'll be competing against an unknown number of people of unknown quality from all over the world. I know you're good, but they're good, too. You need to try to write the best application that the mentor will see. Here mentor is a person from the org. who evaluates the proposals.
The proposal template is depend on the org. If there is a specific template , it will be published on the project site. Normally you need to give a good impression from the proposal that you can successfully completed the project with the given deadline.
Here is my project proposal which became a top voted project proposal in GSoC 2009 for Apache Software foundation.

Normally a project proposal is published as a Wiki page or a on-line document even though it is submitted to the GSoC for evaluations. A good practice is to send the proposal to the mailing list and ask some feedbacks from the mentors for more modifications before submit it to the google.
The mentors will respond to that thread and it will be beneficial in final proposal evaluations.

Be sure to submit your proposal to Google early enough to avoid the unexpected circumstances.

Do not stuck on the GSoC time-line, start and try to contribute to the project as early as possible. When selecting a org. you do not have to wait until Google publishes the accepted orgs. You can count on the orgs which were selected in previous years for GSoC.

In GSoC 2009 time-line it's only 5 days allocated for discussion about project ideas with the orgs. But it is not enough to get an good idea about the project and to write a good proposal. So to write a good proposal students need to discuss the ideas much earlier.

Send some patches on what you have done to the project issue tracker. So that you can mention them on the proposal. Here is an example related to my project.

The proposal evaluation protocol depends on the org. The project proposal need to be changed based on that protocol. So it is essential to be alert on the web sites related to the project, or you can ask those related issues via the mailing list.

After submitting the proposal as well, you need to be so alert on mails, as the mentors may need to communicate with you for more details and sometimes they will ask you to submit a patch to ensure that you are capable of developing the project.

Here you can get more detailed advices for students regarding GSoC.