This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
I am just starting with web services,and I was reading a few introductory articles on the net. What I wanted to know was under which situations would it be better/imperative to use web services when compared to server side scripting. One of the links I visited gave the example of a digital library with functions such as keyword searching,advanced searching (http://www.ariadne.ac.uk/issue29/gardner/). But can't this be implemented using any server side scripting language which can connect to a database?
(Please excuse me if this question seems annoying,but I am really confused about the role of web services).
Lets say Company A uses Microsoft technology, and Company B uses Java.
Now Company B will allow Company to call one of its services (like a remote method call). How will company A call company B?
Before Web Services, the popular answer will be CORBA. It allows 2 different platforms to communicate, using its (very complicated) proprietary technologies.
Now what if I tell you that XML can do the same in a much more human-friendly or programmer-friendly way? That is what we call Web Services.
Joined: Feb 16, 2007
Ok,I understand their use in Application to Application communication,which one of the links referred to as B2B.But what about user to application communication,which the link referred to as B2C.
For example,in our university,the software made for course registration was done using web services.The basic function of it was a web based form,in which the student had to select courses,and then click submit to store in the database. Now why are web services required in this? This could have been made using a combination of JSP and JDBC right?
The question is not so much "could it have been done without a WS", it is more like "what do you gain by implementing it as a WS". Both examples you cite -library and course registration- can be implemented as web apps, usable by human beings working with a web browser. But I can easily imagine other client applications for both cases, where the user is not a human being with a web browser, but a computer program running unattended. In that case, having a system that returns a web page is of little or no use. But if I design the system with a WS interface, then I can use it in different ways through different clients (one of them being to layer a web GUI on top of it).
Actually, your question is also my question when I was starting to learn web services.
Are you familiar with RMI? remote methods? You do remote method calls using RMI over protocols such as JRMP(java to java) or RMI-IIOP(using CORBA).
Web services is very similar.
You do remote method calls using Web services(any to any using XML) over protocols such as SOAP.
As you will notice, a web service is a service. It is built to service something. It is not a full application. [ August 22, 2007: Message edited by: Jesus Angeles ]
Joined: Mar 22, 2005
In response to Jesus, it should be noted that web services have started out mostly as a platform-independent RPC mechanism. But they have since taken a turn towards a more document-centric view of the world, and are being used more and more to exchange XML documents. In that case the payload isn't an XML-ified method name with parameters (and the response the result of that method call), but an XML document that contains some data and/or instructions what to with it. The server has to do more work in this scenario, but it offers more flexibility as well.
Joined: Feb 26, 2005
For an architect or designer, and also for beginners, it is easier to classify web services as a form of remote method system - whether it is asynchronous or not, document or rpc, etc.
Originally posted by Jesus Angeles: It is easier to classify web services as a form of remote method system
However this over-simplification also leads some beginners to always treat web services as yet another RPC or component level distribution mechanism which unnecessarily constrains the "modus operandi". Sometimes an RPC interface is appropriate (as long as you avoid unnecessary chatty-ness). However at its most general you can submit and/or retrieve an "aggregation of data" to/from a web service. That "aggregation of data" doesn't follow object-oriented principles or even relational principles. If the data is represented in XML it will more likely be hierarchical in nature. So that "aggregation of data" should be viewed at least as a message, possibly even as a document. [ August 23, 2007: Message edited by: Peer Reynders ]
What about if a web service method is looking for specific java objects (for instance, a collection) as parameters? Could a microsoft or non-java client still consume the service?
Joined: Aug 19, 2005
Originally posted by Tom Griffith: What about if a web service method is looking for specific java objects (for instance, a collection) as parameters? Could a microsoft or non-java client still consume the service?
There is no guarantee that both sides have equivalent objects, collections, etc. In fact you can't even assume that all the parties involved are object-oriented. So trying to exchange objects is generally a bad idea - especially if you are trying to be interoperable.
When exchanging data in XML the closest equivalent to a collection of objects (as defined by XML Schema) is a sequence of complex types. How either the web service or the web service client interpret that data structure is entirely their own business. Another mundane example is date/time - XML Schema has a build-in simple type dateTime with uses ISO-8601 conventions. A Java application may convert it to java.util.Calendar or java.util.Date, while a .NET application might convert it to a system.datetime structure. It would be however ludicrous to suggest that java.util.Calendar (object) is identical to the .NET system.datetime (structure).
That's why it is important to design the service contract in the domain in which the data is exchanged - so if the data is exchanged as XML then the service definition should describe the exchanged data with XML Schema (which is what WSDL does). Creating the service definition in the domain of service platform just tends to introduce unnecessary problems which usually includes an overly obscure client-facing (WSDL) service definition (ever tried to make sense of a WSDL based on a .NET web service that exchanges ADO DataSets?).
It is also usually not appreciated that you are shifting paradigms once you "step through" that web service interface. In the case of a Java-based web services host you are shifting from the object-oriented paradigm to the service-oriented paradigm. While there are some similarities there are also significant differences.
Joined: Aug 06, 2004
Peer, thank you...that was very informative. I've designed web services as well as consumers (via axis WSDL2Java) for specific java-based services but never any ~service~ with a large general audience. One-time, before i worked in java, i had to write a consumer to a java-based service. All the arguments were Strings wrapped in java objects so I took the wsdl and wrote the consumer strictly in xml...mapping in 100 or so strings into the nodes based on wsdl. I always kinda winced at that but in hindsight that appears to be the only recourse at the time.
Joined: Aug 19, 2005
Originally posted by Tom Griffith: (...) so I took the wsdl and wrote the consumer strictly in xml...mapping in 100 or so strings into the nodes based on wsdl. I always kinda winced at that ...
I figure that is why SUN decided to include JAXB in Java EE 5 and Java 6 SE. As an XML binding tool it's not specific to web services but can be quite useful when you are trying to coax an XML application into something that at least resembles your object model without writing too much code by hand. However it is "yet another tool to learn" and just like many other good tools it doesn't relieve you of understanding "the other side" (XML and XML Schema in this case) - but in exchange it can make you more effective (in comparison to hand coding everything).