Minutes

This section gather together the minutes of each meeting of the development team. These summaries describe very briefly what has been discussed, which decisions have been taken, what the members' team are doing, have done, or have to do.

Monday, December 6th 2004

Present were:

  • Dr. Eric Dubuis
  • Patric Fornasier
  • Pawel Kowalski (protocol)

Minutes:

  • Mr Dubuis confirms having read bexee project documentation.
  • The length and the contents of the documentation are appropriate. There are some minors corrections to be done
    • Page 5: "Current State" instead "Actual State"
    • Update bexee short description (reference to J2EE)
    • Update Class and Sequence diagrams
    • Update Use Case diagrams
    • DAO description: mention JDO
    • Page 78: "Create a new class..." instead "Create a new file..."
  • Documentation Layout is OK
    • The "Use Case" diagrams are not necessary
    • It is not necessary to work on the layout
  • Consistence of the project documentation is very important for the final project documentation, this is now most important for the documentation.
  • The project team will work on the demo and the project documentation during the last project week.
  • The project has to be submitted as a project CD and printed documentation (2 copies).

Actions to be taken:

  • Finalize project documentationi and the demo
  • Prepare project CD and printed documentation

Next meeting: No next meeting will be held.

Tuesday, November 30th 2004

Present were:

  • Dr. Eric Dubuis
  • Patric Fornasier (protocol)
  • Pawel Kowalski

Minutes:

  • The project coached announced that the thesis need to be turned in as a physical document in two copies. Folders can be announced at the secretary's office at the given time.
  • The team members reported the issues they experienced while working with XML. The team members explained, that there is going to be a limit in that context, as only simple XML-Types will be supported in the bexee version they will submit.
  • The team members reported the issues and difficulties associated with hot-deployment.
  • The team members reported the experiences and insights they had gained about PartnerLinks and WSDL files associated with a BPEL process.
  • The team members reported that there is going to be a restriction, as only one port type can be used in the bexee version they will submit.
  • A talk about Axis and third-party software integration was held among the three people present.
  • P. Fornasier made the suggestion that the team members plan to continue working on the engine core, rather than on fancy demos and will build the demos during the x-mas holidays. The demos will not be part of the thesis marking.
  • The project coached showed full understanding in the points the team members reported and agreed on the remaining actions planned by the team members.

Actions to be taken:

  • Continue working as defined in project schedule

Next meeting: Monday, December 6th 2004

Monday, November 22nd 2004

Present were:

  • Dr. Eric Dubuis
  • Patric Fornasier (protocol)
  • Pawel Kowalski

Minutes:

  • The team members presented their work of the preceding week.
  • P. Kowalski presented how the XML to OO mapping works in bexee. He explained the concepts of Apache Digester, which is used to map the XML structure into objects. He also showed how factories can be used to introduce more control in the creation of object structure.
  • P. Fornasier showed how Axis is integrated into bexee. To further illustrate this, he drew a small sketch of the message flow starting with a user request and ending with the appropriate response back to the user. He also presented the deliverables structure, by explaining what different components are going to be put into the bexee web archive file.
  • The team members stated that the Axis integration had proven to be more time-consuming than expected.
  • The team members requested a feedback regarding the project documentation (web site and pdf) from the project coach.

Actions to be taken:

  • Project coach will send a feedback regarding the project documentation

Next meeting: Tuesday, November 30th 2004

Tuesday, November 16th 2004

Present were:

  • Dr. Thomas Siegrist
  • Dr. Eric Dubuis
  • Patric Fornasier
  • Pawel Kowalski (protocol)

Minutes:

  • Extraordinary minute with the diploma project expert Dr. Thomas Siegrist, the project coach Dr. Eric Dubuis and the project team P. Fornasier and P. Kowalski.
  • The project team members present the bexee project and the BPEL language to the diploma project expert. After this brief presentation, all those present discuss the rationales for the BPEL language, BPEL and Web Services related technologies. The expert advises that this rationale be contained in final project documentation.
  • Final project documentation and all deliverables have to be provided in digital form at the end of the project. Printed documentation must not be delivered to the expert.
  • At the end of the project, the project team will inform the expert and the project coach where all project documents and deliverables can be found.

Actions to be taken:

  • 9.12.2004: email with important information about the project and project document addresses

Next meeting: there will be no next meeting with the diploma project expert and the project team.

Tuesday, November 16th 2004

Present were:

  • Dr. Eric Dubuis
  • Patric Fornasier
  • Pawel Kowalski (protocol)

Minutes:

  • The team members present the work done during the last week:
    • Simple processes consisting of a Receive, synchronous Invoke and a Reply has been created programmatically and executed. The process executed correctly. In this stadium, the bexee engine was not yet integrated with Axis and Tomcat. Neither was the process parsed from a BPEL document, but created programmatically. The work to be done has been divided. P. Fornasier took was assigned the task of integration bexee with Axis and P.Kowalski transforming BPEL documents.
      • In theory, integration with Axis should be very easy, but this task occurred to take longer than foreseen. Integration with Axis is not very well documented and some issues, e.g. programmatically deployment of services in Axis cannot be done in a straight forward way. Once the integration task completed, bexee will be delivered together with Axis. No changes will be inside Axis. This way, it will be possible to replace versions of Axis without recompiling Axis code.
      • Parsing and transforming BPEL documents will be done with Apache Digester [Digester]. This tool is suitable for this task and can be customized in order to fulfil special requirements of BPEL documents parsing. JAXB, XMLBeans have been briefly evaluated but as those techniques are not suitable for bexee, they will not be used.
  • The team and the project coach have discussed other, not yet solved issues:
    • bexee has to provide engine administration means. In order to do so, an administration interface will be provided and deployed in the integrated Axis engine.
    • Deployment of BPEL processes in bexee. The wsdl bindings for the web service interfaces of the deployed BPEL processes have to be made concrete by bexee (the receive activities will manifest as web services). The engine will define a concrete way to call those web services. This concretization will be done at deployment time, as the BPEL processes do not provide concrete invocation information.
  • Presentation of core architectural decisions done by the project team:
    • At the beginning of the project, the project team decided to use a generic homogenous tree to represent BPEL process types. During the first week of realization, this proved not to be useful structure for the modelling of BPEL process types. BPEL process types are now modelled using a heterogeneous tree model.
    • At execution time, BPEL processes will not be processed recursively, but sequentially

Actions to be taken:

  • bexee documentation has to be updated after finishing Axis integration and BPEL document parsing. Especially Axis integration needs to be well documented.
  • Deployment of BPEL processes has to be defined and documented.

Next meeting: Monday, November 22th 2004

Tuesday, November 9th 2004

Present were:

  • Dr. Eric Dubuis
  • Patric Fornasier (protocol)
  • Pawel Kowalski

Minutes:

  • The team members presented the work they had done during the previous week. This included a short presentation of the following items:
    • Solution Description - Function Details
    • Solution Description -Process Modelling
    • System & Software Architecture
    • Unit Test and Clover Reports
  • A discussion was held about possible solutions to prevent a TCP connection from being closed when a synchronous request for a long- running process is being made by a client.
  • Another discussion was held about the multithreading issues with Mozilla that were described in the Function Details document. For both discussions the team came to the conclusion that it should strive for a clean solution at HTTP level (e.g. sending a response like 'Data Not Yet Available').
  • The team members shortly stated what they are currently working on and explained how they want to use Apache Axis for their purposes. This will be done by providing a custom Provider class which will replace the default Axis Provider class.
  • A short explanation was given to the project coach on how to generate the project documentation from the Maven artifacts.
  • The project coach approved the scope and detail of the documentation that had been written so far.
  • The following two appointments were fixed:

    • 16.11.2004 First Visit Expert (Exact time to be announced by project coach)
    • 11.01.2005 10:00 - 11:00 Defence diploma thesis

Actions to be taken:

  • Check HTTP protocol for possible solutions for signaling clients that data might not yet be available for a long-running synchronous process request.
  • Continue working according to project schedule.

Next meeting: Monday, November 15th 2004

Monday, November 1st 2004

Present were:

  • Dr. Eric Dubuis
  • Patric Fornasier (protocol)
  • Pawel Kowalski

Minutes:

  • The team members announced that they are going to use the following approach for the core architecture: The BPEL document will internally be represented as a tree. There is one process controller which incorporates the logic for the various activities and there are n process context objects, one for each process instance.
  • The team members also disclosed that bexee most likely will be built to run in a J2EE web container and not unlike previously assumed in an J2EE application server. This led to the conclusion to use Java Data Objects (JDO) as the persistence mechanism for bexee.
  • P. Kowalski made a comment about what happens when a process can't terminate (e.g. because a link status never evaluates to true). A possible solution two this problem could be two set a time-out or to provide a management function which allows to remove locked processes.
  • The team members agreed on E. Dubuis suggestion that it might be prudent to focus on the most important BPEL activities first (e.g. <receive>, <invoke>, <assign>, etc.) and to consciously leave out less-frequently used BPEL activities (e.g. <pick>)

Actions to be taken:

  • Go through a number of simple examples for the most important BPEL activities.
  • Until the end of the week the project team should have a solid basis and detailed understanding of the core architecture.
  • Get familiar with JDO and check if the file system can be used instead of a DB.

Next meeting: Tuesday, November 9th 2004

Friday, October 29th 2004

Present were:

  • Dr. Eric Dubuis
  • Patric Fornasier
  • Pawel Kowalski (protocol)

Minutes:

  • P. Fornasier and P. Kowalski make a short presentation of the current bexee core model with, i.e. the bexee tree model with ProcessTree and the ProcessController concepts. The tree approach is an exceptional one for this kind of problems, but it seems that it's possible to realise bexee using this approach. During this discussion a number of topics are discussed which have to be evaluated.
  • What happens when a ProcessController receives a message for a Receive element but the process is not processing this element?
    • The message gets lost
    • The message is saved for later processing
    • An error or fault is triggered
  • Investigate the following bexee core model alternatives:
    • There is a process blueprint tree and each process instance has its own data tree.
    • There is one process blueprint tree and n controllers.
    • There is one process blueprint tree, one controller and n contexts. In case of this solution it would be possible to memorize actions taken and the time stamps as events. Each event would have a reference on the corresponding process tree element. In this way it would be possible to reconstruct the whole process tree with its instance specific data.
  • Is it really necessary to use a EJB container for bexee? It would be possible to use a Web container instead. The advantages of a EJB container seem not to be very important for bexee. Its use would only restrict bexee e.g. not to use threads. Investigate this!

Actions to be taken:

  • Prepare graphic representations of the structured BPEL activities, e.g. Switch, While, etc.
  • Investigate the mentioned subjects
  • Play though the simple BPEL cases.

Next meeting: Monday, November 1st 2004

Thursday, October 28th 2004

Present were:

  • Dr. Eric Dubuis
  • Patric Fornasier
  • Pawel Kowalski (protocol)

Minutes:

  • P. Fornasier and P. Kowalski make presentation about the possible core bexee models. As a result the following possibilities are discussed:
    • A tree model, corresponding to the BPEL XML document structure.
    • A flow graph model, corresponding to the BPEL process.
    • A state machine model

Actions to be taken:

  • Investigate core bexee model

Next meeting: Friday, October 29th 2004

Tuesday, October 25th 2004

Present were:

  • Dr. Eric Dubuis
  • Patric Fornasier
  • Pawel Kowalski (protocol)

Minutes:

  • Presentation of the Project Management Documents: Schedule, Organization and Project specification
  • It will be necessary to prioritize functional requirements of the project. An implementation of a BPEL engine is a project of several man years. It will not be possible to implement full functionality of a BPEL engine. The project team has to decide on priorities during the conception and development of the bexee system.
  • The final product will therefore not be a complete BPEL engine, but
    • Running parts of such an engine
    • Test code
    • Documentation
    • etc...

Actions to be taken:

  • Analyze different models for the implementation of the core BPEL engine
  • Architecture proposal as a discussion base.
  • Prioritize bexee functions.

Next meeting: Friday, October 29th 2004

Tuesday 19th October 2004

Present were:

  • Dr. Eric Dubuis
  • Patric Fornasier
  • Pawel Kowalski (protocol)

Minutes:

  • Docbook vs. Maven: After the presentation of Maven in use (http://dptool.sf.net), Mr. Dubuis decided that we may use Maven for the bexee project. We'll incorporate different reports in the bexee project site, e.g. checkstyle, code coverage, metrics, etc.
  • The bexee BPEL Execution Engine will be constructed as a server side J2EE application. Thanks to the existing technical infrastructure of an J2EE Application server we'll be able to concentrate on the essential aspects of the bexee engine. For this project the JBoss J2EE Application server will be used.
  • Base J2EE architectural decisions:
    • Within bexee there exist several Business Process blueprints and for each of those blueprints there may exist different instances. Each user of a Business Process must have access to his own instance of a process. The instances of the Business Processes will be modeled as Entity Beans. It is also possible that each Business Process instance be modeled as different Entity Beans.
    • One possible way to execute the processes is to use the Visitor/Visitable GoF pattern. The Visitor would be used to run through a Business Process. In such a case, it is important that the Visitor contains no data an no information about the process. The whole information about the process and the state as well can be found in the process: The information about the state of the process is included in IVisitable elements.
    • Outbound requests from the Application Server should not take too long. In case of outbound Web Service requests, which may potentially take long periods of time we have to consider asynchronous requests and responses using Message Driven Beans and JMS. It is imaginable to split methods that may take a long time to execute in two parts, a request and a response part.

Actions to be taken:

  • Analyze whether the use of the Visitor Pattern for the execution of the business process is appropriate

Next meeting: Monday, October 25th 2004