(Please excuse me if this question seems annoying,but I am really confused about the role of web services).
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.
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?
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 ]
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 ]
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.
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).