RE: Best way to realize stateful services architecture with massivedata?

2007-10-22 Thread Walker, Jeff
Doesn't look like anyone replied. So here goes..
1. Web services shouldn't be stateful. (Far harder to keep that promise than to 
recite it). My own current service is stateful, and it breaks the SOA rules we 
have in place here, causing me no end to issues. Removing the statefulness once 
it creeps into your project is like getting blood from a stone. Best remedy is 
to create a composite service that is stateless, and that talks to the client. 
It also formulates a series of web service calls to your stateful service that 
does the real work. The composite service then returns the result to the 
client. BPEL could help here.

2. Web services are not suitable for large data transfer, at all. I have found 
past about 20Mb of data per request/response and the service starts to timeout. 
That is even when RAM is added and processors are upgraded. On one of my 
previous web services gigs I was asked to build a web service to transfer 
files. They grew from 20Mb to 75Mb with few troubles except for the occasional 
timeout, then to 1 Gig in size. The remedy was to call the service 
asynchronously. There are various Microsoft and IBM websites that will explain 
that mode of calling. (If you need them, I can send you the article urls, I 
just don't have them handy right now).
Remedy is to rethink your architecture. Web services will perform very badly 
for you on large data sets. (So bad as to be totally unusable). So simply don't 
use the web services for the data transfer. Try FTP instead, and use the web 
service to generate the files and pass back the address of where to find the 
files. It sounds like the granularity of your service is too fine-grained. You 
need to think in higher terms for the web service operations.
Just some thoughts.
-jeff

 

-Original Message-
From: Florian Georg [mailto:[EMAIL PROTECTED] 
Sent: Sunday, October 21, 2007 11:29 AM
To: axis-user@ws.apache.org
Subject: Best way to realize stateful services architecture with massivedata?

I´m currently thinking of the best way to realize data-intensive
"workflows" composed of web services (similar e.g. to a BPEL engine).
I´ll looking at Axis2 engine for that, but I´m unsure how it could fit
my special needs:

What I need to do is to be able to call subsequent operations on a
service (e.g. configure(), execute(), getNextResults(), reset(), ..).
Background is that these are very long running services which consume
and produce potentially some GBs of data.
The services are dependend of each other, e.g. execute() may only be
called after a predecessor service has successfully executed.
Produced data should be re-usable by differend nodes, e.g. passing
around and re-generate should be minimized.

What do you think of this?
What does Axis provide me for this scenario? 
Should I use, e.g. WS-Resource (Muse) for this? An ESB ?
Or should I even consider mapping this into BPEL and use a process
engine?
(ok, I´ll stop here before it becomes too off-topic)

Any remarks would be greatly appreciated.

thanks in advance
  -- Florian



-
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]



RE: Best way to realize stateful services architecture with massivedata?

2007-10-22 Thread Michele Mazzucco
On Mon, 2007-10-22 at 09:09 -0400, Walker, Jeff wrote:
> 1. Web services shouldn't be stateful. (Far harder to keep that
> promise than to recite it). My own current service is stateful, and it
> breaks the SOA rules we have in place here, causing me no end to
> issues. Removing the statefulness once it creeps into your project is
> like getting blood from a stone. Best remedy is to create a composite
> service that is stateless, and that talks to the client. It also
> formulates a series of web service calls to your stateful service that
> does the real work. The composite service then returns the result to
> the client. BPEL could help here.

Jeff, can you tell me about a non-trivial stateless web service?
What is the difference between the first (i.e. the stateful WS talks to
the client) and the second approach (i.e. the stateful WS is hidden by a
stateless one)?

> 
> 2. Web services are not suitable for large data transfer, at all. I
> have found past about 20Mb of data per request/response and the
> service starts to timeout. That is even when RAM is added and
> processors are upgraded. On one of my previous web services gigs I was
> asked to build a web service to transfer files. They grew from 20Mb to
> 75Mb with few troubles except for the occasional timeout, then to 1
> Gig in size. The remedy was to call the service asynchronously. There
> are various Microsoft and IBM websites that will explain that mode of
> calling. (If you need them, I can send you the article urls, I just
> don't have them handy right now).
> Remedy is to rethink your architecture. Web services will perform very
> badly for you on large data sets. (So bad as to be totally unusable).
> So simply don't use the web services for the data transfer. Try FTP
> instead, and use the web service to generate the files and pass back
> the address of where to find the files. It sounds like the granularity
> of your service is too fine-grained. You need to think in higher terms
> for the web service operations. 

What about WS with JMS?


Michele


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]