Christian Kloner wrote: > there are a lot of interesting questions and i see that we are quite > using different technologies. hi chris!
i think which is simply reflection of differences in goals (i care very much about adaptivity and dynamic workflows as it is main goal for workflows we want to run in leadproject.org) - nonetheless i see no reason why we should not cooperate and make possible to have workflows work together :-) > So perhaps we can measure performance of engines at some later point > when weep is going to have a greater subset of bpel implemented. > because at moment we have only infrastructure and activities invoke, > assign, receive (this only partly because wsdl is not exposed and user > can only send a soap message to the receive activity through the web > browser interface). it would be quite interesting to have detailed > performance results not only on the execution of the workflow as a > whole but what impact used technologies have and where improvements > can be made. So if you are interested in that topic later, it would be > rather fine. we can save great time also in comparing other engines > like apache agila/ode or jboss engine... i am interested more in scalability then (micro)benchmarks in particular: what is the upper limit of number of concurrent workflows that can be sustained with good turnaround, can system survive crashes and continue execution after restarting, to what degree it can support load-balancing and fail-over. as most workflows we run are spending 99% waiting for service response (some service may take hours or longer to produce result) so it makes sense in gpel to swap out workflow state to persistent storage - this allow to support very large number of concurrent workflows - still i am interested in quick workflows (that may invoke lot of service that take very short time to produce response message) but that is not my focus (and gpel is not optimized for it). > > so maybe, if you agree, we can move discussion to the > [EMAIL PROTECTED] mailing list. i created a mailing list that is not specific to any particular project but generally about workflows (not just bpel) and web services (any web services - rest, soap, wsrf, ws-i etc etc ...) - please subscribe to it and we can continue over there: http://tech.groups.yahoo.com/group/ws-wf/ i have also subscribed to weep-dev and i send CC to it as well but as the topic is not weep specific so maybe it is better to have a place to is not specific to any project > at moment in my timezone, it's 6 o'clock in the morning and I need to > go to bed... :-) > so i will answer the questions in the night today. Normally you write > your mails at 1/2 o'clock a.m (i assume my timezone ;) ) so i will > write the things to the [EMAIL PROTECTED] mailing list at that time. > further informations can found there: > http://dev.globus.org/wiki/Incubator/WEEP. at the moment we are just > starting to document so there is not so much information available. how i can try to week [1]? best, alek [1] why name it WEEP? i hope the project is not making you to shed too many tears ;->) > > > > Aleksander Slominski wrote: >> hi, >> >> how about we move this discussion to some mailing list dedicated to web >> services workflows (or we create one as they do not know any such list)? >> i think that having this kind of discussion and sharing ideas would be >> beneficial not only to us. >> >> Christian Kloner wrote: >>> Aleksander Slominski wrote: >>>> Christian Kloner wrote: >>>>> Does not know if i understood correct but using raw XML messages does >>>>> not mean that you forgo type handling. you can still validate against >>>>> schema if the SOAP envelope conforms to doc/literal or >>>>> doc/literal/wrapped (WS-I Profile). If you use a dynamic approach you >>>>> have to parse wsdl files and schemata anyway to know, how the SOAP >>>>> body message should look like. >>>> yes and that is the catch - there no good libraries for that (at >>>> least i >>>> do not know about) so you need to implement that yourself if you want >>>> flexibility >>> but to my best knowledge, xml parser validation should be able to >>> handle this. but i am not 100% sure. anyway, i used wsdl4j and >>> XmlSchema API to get my own representation for the price of high >>> memory consumption. >> how do you deal with persistence (when machine that running workflow >> needs to be restarted etc)? this is a tough problem that effects design >> on every level - if you use OO-DB mapping (iBatis below) then can you >> persist your own representation instead of keeping it in memory. >>> I am really looking forward to apache woden (including wsdl 1.1 >>> support if hopefully ever implemented). >> AFAIK there were no plans for WSDL 1.1 support in woden or did they have >> it now in plans? >>>>> description representation and used visitor pattern to visit the >>>>> descriptions to create a dynamic SOAP envelope. Only the values are >>>>> needed in the right order with special marks for array, complex type, >>>>> attribute. But this is implementation specific. >>>> so what you did you implemented your own (as minimal as needed) type >>>> handling code - not exactly a trivial task and always incomplete at >>>> best >>>> considering level of complexity present in XML schemas (to get it >>>> right >>>> i thhink you need team of minimum 5-10 people working for a year if >>>> not >>>> longer ...) >>> In my approach, I transformed this information into internal >>> you are right. attributes and groups/choices (althouth marked in the >>> description model) are not supported. the rest should work if you use >>> DocLiteralWriter implementation. In case of RpcEncodedWriter, arrays >>> will additionally be not supported. to much work for one... >> exactly (support of XML schemas is not exactly what i am interested in >> or contributes ot my PhD) - but as long as you have a big enough subset >> implemented to get user workflows to run that should be fine (and subset >> can be extended later when needed) - lot of what you implemented in this >> subset is what WSIF (and Apache SOAP, and AXIS, and ...) already did. >>> anyway, I have consideration to take description model out and work >>> directly on the XmlSchema (Apache XmlSchema API). Because at the >>> moment i transform the schemata with XMLSchema API into description >>> model. >> what i do is different - i am looking in direction of supporting >> _experimental_ and open ended building of workflows therefore ability to >> change is the most important factor. >> >> for that reason i actually avoid static checks instead rely on >> just-in-time checking when interpreting XML representing workflow - the >> reason i do it this way is that i am interested in supporting workflow >> instances created in an ad hoc manner that are build incrementally by >> modifying workflow during its execution (including trying what-if >> scenarios, undo etc) - i would like eventually user to build a workflow >> by just playing with tool that allows to record set of steps (such as >> invoking external services) - you could think about such tool to be a >> scientific experiment recorder :-) >> >> that is different than building an engine to run production workflows - >> such engines are focused on running instances of the same template and >> that looks to me current bpel engines concentrate on. i am not really >> interested to repeat it (even those need an extra flexibility to support >> multiple versions of the same template as nothing is forever in IT ...) >>>>> Of course, if you have services using RMI or CORBA instead of SOAP >>>>> you >>>>> need another abstraction layer where WSIF can help if it supports the >>>>> transport protocols. It's long time ago when i worked with it. :( >>>>> But the big advantage of Web service technology is to achieve >>>>> interoperability through standards revolving around XML. So I don't >>>>> think that another abstraction layer is really needed. >>>> i agree however that also mean that you do not really need WSDL >>>> abstraction as you work with XML and then just get XML infoset to be >>>> sent the way of WSDL binding/service/endpoint - unfortunately current >>>> Apache WSIF will not help you much to do it as it was designed and >>>> implemented with Java types first and not with XML infoset first >>>> approach (so that is why there is need for mapping of Java objects >>>> to to >>>> representation for each WSDL/WSIF binding ...) >>>> >>>> i think it would certainly be useful to have complementary WSIF >>>> that has >>>> XML infoset first. >>> would be nice. but in my opinion, the third generation of web service >>> frameworks almost makes WSIF useless under assumption that you only >>> work with Web services. they can handle everything what is needed. in >>> the past it was fine to switch between the old apache soap engine and >>> axis engine but technologies are changing... but perhaps exactly there >>> is a new up wind for WSIF. I heard about new version with Axis2 >>> support and if there was support for XFire or rather CeltiXfire, WSIF >>> would be a consideration again. So you are able not to bind to a >>> specific Web service framework. >> yes - that would be good. >>> Seems that you are active using WSIF. >> in XSUL i have XWSIF that is subset/superset of WSIF API with many >> extensions (it includes for example support for handlers and directly >> working with XML infoset for WSIFMessage) >>>>> i am really interested in how your implementation strategies are. do >>>>> you do any static code analyzing so far or rather do you use >>>>> XMLBeans to get BPEL in memory representation. >>>> i concentrated on dynamic and adaptive aspects of workflows so >>>> *maximum* >>>> flexibility was my goal so i avoided static type checking as much as >>>> possible ... you could look on GPEL engine to have two >>>> responsibilities: >>>> maintain workflow state as XML (as visible to clients) and model >>>> workflow execution as XML transformations that follow BPEL rules (i >>>> only >>>> implemented subset of BPEL as i am the only one implementing it and >>>> moreover BPEL has much more than what is needed in scientific >>>> workflows >>>> we run) >>> I also only have subset at the moment. In my implementation, workflow >>> state is in hsqldb database using iBatis, which is queried through >>> Globus Resource Properties. >> so if i understand correctly you are mapping Java objects to SQL DB? if >> so then how do you map this to XML to have WSRF (Globus GT4 right?) >> properties? >> >> if you do map DB to XML then it is an interesting approach but key >> question is how flexible it is: is it read-only or read-write? do you >> allow users to change those properties or only to view them? >> >> i had an initial prototype of something like that when i was trying to >> design gpel for GT3 - XML properties in OGSI (predecessor to WSRF) >> provided a reflection like capability into workflow engine but their >> semantics were not very well defined so i eventually moved to use ATOM >> Protocol to support something very similar but simpler: instead of >> properties i have a set of XML documents that are identified by URLs and >> (hyper)linked together (using what ATOM provides for a:link) to >> represent workflow state. >>> I hope I can ask you a few more questions and abuse this mailing list >>> for some other things. >> yes but let move to some other mailing list :-) >>> So do you use XMlBeans (using Java classes created from xsd bpel >>> schema) to get BPEL representation? >> no >>> getting bpel into memory and analysing it is a hot spot. I considered >>> to let this another service doing. >> i actually do not care about one process performance (i only do >> interpretation of workflow and no compilation - obviously with some >> caching to keep some internal representation to speed it up but that is >> very straightforward) instead i designed it for scalability - multiple >> gpel engines can be started (or stopped) at any time on on any machines >> as long as it is in one cluster - the only thing they share is DB - if >> gpel starts to be slow i can start more processes on more machines (this >> approach takes an advantage of workflow processing being embarrassingly >> parallel - workflows are now aware of each other so yo can move >> processing freely between cluster nodes) >>> some days ago, I looked at your Java client API(I don't know the >>> portal). Are there any considerations why you didn't use a package >>> approach to deploy Bpel processes. I find it much more easier to >>> create one archive with all the files and send it to the engine. >> i could do this and what is actually done is very close to that - >> deployment of workflow template (and creation of workflow instance) is >> set of HTTP POST operations with (mostly) XML documents (using ATOM >> publishing protocol) - nothing (except for time constraints) prevent >> from implementing POSTing .zip file that is then expanded by engine but >> doing it current way has a nice advantage that you can make this process >> incremental and can change content of one document (HTTP PUT). >>> if you don't use globus toolkit container, you can send it as >>> attachement. but perhaps i have seen an old client api. >> for simplicity i just use tomcat but any servlet container would do - >> gpel has three parts: engine process(es) which is actually running >> workflows (doing XML transformations), sender process(es) that sends >> (SOAP) messages out, and receiver(s) that gets messages and supports >> workflow deployment, monitoring etc (that is tomcat) >>>>> Apache now started workflow project with synergy effect: >>>>> http://incubator.apache.org/projects/ode.html >>>> i tried to compile it weeks ago (so i could run bpel 2 validator) but >>>> never succeeded (got lost in maven maze of sub projects and >>>> dependencies >>>> ...) - hopefully it got better. >>> only looked at it. but maven2 brings great ease of development. >>> however, they have too much modules... and at the moment they merge >>> agila engine and ode engine so there may occur some problems. :( >> yes - i also await a stable release so i do not have to pull it from svn >> and hope i got a working snapshot of code ... >> >> thanks, >> >> alek >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- The best way to predict the future is to invent it - Alan Kay --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
