Here's the IRC chat from today:
[09:01:17] <boisvert> it's 9am PST, should we wait a little to give a
chance for everybody to join?
[09:01:35] <mszefler> sounds like a plan
[09:01:39] <boisvert> say, 5 minutes
[09:02:36] <charper> okay
[09:02:43] <h2o> maybe send a reminder to the list. :)
[09:02:51] <boisvert> ok, will do!
[09:04:03] <boisvert> sent
[09:07:12] <boisvert> there was some confusion
[09:07:26] <boisvert> Matthieu, Paul and Guillaume were on irc.freenode.org
[09:08:02] Join gnodet has joined this channel.
([EMAIL PROTECTED])
[09:09:23] <boisvert> Hi Guillaume!
[09:09:35] <boisvert> We're waiting for Paul and Matthieu I believe
[09:09:45] <boisvert> Cory, do you know if Lance will be attending?
[09:09:47] Join Matthieu has joined this channel. ([EMAIL PROTECTED])
[09:09:54] <charper> yeah, he's coming
[09:10:10] <boisvert> Ok, good, we'll wait
[09:10:26] <Matthieu> I'm here, Lance is coming
[09:11:25] <boisvert> Gentlemen, if you have any specific topics you'd
like to discuss today, please come forward
[09:11:33] <Matthieu> Paul was on freenode as well, I hope he'll follow
but he didn't seem to be reading
[09:11:43] <boisvert> I'll pretend to be the moderator unless somebody
else wants to do the job
[09:11:59] <boisvert> And gather the agenda
[09:12:28] <charper> i know Lance has some topics once he gets here
[09:12:45] <boisvert> Ok
[09:13:10] <boisvert> I was thinking maybe Lance could give an update on
the Process Management API he's been working on
[09:13:27] <boisvert> and maybe we have left over items on the
integration API
[09:14:04] Join LLW has joined this channel.
([EMAIL PROTECTED])
[09:15:50] <charper> Lance we are gathering some topics to discuss today
[09:16:07] <boisvert> Also, Guillaume, Lance or Maciej do you have any
integration API items you want to cover?
[09:16:27] <mszefler> i dont have anything specific, i can give a
general update
[09:16:37] <boisvert> ok, good idea
[09:17:02] <boisvert> So far we have: 1) integration API update, 2)
process management API update
[09:17:23] <LLW> I don't have anything specific either, other than I'm
working on the deployment proposal
[09:17:43] <boisvert> oh yes, i'm sorry i would have said deployment
[09:17:51] <boisvert> Maciej, would you like to start?
[09:17:59] <mszefler> sure.
[09:18:11] <Matthieu> I believe Lance and Cory probably have issues
around the jacob framework too, aren't they?
[09:18:46] <Matthieu> sorry maciej, go ahead
[09:19:00] <boisvert> let's add 3) jacob discussion
[09:19:01] <LLW> I don't really have issues, but I could use some help
coming up to speed
[09:19:40] <mszefler> status: im a bit behind where i wanted to be in
terms of iapi. I did the first refactor, which was based on my original
api proposal. Starting from that I did a second refactor incorporating
the suggestions from the mailing list.
[09:19:44] <mszefler> The key differences were
[09:20:00] <mszefler> a) Bpel engine handles all persistence (IAPI can
be dumb)
[09:20:25] <mszefler> b) provide a more natural mechanism for
synchronous invocations
[09:20:43] <mszefler> correction to (a) -- integration layer (not IAPI)
can be dumb
[09:21:17] <mszefler> im currently trying to get everything working with
the current service framework (i.e. sp-bpel using IAPI)
[09:21:45] <mszefler> and major headache is epr handling, although this
is largely a function of how sfwk works
[09:22:14] <LLW> can we add c) flesh out Context interface - or do you
feel this belongs someplace else?
[09:22:22] <gnodet> cool, will you be able to commit it in svn so
everybody can look at it ?
[09:22:35] <charper> yeah, we would like to try them out on the BPE
[09:22:35] <boisvert> I was just going to ask the same
[09:22:38] <mszefler> yes, ive been meaning to
[09:22:52] <mszefler> i have it commited on svn.intalio.org right now,
[09:23:20] <mszefler> as it is, i need a working environment to make
sure everything actually makes sense
[09:23:39] <mszefler> i will move to the apache svn as soon as iv
eupdated the javadocs
[09:23:41] <boisvert> So maybe you could update on the Ode SVN and send
the changeset link to the mailing list?
[09:24:02] <mszefler> right now the api is pretty unreadable because all
the javadocs are actually wrong
[09:24:43] <mszefler> ok. ill commit to getting that in this weekend
[09:24:50] <mszefler> hell or high water
[09:24:58] <boisvert> Ok, so when you've updated the javadoc, we could
have another round of feedback on the mailing list
[09:25:08] <mszefler> yeah. two items there
[09:25:15] <boisvert> And come back to this topic for the next IRC
[09:25:26] <mszefler> ive had to make some simplification wrt 1)
deployment 2) data abstraction
[09:25:43] <mszefler> (1) is ultimately going to be related to the
deployment proposal
[09:25:59] <LLW> hint taken :)
[09:26:13] <mszefler> (2) requires too much infrastructure, so i punted
[09:27:05] <mszefler> = using DOM
[09:27:41] <boisvert> so maybe this is something that Lance or Guillaume
can take on afterwards?
[09:27:44] <mszefler> yes
[09:27:49] <boisvert> if they want to extend beyond DOM
[09:28:06] <mszefler> there is an abstraction there that will work.
[09:28:24] <LLW> yep - I think Cory or I could take that on since we
have this type of abstraction in the BPE - Cory?
[09:28:37] <charper> yep, i'll sign up for that
[09:29:13] <boisvert> great! thanks for stepping up
[09:29:40] <boisvert> any questions for maciej on iapi?
[09:29:51] <boisvert> or other comments
[09:30:22] <LLW> none from me - I think with his last proposal I have a
pretty good idea of it
[09:30:43] <boisvert> alright, let's move on to 2) deployement API
update -- Lance?
[09:31:19] <LLW> I will shoot to have an initial draft by Thursday.
[09:32:01] <LLW> The only outstanding question from the mailing list has
to do with Maciej's comment on obfuscation
[09:32:33] <mszefler> can you refresh my memory?
[09:33:07] <boisvert> I think it was me who suggested that some people
have a requirement to obfuscate their BPEL code
[09:33:29] <LLW> I think you were proposing that a use case for
compiling BPEL on the client had to do with protecting IP.
[09:33:33] <boisvert> in the sense of deploying a compiled version -- as
opposed to an XML document
[09:33:45] <boisvert> correct
[09:34:14] <boisvert> I was more raising it as a discussion item than an
actual requirement
[09:34:35] <boisvert> I'm fine with not supporting this use-case until
we have people in the community explicitly asking for it
[09:34:45] <LLW> oh - sorry Maciej - I guess it was Alex that raised the
issue
[09:35:17] <LLW> Great - I would propose we hold off that until we get
feedback
[09:35:26] <mszefler> yeah i believe my requirement was that it be
possible to compile without deploying
[09:35:30] <mszefler> for validation purposes
[09:35:54] <LLW> sure - validation makes sense
[09:36:30] <LLW> in that same topic then, I would also like to talk
briefly about the BOM
[09:36:45] <mszefler> yep
[09:37:27] <LLW> I'm still not sure I fully understand why its needed -
and we can't parse directly to OModel
[09:37:58] <mszefler> theres two questions
[09:37:59] <LLW> In looking at the code it appears that most of the
validation is done in the parser
[09:38:12] <mszefler> is it needed as an api
[09:38:17] <mszefler> is the implementation needed
[09:38:35] <mszefler> as an api its not really needed
[09:38:49] <mszefler> as an implementation it makes the compiler a lot
simpler, so in that respect it is needed
[09:39:07] <mszefler> it avoids having to write a 2pass compiler
[09:39:40] <charper> could you explain that a little further?
[09:39:50] <LLW> so when the BOM is "compiled" there is another
validation pass?
[09:39:55] <mszefler> yes
[09:40:02] <mszefler> the parser validation is actually minimal
[09:40:07] <mszefler> it is on the level of schema validation
[09:40:34] <mszefler> the compiler does all the hard validation (making
sure variable types are valid, that references resolve to the correct
things, etc...)
[09:40:55] <mszefler> BOM == DOM | XmlBean in terms of function
[09:41:22] <mszefler> it is simpler to write the compiler using a DOM
than a event stream, that is the whole logic
[09:42:04] <LLW> I see - thanks - I understand
[09:42:41] <mszefler> as i mentioned the only reason bom exists at all
is because of the 2 different bpel versions
[09:42:47] <mszefler> otherwise we'd be using Xmlbeans
[09:43:27] <LLW> right - you are using it to normalize BPEL syntactic
versions
[09:43:39] <mszefler> yes
[09:44:23] <mszefler> it is not possible to get XMLbean to generate a
data model from 2 different schemas
[09:44:27] <mszefler> (as far as i know)
[09:44:59] <mszefler> which makes it hard to reuse code in the compiler
[09:45:39] <LLW> I'm fine with that - I think Guillaume had some concerns?
[09:47:32] <LLW> Guillaume - were your concerns around maintainability?
[09:48:47] <boisvert> Earth to Guillaume (ping!)
[09:49:10] <Matthieu> I think we can ask Guillaume later if he shows up
[09:49:23] <LLW> One thing I think is a bit hard to follow is when new
things like <if> are mapped into <switch> objects.
[09:50:15] <mszefler> yes. that's true
[09:51:00] <mszefler> theres a whole story behind that
[09:51:26] <LLW> time to market :)
[09:51:46] <mszefler> that mod generated quite a bit of heat at the bpeltc
[09:52:02] <mszefler> but...
[09:52:16] <mszefler> it may be easier
[09:52:37] <mszefler> to maintain two separate compilers, one for 1.1
and one for 2.0 with two different xmlbean models as inputs
[09:52:53] <mszefler> 1.1 is not really changing
[09:53:20] <mszefler> and all those little differences add confusion
[09:53:30] <LLW> I understand the desire to prevent ripple - and the
logical equivalence argument
[09:54:35] <mszefler> did we ever dicide if 1.1 is a requirement?
[09:54:45] <LLW> don't want to rehash - just looking for a way to
explain to folks who ask the XML beans question
[09:55:09] <LLW> I would like to continue 1.1 support.
[09:55:25] <boisvert> the two different compiler approach is interesting
[09:55:40] <boisvert> Lance, do you like that idea?
[09:56:17] <LLW> yes - that would have been the route we would have gone
down
[09:56:58] <boisvert> ok, then maybe going forward we should consider
migrating to this approach
[09:58:37] <LLW> sounds good to me
[09:59:10] <boisvert> It's not like anybody desperately wants to do it,
but I think it would be an investment
[09:59:25] <mszefler> this should be relatively simple move, since the
bom objects look like Xmlbeans already
[09:59:27] <boisvert> especially if there's a BPEL revision after 2.0
[09:59:37] <LLW> agreed
[10:00:04] <boisvert> ok, then I think we have a direction
[10:00:39] <LLW> okay - that's all I really had around deployment.
[10:01:01] <boisvert> Good. It's 10am PST already, are we ready to move
to 3) jacob ?
[10:01:34] <Matthieu> seems so
[10:01:51] <LLW> yes - sounds good
[10:02:15] <boisvert> Ok, the floor is open
[10:03:18] <Matthieu> actually isn't Bill going to join us? it seems he
didn't like jacob much
[10:03:20] <LLW> Cory - want to jump in?
[10:03:45] <boisvert> Maybe what would help is to understand areas where
there needs to be more documentation / explanation
[10:04:03] <LLW> I'm not sure Bill will be joining.
[10:04:11] <charper> yes, we are still trying to figure out how the
Jacob engin walks the Omodel
[10:04:33] <boisvert> I have a suggestion
[10:04:50] <boisvert> How about Cory you provide a simple BPEL process
[10:05:02] <boisvert> and maybe Maciej can walk you through the execution?
[10:05:13] <boisvert> Would that help?
[10:05:22] <charper> yes
[10:05:37] <boisvert> I think that would be worthwhile for everybody
[10:05:52] <LLW> It would help me
[10:05:57] <boisvert> In that case, Cory can you think of the example
you'd like to review
[10:06:00] <boisvert> and post it to the mailing list?
[10:06:17] <boisvert> that would give time for Maciej to structure the
explanation
[10:06:30] <boisvert> and we could put this on the wiki
[10:06:54] <boisvert> create some sort of section with BPEL snippets and
walkthroughs
[10:07:13] <LLW> sounds like a great idea to me
[10:07:30] <charper> ok, i'll come up will a few snippets of BPEL
[10:07:33] <boisvert> Ok, let's try that
[10:07:46] <boisvert> Excellent
[10:08:01] <LLW> I would like to ask a couple of hight level question in
the meantime
[10:08:12] <boisvert> Let's hear
[10:08:44] <LLW> does the PXE engine capture history of process execution?
[10:09:06] <mszefler> it saves an event log
[10:09:35] <mszefler> this log can be used to reconstruct the execution
of the process
[10:09:51] <LLW> but not in the instance repository - correct
[10:09:56] <mszefler> correct
[10:10:16] <mszefler> although that would be a cool enhancement (revert
process state)
[10:10:40] <LLW> and many instances share the same process definition
[10:11:11] <boisvert> Some sort of "checkpointing" feature would be nice...
[10:11:33] <mszefler> sure many instances share the same defintion, but
they each save state individually
[10:11:54] <LLW> does the engine cleanup instances at termination?
[10:12:25] <mszefler> it leaves the instance record in the db i believe
[10:12:37] <boisvert> We've been thinking about definiting different
policies about cleanup
[10:13:08] <boisvert> e.g. separate decide if the state/events are kepts
when the process completes or fail
[10:13:14] <boisvert> (separately)
[10:13:35] <h2o> a quick note from the fly on the wall
[10:13:39] <boisvert> This would be a deployment option
[10:13:58] <h2o> I added a simple callback last summer to customize
instance removal on completion
[10:14:09] <boisvert> btw, h2o is Holger
[10:14:32] <h2o> last time I checked the VM storage removed completed
instances while the hibernate-based backend kept the instance in the DB.
[10:14:58] <boisvert> cool, so we have the basic mechanism in place
[10:15:04] Nick h2o is now known as holger.
[10:15:37] <holger> I added this to fix an OOM with stress-testing the
VM store..
[10:15:45] <boisvert> so maybe we could define a standard way to
configure it in the deployment api / contract
[10:16:26] <LLW> yeah - it seems like we ran into deadlock issues when
trying to remove instances in the same transaction that started process
[10:16:43] <LLW> sure - I'll add that in
[10:17:10] <boisvert> how can you remove something that hasn't been
committed yet?
[10:17:36] <mszefler> it just never gets written (in theory)
[10:17:58] <charper> this was in a stateful process, where the process
is stored waiting on a recieve
[10:18:30] <boisvert> ok, i see
[10:18:50] <boisvert> not being sure which version you tried, i'll just
put a disclaimer out there
[10:18:54] Join prb has joined this channel.
([EMAIL PROTECTED])
[10:19:02] <boisvert> we've recently gone through a multitude of
hibernate versions
[10:19:15] <boisvert> that didn't work quite well with HSQL/Derby
cascading deletes
[10:19:30] <boisvert> and therefore the cleanup process was broken for a
while
[10:20:09] <boisvert> the symptom you get if there's a failure during
cleanup is a transaction rollback
[10:20:56] <LLW> one last question - how does the PXE engine lock
instances ( i.e. does it use the DB ) - specifically on correlation?
[10:21:13] <charper> we spent quite a bit of time in the BPE ordering
operation so deadlocks would not occur
[10:21:39] <mszefler> what kind of deadlocks?
[10:22:31] <charper> deadlocks in the DB
[10:23:59] <mszefler> so correlation would use db locking.
[10:24:08] <mszefler> so far we have not had any deadlocking issues
[10:24:28] <charper> yes, the BPE uses the DB for locking
[10:24:45] <mszefler> but the correlation process uses a select to find
the one instance
[10:25:21] <mszefler> that it matches, so in theory it should not create
locks on other instances
[10:25:35] <LLW> sorry - got a bit lost - PXE does use the DB for
instance locking?
[10:25:43] <mszefler> yes, implicitly
[10:25:54] <mszefler> if there are mutliple events for the same instance,
[10:26:01] <charper> we were trying to solve the problme where two
messages are racing towards the same instance
[10:26:38] <mszefler> i see. yes, there is a in-memory lock to prevent
that i believe
[10:26:54] <mszefler> only one thread can process a given instance at a time
[10:26:57] <charper> the BP used DB locks for that as well
[10:28:53] <LLW> for cases where the engine is running distributed -
correct Cory?
[10:29:20] <mszefler> makes sense
[10:29:26] <charper> yes
[10:31:28] <LLW> thanks - that helps clear up some high level questions
I had.
[10:32:17] <boisvert> cool
[10:32:32] <boisvert> last item
[10:32:40] <boisvert> is everybody fine with sending the IRC log to the
mailing list?
[10:32:55] <charper> ok with me
[10:33:04] <Matthieu> for the posterity
[10:33:06] <LLW> fine with me
[10:33:09] Join dims has joined this channel.
([EMAIL PROTECTED])
[10:33:14] <boisvert> i thought we could hang around this channel anytime
[10:33:20] <dims> hi all
[10:33:33] <LLW> sounds good
[10:33:33] <boisvert> but the weekly meeting would be "on the record"
so-to-speak
[10:33:48] <Matthieu> hi dims
[10:33:53] Mode holger gives channel operator privileges to you.
[10:33:57] <boisvert> ok, will send the log on the mailing list
[10:34:02] <boisvert> thanks everybody for attending
[10:34:12] <LLW> thanks
[10:34:18] <boisvert> i think we've covered some ground
[10:34:35] <LLW> agreed
[10:35:07] <boisvert> meeting is officially over but feel free to chat
