Partner Links in simBPEL (was: Easy BPEL aka BPEL4Coders aka BPEL4Hackers)

[Oliver Kopp]

Hi,

 I question if we need to keep partnerLinkType alive?

If we want to have a 1:1 relation of simBPEL to BPEL, then we really need to
keep it.

We think, it is good to have a more easy language, but this should be the
second step. First, there should be a bijective mapping between simBPEL and
BPEL, so that one can freely choose the syntax one likes.

We think that something like simBPEL+ should be born afterwards. There,
language extensions such as your security context and anonymous partner
links could be brought in. Then, the simple syntax is clearly distinguished
from the extensions of BPEL.

 It's a modeling artifact, but if we're not aiming for modeling, 
 do we need the extra indirection?

Isn't the introduction of anonymous partner links a new kind of modeling? In
that case, the modeler has not to think about the concrete partner links.

Cheers,
Olly, Tammo

Syntax of links in simPEL

[Oliver Kopp]

Hi,

We have thought about the syntax of links. As we understand, join and signal
belong to the previous element.

Assume following example:

parallel {
  a;
  b;
  signal(b-to-X);
} and {
  join(b-to-X);
  c;
  d;
} and {
  e;
  signal(e-to-f);
  f;
  join(e-to-f);
}

The link b-to-X connects b and the sequence s2, which contains c and d.
The link e-to-f connects e and f in the sequence s3, which contains e and f.

The link b-to-X is NOT sourcing from sequence s1, which contains a and d.
However, it can be understood like that, because it is the last statement in
the sequence.

The link b-to-X is NOT targeted at c. However, it can be understood as is,
because first links are joined and then an activity is executed. I.e., join
on b-to-X and then execute c. - In the above example both interpretations
lead to the same execution. But if there is a join condition put on the
join(b-to-X), then it is not the same semantics: Assume join(b-to-X,
false()), then in the above example, c and d are both not executed, since
the join condition of the sequence evaluates to false(). If the other
interpretation is assumed, c does not get executed, but d: The sequence is
enabled and only c joins on the incoming links.

We have following different proposals: The syntax is inspired by LaTeX,
where optional arguments can be put in square braces [...]; We do not want
to use additional curly braces {...} to have the links distinguishable of
real arguments.

1. Proposal: Our favorite. Reflecting the execution order.
[join(...)]? activity [signals]?;

parallel {
  a;
  b [signal(b-to-X)];
} and [join(b-to-X)] {
  c;
  d;
} and {
  e [signal(e-to-f)];
  [join(e-to-f)] f;
}

2. Proposal: Everything before the activity.

[join(...)?, signals?]? activity;

parallel {
  a;
  [signal(b-to-X)] b;
} and [join(b-to-X)] {
  c;
  d;
} and {
  [signal(e-to-f)] e;
  [join(e-to-f)] f;
}

3. Proposal: Everything after the activity. (As it is now, but with
brackets).

Activity [join(...)?, signals?]?;

parallel {
  a;
  b [signal(b-to-X)];
} and {
  c;
  d;
} [join(b-to-X)] and {
  e [signal(e-to-f)];
  f [join(e-to-f)];
}

What do you think?

BTW, could we name simPEL simBPEL to enable googling for it? :-) (And
doesn't describe sim(B)PEL *B*usiness Processes? :))

Cheers,

Olly, Tammo

RE: Syntax of links in simPEL

[Oliver Kopp]

Hi Alex,

 However, when I read your explanation, you're interpreting
 everything in terms of links, sourcing and targeting. What we have
 here aren't links, we have a signal construct and a join construct.
 Is it fair to say that signal() is like a BPEL empty with a target,
 and join() is like an empty with a source?

I don't think so:

--cut--
parallel {
  put-pizza-in-oven;
  pizza-cooked;
 signal(diner-ready);
} and {
 join(diner-ready, beer.temperature  10c);
  get-beer-in-fridge;
  drink-beer;
}--edn--

The execution path is from pizza-cooked to get-beer-in-fridge and not the
other way round.

In addition, this doesn't solve the problem of different join semantics.

Viele Grüße,

Olly

RE: Syntax of links in simPEL

[Oliver Kopp]

Hi Matthieu,

 I'm not sure I'm completely following so please forgive me if I'm off
 base and feel free to correct me. My understanding of what you're
 saying is that the way one could understand the snippet above is not
 the way it actually is.

Yes, true.

 Hence it should be fixed because it's ambiguous. Is that right?

Yes, that's right!

 However, when I read your explanation, you're interpreting everything
 in terms of links, sourcing and targeting. What we have here aren't
 links, we have a signal construct and a join construct.

With the same semantics. Only different names. 

--cut: http://ode.apache.org/bpel-simplified-syntax-simbpel.html---
The signal and join instructions are here to model links,
--end--

 Signal says
 when something is done, join says when we should hold until something
 is done. 

This is a semantics different from BPEL!

 So if I just change labels in your example:
 
 parallel {
   put-pizza-in-oven;
   pizza-cooked;
  signal(diner-ready); } and { join(diner-ready, beer.temperature 
  10c);
   get-beer-in-fridge;
   drink-beer;
 }


[quoting from your other mail]
 And if I think in terms of signal and join, it only really makes sense
 if the entire sequence is skipped. And that's what people are used to
 in most imperative languages (somewhat like a specialized break).
 
 Now for the implementation in BPEL (our poor man's bytecode), I can
 think of a few ways to encode that behavior.

How does your example translate to BPEL? And how are you thinking of a
mapping from BPEL to simPEL?

I assume the following: (shortened syntax)

flow
  linksl1/links
  sequence
put-pizza-in-oven;
pizza-cooked sourcesdiner-ready-to-consumption/sources;
  /sequence
  sequence
targetsdiner-ready-to-consumption/targets
repeatUntil
  Determine-beer.temperature;
  conditionbeer.temperature  10c/condition
/repeatUntil
get-beer-in-fridge;
drink-beer;
  /sequence
/flow

I could not use a join conditions, since BPEL only allows links as the only
variables in join conditions.
--cut--
[SA00073] The expression for a join condition MUST be constructed using only
Boolean operators and the activity's incoming links' status values.
--end--

If BPEL had to support that, another expression language for the join
condition has to be used. Even though, that is still a violation of SA00073.
Even BPEL-J does not allow one to put arbitrary Java-code in the join
condition:
--cut--
BPEL only allows the XPath expressions that are within join conditions to
access link status.
The XPath cannot access BPEL variables or any other aspect of the process
state. The same
restriction applies to snippets used within join conditions. The snippets
expressions can only
access the Boolean parameters that represent the status of incoming links.
---end--

 I won't drink my beer as long as the diner's ready and even when it's
 ready, I still won't drink it if it's not freshed. I don't think one
 would expect drink-beer to execute if both conditions aren't satisfied.

That means, your process is stalled as long as the beer isn't cold enough.
That's OK for your example, but it is not in-line with BPEL
dead-path-elimination (DPE) semantics. In contrast to your intended join
semantics, a join in BPEL is evaluated as soon as the status of the incoming
links is clear. If the join evaluates to false, the activity is skipped
(suppressJoinFailure=true). If one does NOT want the activity to be skipped,
but a fault to be thrown, suppressJoinFailure has to be set to false. 

I think, you are aware of that. For those, who read my E-Mail to here and
want to read more on DPE:
Curbera, Francisco; Khalaf, Rania; Leymann, Frank; Weerawarana, Sanjiva:
Exception Handling in the BPEL4WS Language. In: BPM 2003
http://www.springerlink.com/content/yhjyaccdf9g4e0q3/


 Or did I completely misunderstood what you were saying?

We have to runtime semantics in mind: 
I have pure BPEL semantics in mind. And I assume, you have some
BPMN-semantics in mind.


How are you going to implement joins in Apache ODE? How does that affect
BPEL processes? 
Is there a different navigation for simPEL processes?



 Are you afraid of people making too many typos? ;) 

Ah, you're right :)

 Actually without
 writing anything about it we're already number 5 on Google 

Yesterday, I got the same result. Today it was not on the first hundred
results. Maybe I did a typo? ;)

Maybe, simBPEL is the language to use for BPEL semantics and simPEL is
the language for enhanced joins and different execution semantics. :-))


Cheers,

Olly

RE: Syntax of links in simPEL

[Oliver Kopp]

Hi Assaf,

 --cut: http://ode.apache.org/bpel-simplified-syntax-simbpel.html---
 The signal and join instructions are here to model links,
 --end--

 Signal says when something is done, join says when we should hold
 until something is done.
 This is a semantics different from BPEL!

 So if I just change labels in your example:
 
 parallel {
   put-pizza-in-oven;
   pizza-cooked;
  signal(diner-ready); } and { join(diner-ready, beer.temperature 
 10c);
   get-beer-in-fridge;
   drink-beer;
 }
 
 That depends no what the semantics of the beer (or was it speech?)
 condition is.  In terms of blocking, DPEs, etc, there's added
 complexity in handling anything but boolean join expressions.  Joining
 only when the beer gets cold is a tricky proposition.
 
 But joining when dinner is ready, and then reading the variable and
 deciding what to do next, that's easy.  BPEL can do that, but in BPEL
 you'll have, in addition to the join condition, also an if/else
 statement.

What is put in the else statement?

With your reading, the BPEL code of the second sequence of statements in the
above example is

sequence
  if
targetsdiner-ready/targets
condition beer.temperature  10c /condition
get-beer-in-fridge;
  /if
  drink-beer;
/sequence

And if that is translated to simPEL (and no pattern-recognition-magic is
done), it looks like follows:

join(diner-ready);
if (beer.temperature  10c) {
  get-beer-in-fridge;
}
drink-beer;

Or did I get something wrong?


One implication is that the signal statement is bound to the activity before
and join to the activity after.

E.g.:

parallel {
a;
signal(l1);
b;
join(l1);
c;
}
translates to:

flow
 sequence
  a
sourcesl1/sources
  /a
  b
  c
targetsl1/targets
  /c
 /sequence
/flow

 The point of Simpel is to make it easier to write processes.  If we
 insist on one-to-one mapping to BPEL syntax, we're limiting how well it
 can do that, we should be open to syntactic sugars and other
 simplifications.

Syntactic sugar is fine with me. As long as it can be translated to BPEL :).
And that BPEL can be fully translated to simPEL.

I'm currently thinking of simPEL profiles. Such as strict and lax:
strict insits on a (close) 1:1 mapping to BPEL. lax allows all
simplifications... (which may generate a bunch of activities / eventhandlers
/ ... in a mapping to BPEL)

 So whenever I look at an example like this, my first question is:
 would anyone want to do that often enough that it should be considered
 into the syntax?  If not, we have better things to worry about.
 
 If yes, are we taking existing BPEL semantics and applying them in
 more interesting ways, or inventing new semantics?  Inventing new
 semantics has the downside that it takes considerable time, and could
 easily confuse people moving between the two languages.  Doing
 syntactic sugar on top of existing semantics, not that hard.

Fully agree.

 So I'm wondering what part of this is different semantics and what
 part is just syntactic sugar.

Me too. - I think, it depends on whether the usage of arbitrary variables in
join conditions have blocking semantics (as in WS-CDL a blocking workunit)
or not (as the translation to if suggests).

Cheers,

Olly

RE: Syntax of links in simPEL

[Oliver Kopp]

Hi Matthieu,


 Ok, let's see with an example that I hope will be better than the last
 one:
 parrallel {
   a;
   if (...) {
 signal(first);
   } else {
 signal(second);
   }
 } and {
   c;
   join(first);
   d;
 } and {
   join(second);
   e;
 } and {
   join(first, second, $first or $second);
   f;
 } and {
   join(first, second, $first and $second);
   g;
 }

 When reading this code, what I expect is the following:

That's what BPEL does with its links.

 The next step is to see which BPEL translation will comply with those
 expectations. I think this one would work:

Why do you put fault handlers? Why do you add empty activities?
OK, you hae suppressJoinFailure set to no. Then your code is right.

I think in terms of graph-oriented programming. I draw a graph using labeled
nodes and labeled edges. In BPEL, the nodes are activities (with join
conditions) and the edges are links (with transition conditions). I know,
that programmers are not used to graph-oriented programming at all.

Maybe that issue can be solved by introducing the suppressJoinFailure
attribute in simPEL? To have two different kinds of mapping?

According to implications of the suppressJoinFailure attribute in BPEL, it
is IMHO not a matter of optimizing the code. suppressJoinFailure=yes
activates dead-path elimination, which has a huge impact on the evaluation
of transition conditions and thrown faults. If there are container
activities, where suppressJoinFailure is yes and other activities, where
suppressJoinFailure is set to no and links connect activities inside the
container activities, things get even worse. I don't believe that a smart
compiler can just optimize to get the same results (or the BPEL code gets
really ugly)... BPEL introduced the attribute by intention and not by
accident. I don't think one can just ignore that fact. Even if I think, such
an idea is nice. But when thinking of a translation of BPEL to simPEL,
things can get really complicated and not manageable. All in all, I think, a
complete mapping from BPEL to simPEL is a must.

The BPEL code I'd expect is follows:

flow suppressJoinFailure=yes
  links
link name=first/
link name=second/
  /links
  sequence
a/
if
  condition.../condition
  empty
sourcessource linkName=first//sources
  /empty
  else
empty
  sourcessource linkName=second//sources
/empty
  /else
/if
  /sequence

(up to here I agree to translate it to empty. - And now your optimization)

  sequence
c/
d
  targets
joinCondition$first or $second/joinCondition
target linkName=first /
target linkName=second /
  /targets
/d
  /sequence

  e
targets
  joinCondition$second/joinCondition
  target linkName=second /
/targets
  /e  
  
  f
targets
  joinCondition$first or $second/joinCondition
  target linkName=first  /
  target linkName=second /
/targets
  /f  

  g
targets
  joinCondition$first and $second/joinCondition
  target linkName=first  /
  target linkName=second /
/targets
  /g  
/flow


But even that code is bloated.

Having graph-based modeling in mind, I think, the original process should
read as follows:

parrallel {
  a;
  signal(first, ...);
  signal(second, not ...);
} and {
  c;
  join(first);
  d;
} and {
  join(second);
  e;
} and {
  join(first, second, $first or $second);
  f;
} and {
  join(first, second, $first and $second);
  g;
}

And that translates to following code:

flow suppressJoinFailure=yes
  links
link name=first/
link name=second/
  /links

  a
sources
  source linkName=firsttransitionCondition=... //source
  source linkName=secondtransitionCondition=not ... //source
/sources
  /a

(continued as in the above BPEL code)

 There are also cases where the links source and target could be carried by
the preceding, following or
 parent activity instead of creating an empty.

I'd ALWAYS put them to the preceding (signal) and the following (join)
activity.

What situations do you have in mind where such glueing is not possible? Is
it the beginning of a sequence? 

There, following syntax should be allowed:

and join(l1) {
  join(l2);
  c;
  d;
}

That translates to

sequence
  targets
target linkName=l1 /
  /targets
  c
targets
  target linkName=l2 /
/targets
  /c
  d /
/sequence

Cheers,

Olly

RE: GSOC project ideas

[Oliver Kopp]

Hi Denis,

 These days I'm developing a WS-BPEL status tracking tool which
 generate an SVG flow diagram based on the BPEL code,

How does your code relate to
http://blogs.sun.com/toxophily/entry/open_esb_tip_generating_svg
?

 and view the
 instance variable values and the activity details of the running
 instances.

Regarding the display of BPEL-processes:
Oryx is a web-based editor operating on SVG: http://www.oryx-editor.org/

Oryx does also offer the editing of BPEL-files:
http://oryx-editor.org/backend/poem/repository//new?stencilset=/stencilsets/
bpel/bpel.json

(Unfortunately, the current version of the import plugin is not available
there. The layout is smashed. - The version in the trunk is better :))

 I used the ODE Management API for that. But it seems that
 ODE doesn't provide any API for handling breakoints.

We implemented the pluggable framework of Khalaf et al. [1] for Apache ODE
1.1 [2]. This can be used for debugging etc. Maybe it could be an idea to
port the code to the trunk? Furthermore, it should be possible to make this
framework optional in the engine. 

Besides debugging, the use cases for the pluggable framework are following:
 * adaptability [3]
 * split BPEL processes [4] 
 * externalize the transaction behavior of the BPEL engine [5]

1. Khalaf, Rania; Karastoyanova, Dimka; Leymann, Frank: Pluggable Framework
for Enabling the Execution of Extended BPEL Behavior. In: Proceedings of the
3rd International Workshop on Engineering Service-Oriented Application
(WESOA'2007).
2. Steinmetz, Thomas: Ein Event-Modell für WS-BPEL 2.0 und dessen
Realisierung in Apache ODE, Diplomarbeit Nr. 2729, 2008. 
Sorry, this is in German. But the code and the comments are in English :-)
3. Karastoyanova, Dimka; Houspanossian, Alejandro; Cilia, Mariano; Leymann,
Frank; Buchmann, Alejandro P.: Extending BPEL for Run Time Adaptability. In:
Ninth IEEE International Enterprise Computing Conference (EDOC 2005).
4. Khalaf, Rania; Leymann, Frank: Role-based Decomposition of Business
Processes using BPEL. In: International Conference on Web Services (ICWS
2006).
5. Pottinger, Stefan; Mietzner, Ralph; Leymann, Frank: Coordinate BPEL
Scopes and Processes by Extending the WS-Business Activity Framework. In:
Meersman, Robert (ed.); Tari, Zahir (ed.): Proceedings of the 15th
International Conference on Cooperative Information Systems (CoopIS 2007).

Cheers,

Oliver

Extension activities

[Oliver Kopp]

Hi,

In the context of our usage, we rely on BPEL extension activity
support within ODE for enabling the invocation of REST APIs through a
corresponding extension bundle. We therefore ported the extension
activity support from the 2.0-alpha branch (already some years ago and
therefore not up to date with "latest" version on GitHub) into the
current 1.3.7 release build which works. The problem is that by
changing the source code of the official ODE 1.3.7 release, we have to
ship our extended version of ODE and take over responsibilities
regarding licenses, etc. Therefore, it would be really nice if there
will be an ODE 1.3.x release with integrated extension activity
support, so that we can use/refer to ODE as it is and as a result
treat it as a ready to use open source middleware such as Tomcat, we
just use within our ecosystem.

Do you see any chance to release a corresponding distribution that
contains extension activity support in the near future?

In return we are really interested in open sourcing our BPEL4REST
extension bundle so that it can be shipped as a feature with ODE!
‍

Cheers,

Oliver

Sources of dependencies

[Oliver Kopp]

Hi,

We are going to use Apache ODE in a project with involvement of
industry partners. There, we are obliged to proof all (transitive)
dependencies ODE uses, in order to guarantee that all of them apply to
the Apache License Version 2.0. Unfortunately, we were not able to
(automatically) retrieve/find the source code for 15 of the 83
dependencies (from Maven Central) which are packaged into the final
ODE WAR distribution and therefore cannot check what licenses these
dependencies REALLY have:


1.  annogen:annogen:jar:sources:0.1.0

2.  org.apache.derby:derby:jar:sources:10.5.3.0_1

3.  org.apache.derby:derbytools:jar:sources:10.5.3.0_1

4.  tranql:tranql-connector:jar:sources:1.1

5.  
org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:sources:1.0

6.  org.apache.velocity:velocity:jar:sources:1.5

7.  net.sourceforge.serp:serp:jar:sources:1.13.1

8.  org.jibx:jibx-run:jar:sources:1.2.1

9.  commons-primitives:commons-primitives:jar:sources:1.0

10. geronimo-spec:geronimo-spec-jms:jar:sources:1.1-rc4

11. org.apache.santuario:xmlsec:jar:sources:1.4.6

12. org.apache.xmlbeans:xmlbeans:jar:sources:2.6.0

13. org.opensaml:opensaml1:jar:sources:1.1

14. org.apache.axis2:axis2-transports:jar:sources:1.0-i6

15. stax:stax-api:jar:sources:1.0.1


The question is, if someone of the ODE team already has transitively
checked all related licenses of the used dependencies when open
sourcing Apache ODE so that we can rely on your checks?

Otherwise, would it be potentially possible that someone can provide
us the source code for all dependencies bundled within the WAR
distribution of Apache ODE so that we can check them?

Cheers,

Oliver

Re: Sources of dependencies

[Oliver Kopp]

Hi Sathwik,

Thank you for your answer.

> As of Apache ODE source code distribution, we don't ship any third-party
> dependent source along with it nor do we take their source and compile it
> ourself. We only use third-party library in it's binary form and it's
> binary license will be shipped with the ODE binary distribution.

Sure. We understand that Apache has a different OSS process than we have.

In Eclipse terms, as far as I understood, Apache is doing "Type A" (a
license certification for all dependencies). We aim for a Type B Due
Diligence, which additionally provides certification, provenance
check, and code scan for various sorts of anomalies. For that code
scan, we need the source of all dependencies. - For details on type A
and B Wayne has some words:
https://waynebeaton.wordpress.com/2017/01/12/license-certification-due-diligence/

Cheers,

Oliver

Re: Extension activities

[Oliver Kopp]

Hi,


2018-02-01 18:45 GMT+01:00 Sathwik B P :

> I dont have a timeline as of yet. The trunk has lot of changes. We need to
> release the new JACOB implementation. Revisit the clustering implementation
> based on hazelcast. We need to test migrations from 1.3.x versions from
> java serialization to json based serialization. We need to document these.
> All this is sitting on the trunk.
>

Oh, wow, this sounds like much work.

Can't we rethink the release model? I am pretty impressed, what Angular is
doing. They seem to follow "Release early, release often" (
https://en.wikipedia.org/wiki/Release_early,_release_often ) very close and
they are not afraid of getting issue reports.

You are doing an amazing job at Apache ODE. It should be possible that your
work reaches the public very soon: New features and fixes should be
released soon and not be kept hidden for a long time.

I would propose the following:

1. Start using semantic versioning - https://semver.org/
2. Make sure that the each of the points you listed are marked as
openedissue
3. Release ODE 3.0.0 from the trunk straight away. - Reason: A) There was
once ODE 2.x, so that should be skipped. B) It is NOT backward compatible
with ODE 1.x (Jacob-JSON things)
4. Work on the JSON migration from java serialized jacob states to json
based
5. Release ODE 4.0.0, which is then (hopefully) backard-compatible with
1.3.x

Reasoning:

1. The 1.x line can still be maintained as rock-solid engine implementation
for business users
2. Starting from 3.x, ODE is a fast-moving project, which can include
contributions from external fast and also have the possibility to "release
early, release often"

I would also propose to have the "master" branch always release ready: All
tests are green.

WDYT?

Cheers,

Oliver
--
http://github.com/koppor/

Re: Extension activities

[Oliver Kopp]

Hi,

Sorry for being pushy. The thing, I want to know is: What steps need to be
taken to create a release which contains our ported extension activities?
Should we port them to another branch? Are there features which we should
help implementing (Jacob?)?

We need an "official" source + binary of the Apache Foundation of Apache
ODE including support of the extension activities.

It might be possible that an alpha or beta version also works fine. I
think, the correlation between source + binary is also there and it has a
touch of a release. So maybe a beta release of the current state is
possible without much effort from your side? O:-)

Cheers,

Oliver





2018-02-21 13:40 GMT+01:00 Oliver Kopp <kopp@gmail.com>:

> Hi,
>
> I think, it's a chiggen-egg problem.
>
> Why not establish a more modern release-early-release-often cycle to show
> activity to the community? What is hindering a CI pipeline? This could also
> ease jumping in this project.I have experience with CircleCI and Travis if
> that helps.
>
> This could also kick-off a Google Summer-of-Code project somehow?
>
> Cheers,
>
> Oliver
>
> 2018-02-03 5:26 GMT+01:00 Sathwik B P <sathwik...@gmail.com>:
>
>> Hi Oliver,
>>
>> May be, we wait to see for the kind of involvment in the DEV community
>> which justifies the release proposal. Head back to the run up of 1.3.7
>> release on the ODE-1.3.x branch and look for the kind of involvement of
>> devs and also consider the time that these developers spend on
>> contributing
>> to ODE and then probably revisit the release cycles.
>>
>> ODE 1.4 was envisaged to be a major GA release with new features, but due
>> to lack of involvement in the community it has not seen the light of the
>> day. I would encourage developers to take up features/issues on the trunk
>> and fix/test them and share information to the community, so that the PMC
>> can make a sound judgement about releases.
>>
>> We would definitely like to see fresh blood coming into the community.
>>
>> regards,
>> sathwik
>>
>> On Feb 2, 2018 20:27, "Oliver Kopp" <kopp@gmail.com> wrote:
>>
>> Hi,
>>
>>
>> 2018-02-01 18:45 GMT+01:00 Sathwik B P <sathwik...@gmail.com>:
>>
>> > I dont have a timeline as of yet. The trunk has lot of changes. We need
>> to
>> > release the new JACOB implementation. Revisit the clustering
>> implementation
>> > based on hazelcast. We need to test migrations from 1.3.x versions from
>> > java serialization to json based serialization. We need to document
>> these.
>> > All this is sitting on the trunk.
>> >
>>
>> Oh, wow, this sounds like much work.
>>
>> Can't we rethink the release model? I am pretty impressed, what Angular is
>> doing. They seem to follow "Release early, release often" (
>> https://en.wikipedia.org/wiki/Release_early,_release_often ) very close
>> and
>> they are not afraid of getting issue reports.
>>
>> You are doing an amazing job at Apache ODE. It should be possible that
>> your
>> work reaches the public very soon: New features and fixes should be
>> released soon and not be kept hidden for a long time.
>>
>> I would propose the following:
>>
>> 1. Start using semantic versioning - https://semver.org/
>> 2. Make sure that the each of the points you listed are marked as
>> openedissue
>> 3. Release ODE 3.0.0 from the trunk straight away. - Reason: A) There was
>> once ODE 2.x, so that should be skipped. B) It is NOT backward compatible
>> with ODE 1.x (Jacob-JSON things)
>> 4. Work on the JSON migration from java serialized jacob states to json
>> based
>> 5. Release ODE 4.0.0, which is then (hopefully) backard-compatible with
>> 1.3.x
>>
>> Reasoning:
>>
>> 1. The 1.x line can still be maintained as rock-solid engine
>> implementation
>> for business users
>> 2. Starting from 3.x, ODE is a fast-moving project, which can include
>> contributions from external fast and also have the possibility to "release
>> early, release often"
>>
>> I would also propose to have the "master" branch always release ready: All
>> tests are green.
>>
>> WDYT?
>>
>> Cheers,
>>
>> Oliver
>> --
>> http://github.com/koppor/
>>
>
>

Re: Extension activities

[Oliver Kopp]

Hi,

I think, it's a chiggen-egg problem.

Why not establish a more modern release-early-release-often cycle to show
activity to the community? What is hindering a CI pipeline? This could also
ease jumping in this project.I have experience with CircleCI and Travis if
that helps.

This could also kick-off a Google Summer-of-Code project somehow?

Cheers,

Oliver

2018-02-03 5:26 GMT+01:00 Sathwik B P <sathwik...@gmail.com>:

> Hi Oliver,
>
> May be, we wait to see for the kind of involvment in the DEV community
> which justifies the release proposal. Head back to the run up of 1.3.7
> release on the ODE-1.3.x branch and look for the kind of involvement of
> devs and also consider the time that these developers spend on contributing
> to ODE and then probably revisit the release cycles.
>
> ODE 1.4 was envisaged to be a major GA release with new features, but due
> to lack of involvement in the community it has not seen the light of the
> day. I would encourage developers to take up features/issues on the trunk
> and fix/test them and share information to the community, so that the PMC
> can make a sound judgement about releases.
>
> We would definitely like to see fresh blood coming into the community.
>
> regards,
> sathwik
>
> On Feb 2, 2018 20:27, "Oliver Kopp" <kopp@gmail.com> wrote:
>
> Hi,
>
>
> 2018-02-01 18:45 GMT+01:00 Sathwik B P <sathwik...@gmail.com>:
>
> > I dont have a timeline as of yet. The trunk has lot of changes. We need
> to
> > release the new JACOB implementation. Revisit the clustering
> implementation
> > based on hazelcast. We need to test migrations from 1.3.x versions from
> > java serialization to json based serialization. We need to document
> these.
> > All this is sitting on the trunk.
> >
>
> Oh, wow, this sounds like much work.
>
> Can't we rethink the release model? I am pretty impressed, what Angular is
> doing. They seem to follow "Release early, release often" (
> https://en.wikipedia.org/wiki/Release_early,_release_often ) very close
> and
> they are not afraid of getting issue reports.
>
> You are doing an amazing job at Apache ODE. It should be possible that your
> work reaches the public very soon: New features and fixes should be
> released soon and not be kept hidden for a long time.
>
> I would propose the following:
>
> 1. Start using semantic versioning - https://semver.org/
> 2. Make sure that the each of the points you listed are marked as
> openedissue
> 3. Release ODE 3.0.0 from the trunk straight away. - Reason: A) There was
> once ODE 2.x, so that should be skipped. B) It is NOT backward compatible
> with ODE 1.x (Jacob-JSON things)
> 4. Work on the JSON migration from java serialized jacob states to json
> based
> 5. Release ODE 4.0.0, which is then (hopefully) backard-compatible with
> 1.3.x
>
> Reasoning:
>
> 1. The 1.x line can still be maintained as rock-solid engine implementation
> for business users
> 2. Starting from 3.x, ODE is a fast-moving project, which can include
> contributions from external fast and also have the possibility to "release
> early, release often"
>
> I would also propose to have the "master" branch always release ready: All
> tests are green.
>
> WDYT?
>
> Cheers,
>
> Oliver
> --
> http://github.com/koppor/
>

Re: Extension activities

[Oliver Kopp]

Hi,

would an etherpad instance (maybe created using https://pad.riseup.net/)
help to coordinate? Do you have other means "inbetween" issue tracker and
mailinglists in place in the context of Apache ODE?

Cheers,

Oliver


2018-02-23 12:32 GMT+01:00 Sathwik B P :

> Hi Michael,
>
> Just a quick jot down of tasks for JACOB. Migration is another, need to see
> what is missing in JACOB.
>
> JACOB [Release branch (2.0a) - compatible with the ODE trunk branch]
> 
> ---
> 1) Update pom
> -- Upgrade Jackson to latest stable release
> -- JDK 8
> 2) Lookout for patterns in source as indicated in the CVE [
> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jackson].
> 3) Make a new CI build for the 2.0a-JDK 8.
> 4) Run the ODE trunk build to take up latest jacob snapshot.
> 5) Look out for any JACOB open JIRA issues. [
> issues.apache.org/jira/browse/JACOB]
>
> Migrations testing from 1.3.7
> --
> 1) Deploy ODE 1.3.7 with external database [mysql] and any transaction
> manager on TOMCAT or use the Embedded ODE Tomee distro.
> 2) Deploy a prrocess and run an instance of the process.
> 3) Configure the ODE trunk to the same external database. Run database
> migration scripts [need to check if there is any required].
> 4) Do we need to recompile the process binary[.cbp file] to new OModel?
> This is the real thing.
> 5) Complete the running process instance. Runtime processing state
> migration would be tested.
> 6) Create a fresh process instance on the trunk and complete the running
> instance.
> 7) Verify all the exmaple processes in similar fashion.
>
> Lets see how it goes from here.
>
> regards,
> sathwik
>
> On Thu, Feb 22, 2018 at 2:35 PM, Michael Hahn  wrote:
>
> > Hi Sathwik,
> >
> > I could commit to support you with the releasing (new JACOB
> > implementation, ODE) and to help you by taking up features/issues on the
> > trunk and fix/test them, e.g., implementation of migration from java
> > serialized jacob states to json based jacob states as mentioned by Tammo.
> >
> > Would it be possible to create a consolidated roadmap/task list to
> exactly
> > define the tasks/steps necessary for the different releases?
> > So that everybody that wants to contribute is able to do so because at
> the
> > moment it is hard to get an idea what the open points are (at least from
> my
> > perspective).
> > If I can help with that, just let me know :-)
> >
> > Best regards,
> > Michael
>

Re: Extension activities

[Oliver Kopp]

Hi Sahtwik,

Thank you for clarification!

I also understand your high quality goals. My hope is that with Michael
Hahn as (Apache ODE?) committer can help to achieve these goals.

Cheers,

Oliver

2018-02-23 12:41 GMT+01:00 Sathwik B P <sathwik...@gmail.com>:

> Oliver,
>
> Apache Ci is Jenkins, code pushes will trigger the build almost immediately
> and snapshots are availavle in the Apache snapshot repo.As I have already
> responded that we cannot market/expose snapshot artifacts to the users as
> per the organization policy no matter which CI tools one proposes to use.
>
> What is your idea behind CI-Pipeline?
>
> regards,
> sathwik
>
> On Fri, Feb 23, 2018 at 5:02 PM, Sathwik B P <sathwik...@gmail.com> wrote:
>
> > Hi Michael,
> >
> > Just a quick jot down of tasks for JACOB. Migration is another, need to
> > see what is missing in JACOB.
> >
> > JACOB [Release branch (2.0a) - compatible with the ODE trunk branch]
> > 
> > ---
> > 1) Update pom
> > -- Upgrade Jackson to latest stable release
> > -- JDK 8
> > 2) Lookout for patterns in source as indicated in the CVE [
> > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jackson].
> > 3) Make a new CI build for the 2.0a-JDK 8.
> > 4) Run the ODE trunk build to take up latest jacob snapshot.
> > 5) Look out for any JACOB open JIRA issues. [issues.apache.org/jira/
> > browse/JACOB]
> >
> > Migrations testing from 1.3.7
> > --
> > 1) Deploy ODE 1.3.7 with external database [mysql] and any transaction
> > manager on TOMCAT or use the Embedded ODE Tomee distro.
> > 2) Deploy a prrocess and run an instance of the process.
> > 3) Configure the ODE trunk to the same external database. Run database
> > migration scripts [need to check if there is any required].
> > 4) Do we need to recompile the process binary[.cbp file] to new OModel?
> > This is the real thing.
> > 5) Complete the running process instance. Runtime processing state
> > migration would be tested.
> > 6) Create a fresh process instance on the trunk and complete the running
> > instance.
> > 7) Verify all the exmaple processes in similar fashion.
> >
> > Lets see how it goes from here.
> >
> > regards,
> > sathwik
> >
> > On Thu, Feb 22, 2018 at 2:35 PM, Michael Hahn <mhahn@gmail.com>
> wrote:
> >
> >> Hi Sathwik,
> >>
> >> I could commit to support you with the releasing (new JACOB
> >> implementation, ODE) and to help you by taking up features/issues on the
> >> trunk and fix/test them, e.g., implementation of migration from java
> >> serialized jacob states to json based jacob states as mentioned by
> Tammo.
> >>
> >> Would it be possible to create a consolidated roadmap/task list to
> >> exactly define the tasks/steps necessary for the different releases?
> >> So that everybody that wants to contribute is able to do so because at
> >> the moment it is hard to get an idea what the open points are (at least
> >> from my perspective).
> >> If I can help with that, just let me know :-)
> >>
> >> Best regards,
> >> Michael
> >>
> >> -Ursprüngliche Nachricht-
> >> Von: Sathwik B P [mailto:sathwik...@gmail.com]
> >> Gesendet: Donnerstag, 22. Februar 2018 08:07
> >> An: dev@ode.apache.org
> >> Betreff: Re: Extension activities
> >>
> >> Oliver,
> >>
> >> What is your commitment towards continued interest in developing ODE
> >> further beyond the extension activities? [We are on the verge of zero
> >> project activity].
> >> We can offer committership.
> >>
> >> Trunk is RAW code, never tested. We also probably need to see if there
> >> are any security concerns with respect to JSON serialization used in the
> >> new Serialization mechanism, I vaguely remember as there was a flag
> raised
> >> on it sometime ago on a different project.
> >> We can probably look for an Alpha release unless the PMC disagrees. This
> >> process will require quite an effort on the administrative front.
> >> With my limited bandwidth since I only contribute during my free time,
> >> it's going to be quite a task. I have the 1.3.8 release process on my
> plate.
> >>
> >> What do you mean by "correlation between source + binary"?
> >>
> >> regards,
> >> sathwik
> >>
> >

[jira] [Created] (ODE-1005) Wrong link in Creating a Process

[Oliver Kopp (JIRA)]

Oliver Kopp created ODE-1005:


 Summary: Wrong link in Creating a Process
 Key: ODE-1005
 URL: https://issues.apache.org/jira/browse/ODE-1005
 Project: ODE
  Issue Type: Improvement
  Components: Documentation
Reporter: Oliver Kopp
Priority: Trivial


http://ode.apache.org/creating-a-process.html lists See the complete example 
here., where here points to 
https://svn.apache.org/repos/asf/ode/trunk/distro-axis2/src/examples/HelloWorld2/.
 That in turn leads to a 404.

I think, the link should be 
https://svn.apache.org/repos/asf/ode/trunk/distro/src/examples-war/HelloWorld2/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira