Dynamic Invocation Evaluation Question

Hello,

I have a project that has several requirements related to
dynamic
invocation of web services using SOAP and async messaging
using JMS.
Our product is written in C and so initially I thought that
using the
new Axis2/C implementation might be the way to go as it
supports client
side dynamic invocation of web services.

However, there are some clear benefits in implementing the
web
services client in Java.  This led me to look at the Axis2
Java
implementation which doesn't have support for dynamic
invocation.  That
lead me to the WSIF project which appears to meet my
requirements.  So a
couple of questions:

1) It looks like the last release was 2003 and that there
was a release
planned for 2006.  Is that release still planned?
2) As I will be going through the samples over the next
couple of days
is it advisable to pull the source for bug fixes, etc that
occurred post
2003 release?

Thank you for your time,

Cliff

-- 
Clifford Audinet
Software Architect

Stonebranch, Inc.
950 North Point Parkway
Suite 200
Alpharetta, Ga 30005
(678) 366-7887 X316
http://www.stonebranch.com

mailto:clifford.audinetstonebranch.com




------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org

Christian Kloner wrote:
> hi,
>
> why do you think, that Axis2 Java has no support for
dynamic
> invocation? The thing is, if you use the RawXmlMessage
Handler for
> sending and receiving messages, you can construct with
Axiom any SOAP
> message and send it through the net to any destination.
I also used it
> in my workflow project and created an own invocation
API around it. if
> you are interested in it, i can manage to give you
access to it.
>
> WSIF was a fine project, but i think it is a bit
outdated. I used it
> in my invocation api 2 years ago but the problem was,
that i had to
> invoke web services really dynamically without having
any java object
> to deserialize xml to. as i know, for every xml
message, you need to
> register a java object to deserialize to. but what is,
if you don't
> have any java class compiled for the receiving xml
message... please
> tell me, if I am not correct and WSIF now supports a
really dynamic
> approach for complex datatype handling. thanks.
chris,

at some stage you need to do /some/ type handling -
depending on
workflow lang and how you use it you may get away with xpath
expressions
and no types validation - the value WSIF could add if you
invoke not
just XML web service but anything that can be described in
WSDL so
workflow interacts with services using common abstraction
(WSDL and WSIF
API)

best,

alek
>
>
>
>
> Clifford Audinet wrote:
>> Hello,
>>
>> I have a project that has several requirements
related to dynamic
>> invocation of web services using SOAP and async
messaging using JMS.
>> Our product is written in C and so initially I
thought that using the
>> new Axis2/C implementation might be the way to go
as it supports client
>> side dynamic invocation of web services.
>>
>> However, there are some clear benefits in
implementing the web
>> services client in Java.  This led me to look at
the Axis2 Java
>> implementation which doesn't have support for
dynamic invocation.  That
>> lead me to the WSIF project which appears to meet
my requirements.  So a
>> couple of questions:
>>
>> 1) It looks like the last release was 2003 and that
there was a release
>> planned for 2006.  Is that release still planned?
>> 2) As I will be going through the samples over the
next couple of days
>> is it advisable to pull the source for bug fixes,
etc that occurred post
>> 2003 release?
>>
>> Thank you for your time,
>>
>> Cliff
>>
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
> For additional commands, e-mail: wsif-user-helpws.apache.org
>


-- 
The best way to predict the future is to invent it - Alan
Kay


------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org

hi alek,

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. In my approach, I transformed this
information 
into internal 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.

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.

but in short, it depends on the requirements.

best regards,
chris

p.s.: how is the status of the GPEL engine? 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. Apache now started workflow project with
synergy effect: 
http://
incubator.apache.org/projects/ode.html


Aleksander Slominski wrote:
> Christian Kloner wrote:
>> hi,
>>
>> why do you think, that Axis2 Java has no support
for dynamic
>> invocation? The thing is, if you use the
RawXmlMessage Handler for
>> sending and receiving messages, you can construct
with Axiom any SOAP
>> message and send it through the net to any
destination. I also used it
>> in my workflow project and created an own
invocation API around it. if
>> you are interested in it, i can manage to give you
access to it.
>>
>> WSIF was a fine project, but i think it is a bit
outdated. I used it
>> in my invocation api 2 years ago but the problem
was, that i had to
>> invoke web services really dynamically without
having any java object
>> to deserialize xml to. as i know, for every xml
message, you need to
>> register a java object to deserialize to. but what
is, if you don't
>> have any java class compiled for the receiving xml
message... please
>> tell me, if I am not correct and WSIF now supports
a really dynamic
>> approach for complex datatype handling. thanks.
> chris,
> 
> at some stage you need to do /some/ type handling -
depending on
> workflow lang and how you use it you may get away with
xpath expressions
> and no types validation - the value WSIF could add if
you invoke not
> just XML web service but anything that can be described
in WSDL so
> workflow interacts with services using common
abstraction (WSDL and WSIF
> API)
> 
> best,
> 
> alek
>>
>>
>>
>> Clifford Audinet wrote:
>>> Hello,
>>>
>>> I have a project that has several requirements
related to dynamic
>>> invocation of web services using SOAP and async
messaging using JMS.
>>> Our product is written in C and so initially I
thought that using the
>>> new Axis2/C implementation might be the way to
go as it supports client
>>> side dynamic invocation of web services.
>>>
>>> However, there are some clear benefits in
implementing the web
>>> services client in Java.  This led me to look
at the Axis2 Java
>>> implementation which doesn't have support for
dynamic invocation.  That
>>> lead me to the WSIF project which appears to
meet my requirements.  So a
>>> couple of questions:
>>>
>>> 1) It looks like the last release was 2003 and
that there was a release
>>> planned for 2006.  Is that release still
planned?
>>> 2) As I will be going through the samples over
the next couple of days
>>> is it advisable to pull the source for bug
fixes, etc that occurred post
>>> 2003 release?
>>>
>>> Thank you for your time,
>>>
>>> Cliff
>>>
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
>> For additional commands, e-mail: wsif-user-helpws.apache.org
>>
> 
> 


------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org

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
> In my approach, I transformed this information into
internal
> 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 ...)
>
> 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.
>
> but in short, it depends on the requirements.
exactly - there is really no one tool for every task and
WSIF is just a
tool at the end of day ...
>
> p.s.: how is the status of the GPEL engine? 
almost finished - i got first version working (and used in
our portal).
> 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)
> 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.

best,

alek
>
>
> Aleksander Slominski wrote:
>> Christian Kloner wrote:
>>> hi,
>>>
>>> why do you think, that Axis2 Java has no
support for dynamic
>>> invocation? The thing is, if you use the
RawXmlMessage Handler for
>>> sending and receiving messages, you can
construct with Axiom any SOAP
>>> message and send it through the net to any
destination. I also used it
>>> in my workflow project and created an own
invocation API around it. if
>>> you are interested in it, i can manage to give
you access to it.
>>>
>>> WSIF was a fine project, but i think it is a
bit outdated. I used it
>>> in my invocation api 2 years ago but the
problem was, that i had to
>>> invoke web services really dynamically without
having any java object
>>> to deserialize xml to. as i know, for every xml
message, you need to
>>> register a java object to deserialize to. but
what is, if you don't
>>> have any java class compiled for the receiving
xml message... please
>>> tell me, if I am not correct and WSIF now
supports a really dynamic
>>> approach for complex datatype handling.
thanks.
>> chris,
>>
>> at some stage you need to do /some/ type handling -
depending on
>> workflow lang and how you use it you may get away
with xpath expressions
>> and no types validation - the value WSIF could add
if you invoke not
>> just XML web service but anything that can be
described in WSDL so
>> workflow interacts with services using common
abstraction (WSDL and WSIF
>> API)
>>
>> best,
>>
>> alek
>>>
>>>
>>>
>>> Clifford Audinet wrote:
>>>> Hello,
>>>>
>>>> I have a project that has several
requirements related to dynamic
>>>> invocation of web services using SOAP and
async messaging using JMS.
>>>> Our product is written in C and so
initially I thought that using the
>>>> new Axis2/C implementation might be the way
to go as it supports
>>>> client
>>>> side dynamic invocation of web services.
>>>>
>>>> However, there are some clear benefits in
implementing the web
>>>> services client in Java.  This led me to
look at the Axis2 Java
>>>> implementation which doesn't have support
for dynamic invocation. 
>>>> That
>>>> lead me to the WSIF project which appears
to meet my requirements. 
>>>> So a
>>>> couple of questions:
>>>>
>>>> 1) It looks like the last release was 2003
and that there was a
>>>> release
>>>> planned for 2006.  Is that release still
planned?
>>>> 2) As I will be going through the samples
over the next couple of days
>>>> is it advisable to pull the source for bug
fixes, etc that occurred
>>>> post
>>>> 2003 release?
>>>>
>>>> Thank you for your time,
>>>>
>>>> Cliff
>>>>
>>>
>>>
------------------------------------------------------------
---------
>>> To unsubscribe, e-mail:
wsif-user-unsubscribews.apache.org
>>> For additional commands, e-mail:
wsif-user-helpws.apache.org
>>>
>>
>>
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
> For additional commands, e-mail: wsif-user-helpws.apache.org
>


-- 
The best way to predict the future is to invent it - Alan
Kay


------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org

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. I am 
really looking forward to apache woden (including wsdl 1.1
support if 
hopefully ever implemented).

>> In my approach, I transformed this information into
internal
>> 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 ...)
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...
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.
>> 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. Seems that you are active using WSIF.
>> but in short, it depends on the requirements.
> exactly - there is really no one tool for every task
and WSIF is just a
> tool at the end of day ...
>> p.s.: how is the status of the GPEL engine? 
> almost finished - i got first version working (and used
in our portal).
congratulations!
>> 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.
I hope I can ask you a few more questions and abuse this
mailing list 
for some other things.
So do you use XMlBeans (using Java classes created from xsd
bpel schema) 
to get BPEL representation? getting bpel into memory and
analysing it is 
a hot spot. I considered to let this another service doing.
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. if
you don't 
use globus toolkit container, you can send it as
attachement. but 
perhaps i have seen an old client api.
>> 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. :(
> 
> best,
> 
> alek
>>
>> Aleksander Slominski wrote:
>>> Christian Kloner wrote:
>>>> hi,
>>>>
>>>> why do you think, that Axis2 Java has no
support for dynamic
>>>> invocation? The thing is, if you use the
RawXmlMessage Handler for
>>>> sending and receiving messages, you can
construct with Axiom any SOAP
>>>> message and send it through the net to any
destination. I also used it
>>>> in my workflow project and created an own
invocation API around it. if
>>>> you are interested in it, i can manage to
give you access to it.
>>>>
>>>> WSIF was a fine project, but i think it is
a bit outdated. I used it
>>>> in my invocation api 2 years ago but the
problem was, that i had to
>>>> invoke web services really dynamically
without having any java object
>>>> to deserialize xml to. as i know, for every
xml message, you need to
>>>> register a java object to deserialize to.
but what is, if you don't
>>>> have any java class compiled for the
receiving xml message... please
>>>> tell me, if I am not correct and WSIF now
supports a really dynamic
>>>> approach for complex datatype handling.
thanks.
>>> chris,
>>>
>>> at some stage you need to do /some/ type
handling - depending on
>>> workflow lang and how you use it you may get
away with xpath expressions
>>> and no types validation - the value WSIF could
add if you invoke not
>>> just XML web service but anything that can be
described in WSDL so
>>> workflow interacts with services using common
abstraction (WSDL and WSIF
>>> API)
>>>
>>> best,
>>>
>>> alek
>>>>
>>>>
>>>> Clifford Audinet wrote:
>>>>> Hello,
>>>>>
>>>>> I have a project that has several
requirements related to dynamic
>>>>> invocation of web services using SOAP
and async messaging using JMS.
>>>>> Our product is written in C and so
initially I thought that using the
>>>>> new Axis2/C implementation might be the
way to go as it supports
>>>>> client
>>>>> side dynamic invocation of web
services.
>>>>>
>>>>> However, there are some clear benefits
in implementing the web
>>>>> services client in Java.  This led me
to look at the Axis2 Java
>>>>> implementation which doesn't have
support for dynamic invocation. 
>>>>> That
>>>>> lead me to the WSIF project which
appears to meet my requirements. 
>>>>> So a
>>>>> couple of questions:
>>>>>
>>>>> 1) It looks like the last release was
2003 and that there was a
>>>>> release
>>>>> planned for 2006.  Is that release
still planned?
>>>>> 2) As I will be going through the
samples over the next couple of days
>>>>> is it advisable to pull the source for
bug fixes, etc that occurred
>>>>> post
>>>>> 2003 release?
>>>>>
>>>>> Thank you for your time,
>>>>>
>>>>> Cliff
>>>>>
>>>>
------------------------------------------------------------
---------
>>>> To unsubscribe, e-mail:
wsif-user-unsubscribews.apache.org
>>>> For additional commands, e-mail:
wsif-user-helpws.apache.org
>>>>
>>>
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
>> For additional commands, e-mail: wsif-user-helpws.apache.org
>>
> 
> 


------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org

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: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org

hi alek,

there are a lot of interesting questions and i see that we
are quite 
using different technologies. 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...

so maybe, if you agree, we can move discussion to the 
weep-devglobus.org mailing list. 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 
weep-devglobus.org 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.

best,
chris


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: wsif-user-unsubscribews.apache.org
> For additional commands, e-mail: wsif-user-helpws.apache.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org

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
> weep-devglobus.org 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 weep-devglobus.org 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: wsif-user-unsubscribews.apache.org
>> For additional commands, e-mail: wsif-user-helpws.apache.org
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
> For additional commands, e-mail: wsif-user-helpws.apache.org
>


-- 
The best way to predict the future is to invent it - Alan
Kay


------------------------------------------------------------
---------
To unsubscribe, e-mail: wsif-user-unsubscribews.apache.org
For additional commands, e-mail: wsif-user-helpws.apache.org