Hi, (Specially for the newbie ) We are using Web services in our project & I find that they are simply great. Some important things: PROS 1. Platform independent 2. Language independent (We have ASP & C++ clients connecting to our Java web service) 3. Deploying web serivces(in Axis) is smoooth. CONS 1. We are using Axis which has some difficult XML tags 2. For a starter, the initial learning curve is a little high.
For Language independent, I feel its idea is come from COBRA, because COBRA did the same thing, as well as EJBs. However, what Web services is trying to provide is, data are in XML format that is transmited via HTTP, without other specific protocols, like IIOP in COBRA and RMI over IIOP in EJB. I think this is the most beauty thing. Nick.
I am new to web services but have a good background in J2EE. I used portable XML for data transfer thro' HTTP in many projects and they can be parsed by any language.
Based on the doc, the core webservices also working in the same way. Can you pls explain what is the real difference & advantages of web services over this XML over HTTP ?
Originally posted by Mohamed Yasin: Can you pls explain what is the real difference & advantages of web services over this XML over HTTP ?
Web services standards give you a lot of tools and products that work together out of the box. If you have designed your own HTTP/XML protocol for communication, you'll need a miracle to find a tool that happens to support your particular XML schema...
The downside to this standardization is that it brings a certain level of complexity regardless of how simple your custom XML stuff would be. SOAP's verbosity also makes for slightly worse performance compared to XML-RPC or custom HTTP/XML solutions, for example.
Originally posted by Nicholas Cheung: /.../ However, what Web services is trying to provide is, data are in XML format that is transmited via HTTP, without other specific protocols, like IIOP in COBRA and RMI over IIOP in EJB.
I think this is the most beauty thing.
Nick.
HTTP is also a specific protocol, originally designed for file transfer.
What is the beauty of using this instead of other specific protocols, originally designed for inter-system (inter-process) method calls?
Originally posted by Dan Johnsson: HTTP is also a specific protocol, originally designed for file transfer.
What is the beauty of using this instead of other specific protocols, originally designed for inter-system (inter-process) method calls?
There's no doubt that HTTP is less than perfect, but it's good enough to support most of what we need and because it's so ubiquitous, there's little reason not to use it.
Originally posted by Nicholas Cheung: For Language independent, I feel its idea is come from COBRA, because COBRA did the same thing, as well as EJBs.
However, what Web services is trying to provide is, data are in XML format that is transmited via HTTP, without other specific protocols, like IIOP in COBRA and RMI over IIOP in EJB.
I think this is the most beauty thing.
Nick.
There is no beuty in web service unless it's providing a beutifull API to code.But it can be a harm also if webservice technology is new.Coz maybe "BUGS" will be there.
The beuty of a webservice is it's API and how carefull and developer friendly the API is,all of the rest can be accomplished by both XML over HTTP also.
But i choose webservice for my present work instead of "conventional"
Client view <---> Servlet controller <---> Data Access layer Model <----> Databasemodel.
I'll tell you how good it is after completing it [ June 01, 2004: Message edited by: Murasoli Maran ]
Originally posted by Lasse Koskela: There's no doubt that HTTP is less than perfect, but it's good enough to support most of what we need and because it's so ubiquitous, there's little reason not to use it.
That might well be (i e "another discussion"), but I do not see the claimed beauty in it.
i like web service too but the question is that if i can achieve the same thing by implementing a normal servlet (via an http post), what would be the extra justifications i need to embrace web service?
Originally posted by H Rice: what would be the extra justifications i need to embrace web service?
Interoperability is the core concept of Web Service. It can fill up the gaps among M$ tech, J2EE and others... If u don't have any foundation on web services, I would suggest you to have a look at Richard's J2EE Web Services book from Addison-Wesley...
Originally posted by H Rice: Posted a question before i found this post.
i like web service too but the question is that if i can achieve the same thing by implementing a normal servlet (via an http post), what would be the extra justifications i need to embrace web service?
Yes , you could do that using HTTP post but wouldn't that solution of yours be proprietary?
Originally posted by Pradeep Bhat: If JMS is the transport protocol, is it required that the implementing technology be JAVA?
JMS is an API, not a protocol. In other words, the "JMS transport" means that the product in question supports writing web service endpoints which (under the hood) listen to a messaging queue through the JMS API. How those messages end up into that queue is irrelevant.
If Web service is the best, then what abt its security??? If we use SSL, then the system will be slow.... is there any effective and good performance securiy level for web services.
Security usually involves added cost in performance, whether your talking about using a fifteen character password or data validation. I don't think of web services as more or less secure than any other network transaction. With regards to web services, I would think the important part is data validation and hardening on the back end.
SSL performance hits will probably affect you regardless of whether you're using web services or some other architecture to transfer data.
Interoperability is the core concept of Web Service.
Thanks for the book recommendation. My book was old - Web Services essential by Ethan Cerami :-(
Anyway, I have done the basic foundation - done two web services already using Axis. Interoperability is not really a concern as we controlled the environment - although some of the apps were developed in Italy, others were done in UK, HK, and Australia; all of us are using weblogic/Axis (i.e. a Java shop). The things that are in my mindset are ... 1) "logically" I am designing a B2B solution (i.e. app - to app); hence the path to web service. 2) easier to debug (as we are tracing the full thingy) 3) we already have a trend of implementing web services in other components.
However, I can't remove from my mind that implementing an http post is easier (esp for the junior programmers).
Post by:autobot
On my planet I'm considered quite beautiful. Thanks to the poetry in this tiny ad:
a bit of art, as a gift, the permaculture playing cards
![[Logo]](/templates/default/mobile/images/mobile-moose.gif)
