axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brain, Jim" <JBr...@Aegonusa.com>
Subject RE: Web Services Logical Architecture
Date Thu, 24 Apr 2003 19:31:55 GMT
I didn't see the original followup, but here are comments:
 
Jim Brain, jbrain@aegonusa.com <mailto:jbrain@aegonusa.com> 
"Researching tomorrow's decisions today."
(319) 369-2070 (work)
Systems Architect, ITS, AEGON Financial Partners
 
-----Original Message-----
From: Almeida, Timothy [mailto:timothya@firepond.com]
Sent: Thursday, April 24, 2003 1:15 PM
To: 'axis-user@ws.apache.org'
Subject: RE: Web Services Logical Architecture
 
I tend to agree with the "not a silver bullet" characterization of web
services.
 
Nothing is a silver bullet.  Good, fast, cheap, pick 2 :-)
 
IT shops want good and cheap, WS offers that at the expense of speed.
 
Besides performance, another significant compromise [I feel] one must make
when using a web service is the consequent flattening of the programmatic
interface. This is inherently associated with the impracticality of
supporting 'remote references'. (For me this is compelling enough a reason
to avoid going overboard with the use of web services -- quite aside from
the more obvious and more often cited 'performance concerns'.) 
WSIF, based on what I understand of it, isn't likely to put that particular
concern to rest.
 
I think that this will be addressed at some point in WS.  However, realize
that a lot of interfaces don't have this complexity.  Of those that do, some
use it carelessly, but that's open for debate.  
 
The sweet spot for web services IMHO is probably integration between systems
-- especially in a fragmented middleware landscape.
(Of course, I'd love to hear other opinions on the subject -- even if it
means having to accept that my assessment was way off!)
 
I think that is a limiting view.  Most client apps are just systems in
disguise, so it becomes hard to segregate them off.  (Think of an automated
phone system, it's both a client and a system, and it does not have a GUI,
so what bucket do you put it in?)  
 
-----Original Message-----
From: Benjamin Tomasini [ mailto:btomasini@neteverything.com
<mailto:btomasini@neteverything.com> ]
Sent: Thursday, April 24, 2003 12:08 PM
To: axis-user@ws.apache.org
Subject: RE: Web Services Logical Architecture


This is kinda fundamental to the choice to use WS or not (and then how
much), but I think it plays into this discussion.

The #1 enemy of performance is serialization.  I use SOAP because I have
to, but recognize it represents the wost kind of performance hit in
computer-land that I know of. For most cases, distributed architecture
is bad design. 
Hmmm, well I will go on record as patently disagreeing with you (no
offense).  In my world, distributed architecture is not only a good design,
we've tried the other ideas, and they failed.
I think developers need to be careful not to overuse any kind of
serialization or distributed architecture.
Serialization is not the issue (how do you think JDBC calls work, or calls
to Peoplesoft or SAP.  Face it, there is no way in any reasonably complex
system to put all the data on my machine and access it directly.  So, call
it what you will, but any interface you use does serialization to something,
and that is expensive, because you are copying and potentially massaging
data.  XML is worse than most, and with compression is slightly worse than
most, but we already overuse serialization in apps, because that is the only
solution.  So, why not standardize the serialization, make it language
agnostic, and move on?
If one has good cause to pursue it, it should be kept to a bare minimum.

Ben

On Thu, 2003-04-24 at 13:11, Richard Musser wrote:
> This is interesting because our team is having this same discussion on how
to apply WS to our project.
>
> My question: has anyone built a system that used WS extensively to
separate tiers and wish they HADN'T? 
>
> The pros and cons are pretty well discussed below, but most people seem to
like using (or at least discussing) WS as their primary
separation/distribution technology. 
>
> The most common argument against WS 'all the time' is performance, but I
haven't seen a situation where WS overhead is a problem.  The 2nd slight
would be that a WS infrastructure would be less couple/integrated with your
development platform/language.  But that can be both a benefit and a
problem.
>
> A couple of random comments:
> >* Other non GUI applications can re-use the same web service
> Any other decent remoting technology (RMI, ejb, whatever) are also non-gui
specific, so that advantage isn't unique to WS.
They are non GUI specific, but they are language specific, so they lose
(most of the time, presentation is done in .NET/VBScript, heavy lifting is
J2EE
>
> >* There are ways of getting XML to approach the speed of RMI,
compression,
> I haven't seen performance comparisons in Java, but in .Net-land I've seen
some tests that show a significant performance hit using XML/WS instead of
binary object serialization.  Now how slow is 'too slow' for an application
varies, and most people get a bias one way or the other before they really
test it.  My guess is that WS are 'fast enough' for most applications.
>
> The current word from the Microsoft crowd is to use WS 'when you need it',
and to use 'native' functionality as much as you can. You can make your own
decision about how much MS cares about interoperability with non .Net
platforms.
I will concede WS are slower.  What I temper that with is "what is too
slow?"  Often, the difference between 5 ms and 50 ms is meaningless, as the
business process takes 500 ms.
Jim




Mime
View raw message