axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: Web Services Logical Architecture
Date Thu, 24 Apr 2003 18:59:07 GMT
Nirmal Mukhi wrote:

> There's a new article on WSIF available at 
> The downloadable code sample link doesn't seem to work right now but 
> hopefully that'll be fixed soon. 


i have put sample code for article temporarily at this location:



> Nirmal.
> 	*"Almeida, Timothy" <>*
> 04/24/2003 01:53 PM
> Please respond to axis-user
>         To:        "''" <>
>         cc:        
>         Subject:        RE: Web Services Logical Architecture
> Frank,
> You should check out WSIF (another Web Services project from Apache).
> As I understand it, it allows the use of a WSDL description to 
> describe a service -- while abstracting one from how the service is 
> implemented/deployed. (So your 'service' implementation could be a 
> local Java object or a remote web service or an EJB.) Also, your 
> client implementation can remain unmodified even while one service 
> implementation is swapped out for another equivalent.
> -----Original Message-----
> From: Zhang, Frank [_mailto:frank_zhang@merck.com_]
> 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?
> Frank
> -----Original Message-----
> From: Brain, Jim [_mailto:JBrain@Aegonusa.com_]
> 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
> 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,
> "Researching tomorrow's decisions today."
> (319) 369-2070 (work)
> -----Original Message-----
> From: [_mailto:Kevin.Bedell@sunlife.com_]
> Sent:   Thursday, April 24, 2003 10:28 AM
> To:
> 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.
> ---------------------------------------------------------------------------
> ------------------------------------------------------------------------------
> 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.
> ------------------------------------------------------------------------------ 

"Mr. Pauli, we in the back are all agreed that your theory is crazy. 
What divides us is whether it is crazy enough to be true." Niels H. D. Bohr

View raw message