axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Van de Velde" <thomas...@yucom.be>
Subject Re: Web Services Logical Architecture
Date Thu, 24 Apr 2003 17:02:07 GMT
Yes, but I have a hard time believing that this has ever been done at a
major web site.  The processing of SOAP messages must suck up all the
server's resources when you are handeling high loads.

Thomas.

----- Original Message -----
From: "Brain, Jim" <JBrain@Aegonusa.com>
To: <axis-user@ws.apache.org>
Sent: Thursday, April 24, 2003 6:00 PM
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
> Java)
>
> 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
> whatever.
>
> 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
> logic.
> * 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
> written)
> * 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
>
>
>
>
>
> Jim Brain, jbrain@aegonusa.com
> "Researching tomorrow's decisions today."
> (319) 369-2070 (work)
> SYSTEMS ARCHITECT, ITS, AEGON FINANCIAL PARTNERS
>
>  -----Original Message-----
> From: Kevin.Bedell@sunlife.com [mailto:Kevin.Bedell@sunlife.com]
> Sent: Thursday, April 24, 2003 10:28 AM
> To: axis-user@ws.apache.org
> 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
> tier
> > (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
> they
> > 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
> option.
>
> 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 -
> Kevin
>
>
>
> --------------------------------------------------------------------------
-
> 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.
> --------------------------------------------------------------------------
-
>
>


Mime
View raw message