You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Senaka Fernando <se...@gmail.com> on 2009/02/21 12:59:05 UTC
[ode-migration] Information Needed
Hi all,
I'm a student seeking a project to work for Google Summer of Code 2009. I'm
interested in working on the ode-migration project proposed on the Summer of
Code 2009 wiki at the Apache Software Foundation. I went through the short
description and also some content which appeared on the pages that were
hyper-linked. I just building the subversion checkout of Apache ODE. Before
start looking into the code, I have a few questions to ask.
1. Is this project aimed at making it possible to represent the process
instances stored as binary streams on the database in XML format so that it
can be exchanged across multiple instances?
2. If so, are you looking forward to a efficient mechanism that can
represent (importer-exporter system) the persistent content (including
process models and instances) in XML format, along with a mechanism that can
move the content between multiple instances?
3. Do you have an infrastructure that is capable of moving similar content
(in XML-format), across multiple instances of ODE?
4. I see the requirement to make it possible to use this mechanism between
different versions of ODE, which suggests an implementation that is
initially abstract (with some basic functionality) and can be extended
depending on the detailed requirements. Am I correct here?
Speaking about me, I'm an undergraduate at the University of Moratuwa, Sri
Lanka, reading for my BSc. in Computer Science and Engineering (presently in
my final year). I have around 3+ year experience in Java, XML and Web
Service technologies. I have worked on implementing REST support and http
authentication on Apache Axis2/C, [1], which is a part of the Apache Web
Services Project where I'm a committer. I have hands on experience working
with Apache Axis2, [2], Apache Synapse, [3], WSO2 Carbon, [4], WSO2
Enterprise Service Bus, [5] and WSO2 Business Process Server, [6]. I'm also
a committer to the new Stonehenge project at the Apache Software Foundation,
[7].
I'm currently involved in research on Complex Event Processing and Event
Stream Processing, Event Driven Architecture and SOA, and am at present
working on my final year research project SCI-Flex, [8] which is aimed at
the flexible integration of Complex Event Processing and Service Oriented
Architecture.
[1] http://ws.apache.org/axis2/c/
[2] http://ws.apache.org/axis2/
[3] http://synapse.apache.org/
[4] http://wso2.org/projects/carbon
[5] http://wso2.org/projects/esb/java
[6] http://wso2.org/projects/bps
[7] http://incubator.apache.org/stonehenge/
[8] http://sci-flex.org/
Looking forward to your favorable response.
Regards,
Senaka
Dept. of Computer Science and Engineering,
Faculty of Engineering,
University of Moratuwa,
Sri Lanka
Re: [ode-migration] Information Needed
Posted by Senaka Fernando <se...@gmail.com>.
Hi Rafal,
Thanks for the pointer. I will have a look at it. I did go through the link
pointed by Tammo in the JIRA issue and also am hoping to read on [1].
[1]
http://www.uni-ulm.de/en/in/institute-of-databases-and-information-systems/research/projects/adept2.html
Regards,
Senaka
On Wed, Feb 25, 2009 at 2:22 AM, Rafal Rusin <ra...@gmail.com> wrote:
> 2009/2/24 Alex Boisvert <bo...@intalio.com>:
> > On Sat, Feb 21, 2009 at 3:59 AM, Senaka Fernando <senakafdo@gmail.com
> >wrote:
> >
> >> I'm a student seeking a project to work for Google Summer of Code 2009.
> I'm
> >> interested in working on the ode-migration project proposed on the
> Summer
> >> of
> >> Code 2009 wiki at the Apache Software Foundation. I went through the
> short
> >> description and also some content which appeared on the pages that were
> >> hyper-linked. I just building the subversion checkout of Apache ODE.
> Before
> >> start looking into the code, I have a few questions to ask.
> >>
> >> 1. Is this project aimed at making it possible to represent the process
> >> instances stored as binary streams on the database in XML format so that
> it
> >> can be exchanged across multiple instances?
> >
> >
> > Generally speaking, it opens up a slew of opportunities for hacking
> process
> > instance data. I think the main business driver would be migrating
> existing
> > instances to newer version of a process definition.
>
> Speaking about this, I've just put an instance replayer code here:
> https://issues.apache.org/jira/browse/ODE-483
>
> I think it's quite good way of handling migration to a newer version
> of process.
> So Fernando, you could take a look at it and maybe use it as some
> source of your work or at least some inspiration.
> The good thing about it is that it will go (in similar shape to
> production), so it's like a needed feature.
>
> Regards,
> --
> Rafał Rusin
> www.mimuw.edu.pl/~rrusin <http://www.mimuw.edu.pl/%7Errusin>
>
Re: [ode-migration] Information Needed
Posted by Alex Boisvert <bo...@intalio.com>.
On Tue, Feb 24, 2009 at 12:52 PM, Rafal Rusin <ra...@gmail.com> wrote:
> 2009/2/24 Alex Boisvert <bo...@intalio.com>:
> > On Sat, Feb 21, 2009 at 3:59 AM, Senaka Fernando <senakafdo@gmail.com
> >wrote:
> >
> >> I'm a student seeking a project to work for Google Summer of Code 2009.
> I'm
> >> interested in working on the ode-migration project proposed on the
> Summer
> >> of
> >> Code 2009 wiki at the Apache Software Foundation. I went through the
> short
> >> description and also some content which appeared on the pages that were
> >> hyper-linked. I just building the subversion checkout of Apache ODE.
> Before
> >> start looking into the code, I have a few questions to ask.
> >>
> >> 1. Is this project aimed at making it possible to represent the process
> >> instances stored as binary streams on the database in XML format so that
> it
> >> can be exchanged across multiple instances?
> >
> >
> > Generally speaking, it opens up a slew of opportunities for hacking
> process
> > instance data. I think the main business driver would be migrating
> existing
> > instances to newer version of a process definition.
>
> Speaking about this, I've just put an instance replayer code here:
> https://issues.apache.org/jira/browse/ODE-483
>
> I think it's quite good way of handling migration to a newer version
> of process.
I like the approach.
alex
Re: [ode-migration] Information Needed
Posted by Rafal Rusin <ra...@gmail.com>.
2009/2/24 Alex Boisvert <bo...@intalio.com>:
> On Sat, Feb 21, 2009 at 3:59 AM, Senaka Fernando <se...@gmail.com>wrote:
>
>> I'm a student seeking a project to work for Google Summer of Code 2009. I'm
>> interested in working on the ode-migration project proposed on the Summer
>> of
>> Code 2009 wiki at the Apache Software Foundation. I went through the short
>> description and also some content which appeared on the pages that were
>> hyper-linked. I just building the subversion checkout of Apache ODE. Before
>> start looking into the code, I have a few questions to ask.
>>
>> 1. Is this project aimed at making it possible to represent the process
>> instances stored as binary streams on the database in XML format so that it
>> can be exchanged across multiple instances?
>
>
> Generally speaking, it opens up a slew of opportunities for hacking process
> instance data. I think the main business driver would be migrating existing
> instances to newer version of a process definition.
Speaking about this, I've just put an instance replayer code here:
https://issues.apache.org/jira/browse/ODE-483
I think it's quite good way of handling migration to a newer version
of process.
So Fernando, you could take a look at it and maybe use it as some
source of your work or at least some inspiration.
The good thing about it is that it will go (in similar shape to
production), so it's like a needed feature.
Regards,
--
Rafał Rusin
www.mimuw.edu.pl/~rrusin
Re: [ode-migration] Information Needed
Posted by Alex Boisvert <bo...@intalio.com>.
On Sat, Feb 21, 2009 at 3:59 AM, Senaka Fernando <se...@gmail.com>wrote:
> I'm a student seeking a project to work for Google Summer of Code 2009. I'm
> interested in working on the ode-migration project proposed on the Summer
> of
> Code 2009 wiki at the Apache Software Foundation. I went through the short
> description and also some content which appeared on the pages that were
> hyper-linked. I just building the subversion checkout of Apache ODE. Before
> start looking into the code, I have a few questions to ask.
>
> 1. Is this project aimed at making it possible to represent the process
> instances stored as binary streams on the database in XML format so that it
> can be exchanged across multiple instances?
Generally speaking, it opens up a slew of opportunities for hacking process
instance data. I think the main business driver would be migrating existing
instances to newer version of a process definition.
2. If so, are you looking forward to a efficient mechanism that can
> represent (importer-exporter system) the persistent content (including
> process models and instances) in XML format, along with a mechanism that
> can
> move the content between multiple instances?
Import-Export, yes.
3. Do you have an infrastructure that is capable of moving similar content
> (in XML-format), across multiple instances of ODE?
Not currently.
4. I see the requirement to make it possible to use this mechanism between
> different versions of ODE, which suggests an implementation that is
> initially abstract (with some basic functionality) and can be extended
> depending on the detailed requirements. Am I correct here?
I think it implies that there would be various versions of the serialization
format, or a single serialization format that accommodates data from
different versions of the BPEL object model. I think whether the base is
abstract or not is more of an implementation concern.
alex
Re: [ode-migration] Information Needed
Posted by Senaka Fernando <se...@gmail.com>.
Hi Alex, Tammo,
Thanks for the replies.
So I guess, we'll be first need to identify the exact mapping from the BPEL
spec to a representation of a process instance in ODE across multiple
versions, and thereby identify what's common to all, and what changes exist
between multiple versions. Also, when creating the XML representation, IMHO
we can make use of two strategies:
1. Create a universal XML format (which is as generic as possible) that is
capable of working with multiple versions of ODE.
2. Create an XML format per version of ODE, and derive mappings from XML
format A to XML format B. And if you need to work with multiple versions of
ODE you need to apply a format translation.
As we have discussed so far, and according to what I read in the project
detail, it seems that we need something similar to option 1 above (I believe
that I'm correct here). But, I also would like to know, that if the need to
work with multiple versions of ODE is lesser when compared to the need of
working with the same version of ODE, would option 2 be possible as well?
And, as mentioned I will focus primarily on robustness, and then work
towards making it efficient. Regarding the abstract base, yes it can vary
according to the implementation.
Also, by the way, I tried building two versions of ODE, from [1], and [2].
For me, [1] built successfully but not [2]. I will post to the list shortly
about a few issues I had with [2].
Therefore, during the initial stages, am I to focus on an implementation for
[1]?
[1] http://svn.apache.org/repos/asf/ode/branches/APACHE_ODE_1.X
[2] http://svn.apache.org/repos/asf/ode/trunk
Regards,
Senaka
On Wed, Feb 25, 2009 at 1:39 AM, Tammo van Lessen <tv...@gmail.com>wrote:
> Hi Senaka,
>
> Senaka Fernando wrote:
> > 1. Is this project aimed at making it possible to represent the process
> > instances stored as binary streams on the database in XML format so that
> it
> > can be exchanged across multiple instances?
>
> Exactly, but in various flavors. One scenario could be to extract a
> certain number of processes, together will all running process instances
> from one node (ODE version X) and move it to another node (running the
> same version X). Another scenario could be to move it to version X' or
> even to version Y. That's why the binary format is not sufficient as the
> internal object structure may change from version to version. Since the
> underlying model is a de-facto standard, the range of possible changes
> is quite limited. Thus, the XML format should be carefully designed to
> be as generic as possible but also as meaningful (in a sense that some
> things are fixed by the BPEL spec and somethings are allowed, like the
> extensibility mechanisms of BPEL) as possible.
>
>
> > 2. If so, are you looking forward to a efficient mechanism that can
> > represent (importer-exporter system) the persistent content (including
> > process models and instances) in XML format, along with a mechanism that
> can
> > move the content between multiple instances?
>
> Efficiency is not the main goal. It should be as robust as possible to
> make migrations between ODE nodes (with the same and/or different
> versions) possible. The easier the better :) I'm also pretty sure that
> researchers are very interested in such an intermediate format, e.g. to
> migrate a running instance of process model X to X' where X' is a
> modified version of X. This opens a can of worms of course, but some
> researchers like worms ;)
>
> Hm, Alex was faster than me, so I'm stopping here since Alex answered
> the rest of your mail already ;) Your vita sounds great, however, at the
> end of the day it's important to submit a compelling application to
> Google/ASF. We're of course happy to assist you in this regard.
>
> Best,
> Tammo
>
> --
> Tammo van Lessen - http://www.taval.de
>
Re: [ode-migration] Information Needed
Posted by Tammo van Lessen <tv...@gmail.com>.
Hi Senaka,
Senaka Fernando wrote:
> 1. Is this project aimed at making it possible to represent the process
> instances stored as binary streams on the database in XML format so that it
> can be exchanged across multiple instances?
Exactly, but in various flavors. One scenario could be to extract a
certain number of processes, together will all running process instances
from one node (ODE version X) and move it to another node (running the
same version X). Another scenario could be to move it to version X' or
even to version Y. That's why the binary format is not sufficient as the
internal object structure may change from version to version. Since the
underlying model is a de-facto standard, the range of possible changes
is quite limited. Thus, the XML format should be carefully designed to
be as generic as possible but also as meaningful (in a sense that some
things are fixed by the BPEL spec and somethings are allowed, like the
extensibility mechanisms of BPEL) as possible.
> 2. If so, are you looking forward to a efficient mechanism that can
> represent (importer-exporter system) the persistent content (including
> process models and instances) in XML format, along with a mechanism that can
> move the content between multiple instances?
Efficiency is not the main goal. It should be as robust as possible to
make migrations between ODE nodes (with the same and/or different
versions) possible. The easier the better :) I'm also pretty sure that
researchers are very interested in such an intermediate format, e.g. to
migrate a running instance of process model X to X' where X' is a
modified version of X. This opens a can of worms of course, but some
researchers like worms ;)
Hm, Alex was faster than me, so I'm stopping here since Alex answered
the rest of your mail already ;) Your vita sounds great, however, at the
end of the day it's important to submit a compelling application to
Google/ASF. We're of course happy to assist you in this regard.
Best,
Tammo
--
Tammo van Lessen - http://www.taval.de