axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pathak, Sanjesh" <>
Subject RE: Web Services Logical Architecture
Date Thu, 24 Apr 2003 19:08:22 GMT
Sorry, I sent a general email. It was not meant against anyone. Thanks for that correction
(my english is bad)..

-----Original Message-----
From: Almeida, Timothy []
Sent: Thursday, April 24, 2003 1:52 PM
To: ''
Subject: RE: Web Services Logical Architecture

not exactly. the point I made in my last message had nothing to do with performance!

PS: The word you were looking for is 'moot' ;)

-----Original Message-----
From: Pathak, Sanjesh []
Sent: Thursday, April 24, 2003 1:48 PM
Subject: RE: Web Services Logical Architecture

I thought we all knew that there is always a trade-off between flexibility and performance.
Flexibility and performance are inversly related. If one wants flexibility then performace
has to be sacrificed. Web services is about flexibility so the performace will always be (s)lower
than a custom or a native interface.

Once this is understood, all this discussion becomes mute ..

-----Original Message-----
From: Brain, Jim []
Sent: Thursday, April 24, 2003 1:33 PM
To: ''
Subject: RE: Web Services Logical Architecture

You provide an interface that makes sense for each language.  For Java, the
service is exposed as a Java class.  VB sees a COM object, .NET see a .NET
assembly, CICS sees an external CICS transaction, etc.


Pubishment is a strong word.  Remember that big companies are weighing the
"performance"/"maintenance" line.  Basically, what developers who come in
here need to realize is that I am not interested in raw performance.  I am
interested in "good enough" performance that is easy to maintain.  Overall
TCO, and all that.  I get a lot of "guru coders" in here that scoff at web
services because it is not the most performance centric solution.  They like
tightly coupled native API apps.  I tell them to get over it.  I want
scalable apps that use a limited set of technologies.  Web services provides
a good middle ground that is often "good enough" and limits the number of
technologies I have to maintain and support.  If you can automate the
creation of the client code, that is good, and allows IT to offer more proxy
options.  WSDL offers that, so we just buy proxy generators for various
languages (or use built in tools).

There are a few apps in this world that need raw performance over all other
criteria.  For the rest of us, good enough is just that:  good enough.


Jim Brain,
"Researching tomorrow's decisions today."
(319) 369-2070 (work)

 -----Original Message-----
From:   Zhang, Frank []
Sent:   Thursday, April 24, 2003 12:36 PM
To:     ''
Subject:        RE: Web Services Logical Architecture

Well said.
I am wondering what people do for Java client. If you let Java and non-Java
clients go thru WS, it's a 'punishment' to Java client. It's like to force
all vehicles moving at the speed of a slow 18 wheeler. Do you provide
different interfaces for the clients?


-----Original Message-----
From: Brain, Jim []
Sent: Thursday, April 24, 2003 12:00 PM
To: ''
Subject: RE: Web Services Logical Architecture

I would concur.

For 10 months, we have been running, in production, a web application that
uses Struts.  When the app (a life insurance new business entry app) needs
to contact our life admin system, it formats a message style ACORD TXLife
message (actually, it uses java classes to build a Java class tree of the
data, ala Castor or JAXB), and then sends the resulting data via AXIS to the
server, and then gets the response.

There are significant advantages, even though the client app is in Java.

* Standardized data format
* Other non GUI applications can re-use the same web service
* There are ways of getting XML to approach the speed of RMI, compression,
and such
* We find that if you build the web service right, the time taken to perform
the service is much greater than the network latency (read as the web
service does enough processing to take a bit of time), so the latency is a
moot point, anyway. (Web services are best served up as coarse business
functions, not fine business fragments)
* If performance requirements requires, AXIS can be swapped out for RMI
(just implement a version of the stub that uses RMI) (if client was in Java)
* If that isn't good enough, hook the service and the client together via
EJB local calls (again, just re-implement the stub) (again, if client was

So, we get flexibility, we don't lose the RMI option, but we only have to go
to it if performance requirements dictate.

It has worked out EXTREMELY well for us, even though many folks here thought
it was a big gamble when we started.  I recommend it for all development, as
it supports non-Java clients (and servers), and if there is language parity,
you can switch to RMI or direct calls later on if need be.  However, using a
web service offers much easier debugging options (anyone try to trace an RMI
stream lately and read it?), so even if you intend on doing RMI in prod, WS
in dev is a good way to test.

And, if transactions are needed, JMS is there as well, or HTTPR, or

The short of this is:

Web services is an implementation of an abstraction layer framework, and
this is the idea that will win IT shops over, like it has mine.  Have your
business logic development write code that does the business function, but
have them simply expose the logic in a language specific way (CICS
transaction, Java EJB, etc).  Use the server piece of an abstraction layer
to take the language specific logic and expose it via a few defined ways
(web services, EJB, etc.).  Then, on the client side, us the client piece of
the abstraction layer to generate proxy code to contact the service.  This
is a good thing, because:

* transport and actual wire data format are abstracted from the business
logic and the client code, meaning that IT shops can change out a transport
and/or wire protocol at a later time, without rewriting complex business
* Free app development to concentrate on business logic and client
presentation, not glue logic and data format conversion.
* Flexibility to choose transport based on non technical constraints
(MQSeries is not cheap, but robust, HTTP is cheap, but not as robust, pick
the transport after weighing the risks, not because it's how the service was
* Since all logic is remotely callable, traces can be inserted easier
* Remote called code is useful for scaling purposes, something a large
company needs to keep in mind.  Apps start small and fit on one box, but
some grow up (because of customer demand), to require a more scalable
architecture, but typically, the cowboy-coder development didn't plan for
such demand, so the apps breaks under its success.  An Abstraction layer
give you built in scalability options without requiring the nasty up-front
commitment in development time (or, at least other benefits of using the
layer make the commitment good for other reasons)

Web services will gain more traction than other abstraction layers (like
COM+ or EJB), because it is platform/language agnostic.  IT shops want that
as well, because .NET and Java are both here to stay, and large companies
will have a mix, whether they want that or not.

I've been preaching this for 18 months or so here, and it's starting to sink
in.  It sinks in very quickly when people see the re-use, and they see the
platform-agnostic solutions.


Jim Brain,
"Researching tomorrow's decisions today."
(319) 369-2070 (work)

 -----Original Message-----
From: []
Sent:   Thursday, April 24, 2003 10:28 AM
Subject:        Re: Web Services Logical Architecture

> Kevin,

> I find your remarks very interesting but I am wonder how you can ever
> justify having soap replace rmi between the Web tier and the enterprise
> (with EJBs) in a close environment.  Web Services seem to be much slower
> than RMI.  I guess web services only make sense between these tier if
> are seperated across the Internet.  Do you agree?

> Thomas

Thomas -

I disagree. I use web services for a much wider range of applications.

Interaction between any two given applications is just easier using web
services. I build interfaces between systems  by first defining the
interface using XML and then building a web service to carry the XML.
Unless both sides are using Java, then RMI/EJB connections aren't an

Even if both sides are using Java, I think it's better anyway. If you
define an interface between two systems by creating EJB/RMI links then the
two systems are too tightly coupled. If you change one, you are more likely
to have to change the other. Plus, unless you're using the same JVM version
on each side you can have problems.

Defining the interface in XML between two systems allows you to more easily
change things. Not the least of this is that you can put *all* the data in
a single String when you use XML (versus having a whole host of
methods/objects exposed using EJB's). Also, if you want your EJB's to
return complex objects then both sides have to have access to the class
file definitions. With XML you just send/receive strings - each side can
parse it however they want.

Also, I've found that defining system interfaces using XML allows
business-people and analysts to get more involved in the process. They can
understand XML pretty easily and can even define/maintain a lot of it
without me getting involved.

In addition, we use Cold Fusion MX for some internal applications (great
product!) and it makes it easy for us to do the presentation layer work in
Cold Fusion and then access business objects from our back-end servers
using axis-based web services. We used to create custom cold fusion tags to
call our EJB's, but this is much easier.

When I design systems now that interact with any other system, the first
thing I think now is how to lay out the web services I want to expose. I
then document the XML-based interface points to send to the
builders/maintainers of the other system, and I'm off and running.

Hope this helps -

This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.

Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (Whitehouse Station, New Jersey,
USA) that may be confidential, proprietary copyrighted and/or legally
privileged, and is intended solely for the use of the individual or entity
named on this message. If you are not the intended recipient, and
have received this message in error, please immediately return this by
e-mail and then delete it.

This e-mail is the property of Enron Corp. and/or its relevant affiliate and may contain confidential
and privileged material for the sole use of the intended recipient (s). Any review, use, distribution
or disclosure by others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender or reply to Enron Corp.
at and delete all copies of the message. This e-mail
(and any attachments hereto) are not intended to be an offer (or an acceptance) and do not
create or evidence a binding and enforceable contract between Enron Corp. (or any of its affiliates)
and the intended recipient or any other party, and may not be relied on by anyone as the basis
of a contract by estoppel or otherwise. Thank you.

View raw message