in case you missed it, I wrote last year a concept programming language as part of WSPER (http://www.wsper.org) that has the concept of state at its core.

I am glad to see these kind of ideas catching up at Oracle too.

Jean-Jacques

The IBM technology that Edwin’s referring to is their “business state machine” (article on developerWorks), and my understanding was that it was similar to BPMN in that it was a notation that it compiled down to BPEL for execution with back-references to the original diagram.

Let me try to explain what I mean by 3) a little more. My experience is that if you are building a large scale application, it is always best to first model your data model/schema first. That is going to be the foundation. For example, if you are building an expense processing application, you need a schema to capture the information in the expense report. With entities like an expense report which have a lifecycle (”created”, “submitted”, “approved”, “rejected”) it is usually very valuable to be able to capture that lifecycle information in your schema and be able to expose the lifecycle transitions as business event to the external world.

Given that context, I would like to be able in SimPLE create a entity variable for my expense report based on my data model (hence requirement #2) and I would like to be able to simple to be able to listen to business events like myExpenseReport.lifecycle[ "created" -> "submitted" ]

Regarding 1), I understand why you would not want to drop XML in the very short term but if you want to create something really simple and for the next 2-3 years out, I would recommend you try to reconsider: Most new services offer both plain old XML and JSON. Over time, JSON will win for 80% of the real world cases.

I will take a look at the Apache project. Also try to see if you can reach out to Keith Swenson at Fujitzu: he is a true visionary in this space and an amazing person to work with.

Thanks a lot for your interest, a few remarks based on your feedback:

1) A RESTful interface is going to be the default remote channel to communicate with the engine. And we’ll probably have a few language specific bindings when you want to use the engine in-process. We’ve thought about JSON as well but there are a few translation issues to iron out, XML and JSON don’t map as well as it may seem to each other. I wouldn’t drop XML though.

2) We already have something like this in ODE, where you can map “external variables”. Instead of being store in the engine datamodel, those are mapped to whichever table you configure. What I actually like about it is that it’s an opt-in feature. I think it’s a sound default as there are only a few entities used by your process that you really want to access externally. External variables haven’t been rolled in SimPEL yet but they will be.

3) Interesting. I can definitely agree for task-driven state transitions that usually back a workflow. But do you think there’s also a need for a state machine outside of that use case?

Regarding your help offer, it’s much appreciated. I’ll contact you. I’d also like to repeat that SimPEL is being developed at Apache, as part of an open community where we welcome everybody.

Again this is very interesting. If I had to redo it again today. I would include 3 changes.

1) REST+JSON - REST meaning do not allow people to create verbs…and extend REST to have correlation and async callback. Use JSON instead of XML.

2) Activities are not enough. Most workflow models fail because they do not include a solid entity model. The result is that the data is in jail in the workflow engine. So it would be nice if the model had both support variales of type message and entities (a simple JSON to hibernate mapping would go a long way).

3) orchestration and state. If you look at IBM, they use BPEL for orchestration and have a separate engine for state transition. In the real world, you need both. State transitions and business events are really key.

I have been thinking about something like SimPEL for feedly: as the complexity of our application increases, we end up doing a lot of mashups which need to aggregate data and update multiple JSON services.

Good luck with this initiative and please ping me if I can be of any help.