Sorry... In regards to
chaining together transformations via a Web Service
implementation
I should have emphasized the idea of repeated requests back and forth
across the wire as you had suggested. Obviously if its one request
that invokes a series of transformations without need to return
anything to the requestor before proceeding then this could work quite
well...
On 6/3/05, M. David Peterson <m(_dot_)david(_dot_)x2x2x(_at_)gmail(_dot_)com>
wrote:
Yeah, the Web Service approach is an excellent approach if your
talking one off transforms that are coming from multiple requesting
sources. A well designed Web Service engine can produce fantastic
results for a large multitude of requesting clients. But if you're
talking about chaining together transformations via a Web Service
implementation this is something that would obviously be something to
be leary of.
This is not to down play Web Services from a general stand point. In
many ways they can be quite preferable in that you simply have no
concerns as far as platform compatibilities etc... but in regards to
performance... you've allready nailed it so no need to extend.
On 6/3/05, Barry Lay <blay(_at_)laysercomputing(_dot_)com> wrote:
The XSL-as-web-service is intriguing but I do have some concerns about a
command-line processor. The comment George makes about the JVM startup
overhead can be extended to most things run from the command line -
there will be system-related activity that has little to do with the
work that will be incurred each time. If this is a concern for XSLT the
processor can be properly hosted within the web server. Saxon is ideal
for this as it is Java based. It would be fairly straightforward to
create a web service for this purpose that could be dropped into a J2EE
container and run on whatever kind of platform you like (Windows, Linux,
Unix, Mac, etc.), and it doesn't have to be the same OS as the client.
With Saxon's support for pipelining transformations some of those
concerns could be addressed as well. My main concern with the web
service approach in general is the amount of data that would need to be
transmitted across the network. That may be the real limiting factor in
this.
Barry
George Cristian Bina wrote:
Hi Pieter,
It's actually quite simple. I'm using a process class which allows
me to
capture StdOut and StdErr, and that runs a process in the
background. The
background process can be anything that runs via a command line, and
the
best is that it runs completely independent (in Windows this just
means on
another thread). While threads compete with each other for CPU time,
when
the process runs, the main thread just waits for its output, which
means
that the child thread can use all CPU available, thus maximum
performance is
guaranteed (under normal circumstances and no other tasks running
assumed).
What about the java start up time? You will add that at each run.
And if you run the transformation only once then I think you will not
get the best of Java either - I always hear that if you want to
measure how much time a stylesheet takes for processing you should not
look at the times of the first runs.
My 2 cents...
Regards,
George
---------------------------------------------------------------------
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
<M:D/>
M. David Peterson
http://www.xsltblog.com
--
<M:D/>
M. David Peterson
http://www.xsltblog.com
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--