• Post Reply Bookmark Topic Watch Topic
  • New Topic

Demonstration of Web Services' power

 
Sudharshan Govindan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
We have to give a presentation to our clients on Web Services. Most of the literature on Web Services say that applications hosted as Web Services are better than conventional distributed systems. It also say that "Changes introduced to the Service do not break a Client's ability to use the service". Now changes can be
1.Modification to existing operations/methods
2.Addition of new operations/methods
I need a pseudo-code/sample program that demonstrates the flexible and resilient nature of Web Services architecture. That is, a scenario that will fail in conventional distributed systems when changes are introduced, WILL work fine when implemented as a Web Service. Any help will be greatly appreciated and motivate us to convince our customers of Web Service's power.
Thanks & regards,
Sudharshan Govindan
 
Kyle Brown
author
Ranch Hand
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMHO, this is all hype. Web Services are STILL distributed services. The reason why "experts" say that this is true is because IN THEORY since the information moves over XML that the client app could still process the XML document even though the server uses a slightly different (extended) schema. However, IN PRACTICE this doesn't work since ALL the stub generators (in .NET and in Java both) expect particular XML formats based on the original schema. So, if you remove a value from a message declaration or add one, and then try to use an old stub with a new server, it will break.
Now, if you were using some sort of pure message-based SOAP parser where you took careful pains to handle this case, it could work, but in fact, the existing SOAP engines that I'm familiar with don't handle this case very well.
Bill, are you aware of a SOAP engine that handles this?
Kyle
 
Sudharshan Govindan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the pointers. How else do we convince our clients to go for Web Services ? More or less, Web Services turn out to be an extended version of RPC. Isn't it ?
Regards,
Sudharshan Govindan
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Sudharshan Govindan:
How else do we convince our clients to go for Web Services?

Isn't it funny when we talk about convincing clients to use a technology without knowing how to back up the suggestion...
Well, one factor to consider could be that the Web Services scene is all about standards. One of the benefits of using Web Services (SOAP, WSDL and UDDI) is that they are all based on open standards and they already have considerable vendor support and the client will not face vendor lock-in (in theory).
You could also take a moment to think about the Big Picture behind the magical words, Service-Oriented Architecture. Think about a typical scenario of a distributed set of services using each other by looking them up from a UDDI registry. This architecture can be implemented to take a nuke (almost literally) and still remain functioning as the services are loosely bound via the UDDI registries. The question is, do you need this? Is it worth the trouble of introducing new software and probably wasting more bandwidth/CPU cycles than the existing solution?
Thinking ahead, the client's infrastructure needs to be ready when the awaited <buzzword>Business Integration Boom</buzzword> comes. At that point, having business systems capable of a swift integration according to the industry standards (the likes of RosettaNet) will most probably be key.
I realize this is something that can easily be argued over, but maybe you can grow your consultant pitch from it... The other approach would naturally be "if it works, don't fix it", meaning that for many businesses having the bleeding edge technology rolled-out a few months before the competitor is far from being a priority.
My thoughts. Nothing more.
 
Byron Estes
Ranch Hand
Posts: 313
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I must agree with Kyle. RPC will always be brittle whether you use an static proxy stub, a dynamic proxy or dynamic invocation interface. The bottom line is the service method, it's parameters and it's return value all need to be known. The value of the webservice in this instance cannot shield the users from changes to the interface. It can shield them from implementation, but so can many other distributed technologies. What may be going for this one is that because it can be implemented over http (...it's most common transport protocol), it can be invoked by clients outside your firewall without forcing the network guys to punch additional holes for more ports.
I think as Kyle mentioned, the document oriented webservice could be made a little more resilient, but it assumes that whatever you added or removed from the document is a "optional" piece of information. A decoration if you will that mearly extends the primary data. I think we all need to be careful not to buy into the hype without carefully considering the situation. The hype may be accurate, but only in a very narrowly defined situation. Any deviation from the narrowly defined situation, breaks the model.
Regards,

You brought up a interesting point, one that I wasn't aware of. If an RPC Stub-based proxy would not stand up to the kind of changes you described, what about the use of a Dynamic
 
Kenneth A. Kousen
gunslinger & author
Ranch Hand
Posts: 100
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's an interesting article in this month's JavaPro magazine about integrating .Net programs with J2EE programs. It talks about all the different technologies, but naturally focuses on Web Services.
An interesting point made in the article is that if you're going to call methods over XML, you've got to be aware that not all languages map the fundamental data types the same way (Java has no unsigned integer types; there's no char type in the Schema spec, etc.).
Companies I've been talking to therefore try to make sure all the method calls use either primitives (not unsigned ones, naturally and basic array structures for arguments and return types.
As another aside, I've heard people say that using web services as a way to do RPC just adds another text layer to the stack. A potentially more interesting mode is the asynchronous one, where you send messages to several clients and await responses as they become available.
Here's the link to the JavaPro article:
http://www.fawcette.com/javapro/2003_04/magazine/features/dsavarese/
Ken Kousen
The Golden Consulting Group
kkousen@goldencg.com
(SCJP, SCWCD)
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!