[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: What does SOAP really add?

• To: "Joshua Allen" <joshuaa@m...>,"Simon St.Laurent" <simonstl@s...>,<xml-dev@l...>
• Subject: RE: What does SOAP really add?
• From: "Dare Obasanjo" <dareo@m...>
• Date: Sun, 21 Apr 2002 12:31:44 -0700
• Thread-index: AcHpX5F6rvm5V/3KQ7G9hsfi8+hGFwAA8wmQAAFlKiA=
• Thread-topic: What does SOAP really add?

This is the same conclusion I came to but decided that it wasn't a good enough answer because it really doesn't justify the "web" in web services. From your point of view (and mine, I guess)  SOAP adds better interop than existing distributed computing (RPC/message-based) solutions by eliminating many of the complexities (no pass by ref for example ) and being amenable to many off-the-shelf tools because it uses XML. 
 
However, although I see it being likely that many intranet or similarly closed-network applications may begin to utilize SOAP and its family of related technologies instead of DCOM/CORBA/RMI etc. I'm not sure if there really is much applicability to the World Wide Web that isn't toy applications or even worse poor utilizations of the web. 
 
I really need to take a deeper look at SOAP and GxA. Always so much to learn...  

	-----Original Message----- 
	From: Joshua Allen 
	Sent: Sun 4/21/2002 12:06 PM 
	To: Simon St.Laurent; xml-dev@l... 
	Cc: 
	Subject: RE:  What does SOAP really add?
	
	

	> XML-RPC when used in relatively simple and small environments, I have
	> deep qualms about using RPC in general on any large scale over any
	long
	> period of time.  RPC is brittle, breakable, etc. - we've been over
	that
	> before.
	
	> Loose coupling is central to the nature of Web services-based
	> application integration. That's why it seems to me that the right
	model
	> for XML in Web services is a message-oriented, document-based one
	rather
	> than one based on remote procedure calls.
	
	OK, I hope you are reading this wrong.  Bosworth is certainly making a
	point in *favor* of XML message-passing formats like SOAP vs. things
	like RMI, but is in no way making a case for REST.  The
	"loosely-coupled" in this comment comes from async and XML-based
	messages.  This is the Biztalk model.  I'm not saying that Bosworth
	isn't a believer in REST; just that the particular scenario described
	here is not one that REST advocates find terribly comforting.
	
	> there's a notion of a framework worth discussion, but to be honest, I
	> can't see any real benefit. A vocabulary for fault codes? (Okay, a
	> second wave of hype.)
	
	Are you asking what benefit SOAP brings vs. everyone just rolling their
	own XML serialization/envelope formats?
	
	The basic answer is that it allows out-of-box interop (well, usually) so
	things like VS.NET can work with BEA, and BEA can work with Apache, and
	so on.  This doesn't negate the value of loose-coupling -- it is still
	beneficial to do loose-coupled async architectures even if the
	message/document format is not SOAP.  But the fact that 90% of clients
	and servers support automatic SOAP mappings mean that SOAP is a safe bet
	for an XML novice trying to whip up a loosely coupled architecture in a
	hurry.
	
	Furthermore, messages that use SOAP format will presumably be able to
	work with future infrastructure that does WS-Routing, DIME, and so on.
	These other layers of the "protocol stack" have to be able to depend on
	some consistent features, and will naturally target something like SOAP
	rather than try to support every naked XML format that anyone cooks up.
	
	> the same kinds of questions.  Now I wonder if maybe I should just wait
	> for the Web Services hype to fade, and hope that XML (with REST, or
	> something similar) gets a second chance afterward.
	
	Honestly, I think the best way to grok what all of the fuss is about is
	to try building some mock systems with imaginary (but realistic)
	business partners.  Pretend that your company has a PeopleSoft on Oracle
	system you have to talk to, and your boss just bought a BEA Weblogic
	server for your department, and you have to provide aggregated
	information from the PeopleSoft HRMS on-demand to anyone who sends you
	the appropriate JMS message.  Your two main customers are departments
	that use Microsoft SQL Server, so you have to be able to prove interop
	with them (rather than just declare, "it uses XML so it is
	interoperable, as long as those other idiots do the right thing.")
	
	
	
	-----------------------------------------------------------------
	The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
	initiative of OASIS <http://www.oasis-open.org>
	
	The list archives are at http://lists.xml.org/archives/xml-dev/
	
	To subscribe or unsubscribe from this list use the subscription
	manager: <http://lists.xml.org/ob/adm.pl>
	
	

• Follow-Ups:
  • Re: What does SOAP really add?
    • From: "Thomas B. Passin" <tpassin@c...>

• Prev by Date: RE: What does SOAP really add?
• Next by Date: Re: What does SOAP really add?
• Previous by thread: RE: What does SOAP really add?
• Next by thread: Re: What does SOAP really add?
• Index(es):
  • Date
  • Thread