You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsif-user@ws.apache.org by Nirmal Mukhi <nm...@us.ibm.com> on 2003/04/24 20:05:27 UTC
RE: Web Services Logical Architecture
Hi,
There's a new article on WSIF available at
http://webservices.devchannel.org
The downloadable code sample link doesn't seem to work right now but
hopefully that'll be fixed soon.
Nirmal.
"Almeida, Timothy" <ti...@firepond.com>
04/24/2003 01:53 PM
Please respond to axis-user
To: "'axis-user@ws.apache.org'" <ax...@ws.apache.org>
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: 'axis-user@ws.apache.org'
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: 'axis-user@ws.apache.org'
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.
---------------------------------------------------------------------------
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
Re: Web Services Logical Architecture
Posted by Steve Lewis <sm...@lordjoe.com>.
One more try - same drill - get from ftp site - run i tsend me the logs
At 01:59 PM 4/24/2003 -0500, you wrote:
>Nirmal Mukhi wrote:
>
>>There's a new article on WSIF available at http://webservices.devchannel.org
>>
>>The downloadable code sample link doesn't seem to work right now but
>>hopefully that'll be fixed soon.
>
>hi,
>
>i have put sample code for article temporarily at this location:
>http://www.extreme.indiana.edu/~aslom/webservices.devchannel.org-article/
>
>thanks,
>
>alek
>
>>
>>
>>Nirmal.
>>
>>
>>
>> *"Almeida, Timothy" <ti...@firepond.com>*
>>
>>04/24/2003 01:53 PM
>>Please respond to axis-user
>>
>>
>> To: "'axis-user@ws.apache.org'" <ax...@ws.apache.org>
>> 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: 'axis-user@ws.apache.org'
>>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: 'axis-user@ws.apache.org'
>>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.
>>---------------------------------------------------------------------------
>>
>>
>>
>>------------------------------------------------------------------------------
>>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
>
>
Steven M. Lewis PhD
Director of Development
Unified Signal Inc.
4221 105th Ave NE
Kirkland, WA 98033
425-889-2694
Re: Web Services Logical Architecture
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Nirmal Mukhi wrote:
> There's a new article on WSIF available at
> http://webservices.devchannel.org
>
> The downloadable code sample link doesn't seem to work right now but
> hopefully that'll be fixed soon.
hi,
i have put sample code for article temporarily at this location:
http://www.extreme.indiana.edu/~aslom/webservices.devchannel.org-article/
thanks,
alek
>
>
> Nirmal.
>
>
>
> *"Almeida, Timothy" <ti...@firepond.com>*
>
> 04/24/2003 01:53 PM
> Please respond to axis-user
>
>
> To: "'axis-user@ws.apache.org'" <ax...@ws.apache.org>
> 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: 'axis-user@ws.apache.org'
> 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: 'axis-user@ws.apache.org'
> 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.
> ---------------------------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> 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
Re: Web Services Logical Architecture
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Nirmal Mukhi wrote:
> There's a new article on WSIF available at
> http://webservices.devchannel.org
>
> The downloadable code sample link doesn't seem to work right now but
> hopefully that'll be fixed soon.
hi,
i have put sample code for article temporarily at this location:
http://www.extreme.indiana.edu/~aslom/webservices.devchannel.org-article/
thanks,
alek
>
>
> Nirmal.
>
>
>
> *"Almeida, Timothy" <ti...@firepond.com>*
>
> 04/24/2003 01:53 PM
> Please respond to axis-user
>
>
> To: "'axis-user@ws.apache.org'" <ax...@ws.apache.org>
> 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: 'axis-user@ws.apache.org'
> 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: 'axis-user@ws.apache.org'
> 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.
> ---------------------------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> 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