Final Reports

  1. Patric Fornasier
  2. Pawel Kowalski

Patric Fornasier

Experiences and Difficulties

We are at the end of our diploma thesis and are looking back at two very challenging months of hard work.

Unlike other diploma teams, we didn't have time to prepare the thesis during the summer term, as we both worked on other projects that we finished in summer. Hence we started the project with a bunch of project management documents in the first week, followed by two weeks of intense thinking about how we could actually build what we had in mind.

During that time we gained a lot of insights of how a BPEL engine could work. It was an intellectually very demanding phase, since neither one of us was confronted with similar problems before and sometimes we started doubting, if we'd ever come up with a solution. Now, looking back at the past eight weeks, I think we've made the right decisions and there are no major points that we would do differently if we could start over again.

For me it was also a new and sometimes quite challenging experience to work in a team, where everybody had the same amount of responsibility and competence. This sometimes led to discussions, when we didn't agree on something, and neither one of us wanted to step back or compromise, as both of us were very convinced of their own point of view. Of course this was very good for the project, since delicate decisions where thoroughly discussed, before they were put into action. In general I think we were a very good team with the same ideas about how the project should go and about software development in general. Maybe that's also a reason why we are going to work in the same company next year... ;)

Deviation from the Project Plan

We knew from the very beginning of the project, that we wouldn't be able to fully implement a BPEL engine, as we knew that it took other industry teams ten or more man-years just to build a prototype. However, I think that we also have to admit, that we expected to come a bit further, when we started the project two months ago.

We spent much more time integrating third-party software than we had expected, which delayed the project to some extent. Of course this was unfortunate, as it prevented us from spending more time implementing the engine core, i.e. the process controller.

At the end of the project we decided to leave out fancy demos and interfaces in favor of continuing to work on the engine itself.

Reached Goals

We've built a system that still has a lot of restrictions and limitations, but by deploying and executing actual BPEL processes on it, we've shown that we've realized something that can be used as a base for further developments. A thoroughly worked-out concept and design in the beginning of the project preserved us from having to go back during the implementation phase.

Prospects

I think that BPEL and the entire Web Service technologies are a fascinating area with a big future potential. The development of bexee includes a great number of cutting-edge and state-of the art technologies in modern distributed computing. Hence I'm deeply interested in keeping at it. However, I'm going to start working as a Software Engineer in January, so I'm afraid that there won't be to much time left over for putting into bexee. By making bexee available to the public on SourceForge however, we hope that there might be some interested people, picking up development on bexee and take it a step further.

Pawel Kowalski

The bexee project was very interesting and challenging. Constructing a BPEL engine is certainly not an eight week undertaking, but nevertheless I was very interested and motivated to lay down the cornerstones for a BPEL engine. Even if it wouldn't be possible to construct a somehow complete prototype of a BPEL engine, we would have to consider, design and begin to implement a prospective architecture for such an engine. This was the real challenge for me, to design such an architecture, to implement parts of it and to see whether it works. There's a big difference between just imagening how such an engine might work and actually constructing one that has all the parts fitting together and working. This was really interesting and I'm therefore very content with the outcome of our project.

Deviation from the Project Plan

At the same time, I have to admit that we've underestimated the complexity of such an engine and the efforts needed for the integration of existing software into bexee. When it came to construct our own parts of the software, our estimations were quite accurate, but in the case of integrating external libraries, the estimates were quite poor. It would be necessary to multiply those estimates by at least a factor four. So it happened that we finally were not able to reach the goals we've set. To be concrete, we've planned to construct the bexee engine which would support BPEL CorrelationSets, a cornerstone for the execution of asynchronous processes and complex xml data types in addition to what we've done.

Reached Goals

What the actual bexee engine supports is: synchronous processes with the important basic activities (Receive, Invoke, Assign and Reply) and the almost always needed structured activities (Sequence, Flow, Switch). It is possible to operate on simple xml types.

Yet in spite of the integration problems we've had, it was possible to construct bexee to the point where it is possible to deploy a simple integration process, run it and receive its results. The main architectural decisions we've made, and the important technology choices we've done were right and this was a very important factor for the partial achievement of our goals. It wouldn't be possible to change a strategy during this project, as it only lasted for eight weeks. It paid of that we've spent the first three weeks discussing the possible designs for the construction of the engine and the technology choices about software to be integrated.