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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
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]
