Example of Web Services
Sunny Malik
Ranch Hand
Posts: 86
pradeep jaladi
Ranch Hand
Posts: 65
Peer Reynders
Bartender
Posts: 2968
6
posted 9 years ago
Starting Out and Confusion in writing web service client + jax-ws
However those don't necessarily explain why you would want to use web services.
SOAP web services came into existence because of the realization that in many cases distributing components causes too much overhead
and that reuse might make more sense on the application level. On top of that a protocol that used HTTP and XML (i.e. text) could pass through firewalls unimpeded - something that other RPC protocols could not. This created the opportunity for people struggling to integrate distributed heterogeneous systems (which usually are under the control of different business owners) to get these systems to (automatically) work together to accomplish business goals (i.e. implement large scale business processes). Now these applications are called "services". This gave Services-Oriented Architecture (SOA) additional momentum. These services are "web services" because the are accessed over the web with the HTTP protocol. SOA predates web services and is independent of web services - however SOAP-based web services are technologies that enable SOA and as such, most SOA vendors use SOAP web services. For the most part SOAP is mainly an XML-message-based interface technology.
Example: Your inventory control application detects that the stock of a certain product dropped below reorder levels. If the supplier supports a purchase order web service, the inventory application can submit a (XML) purchase order for the minimum order quantity of the product. If the submission was successful the inventory application marks the stock as on order. It would also store a correlation identifier that it obtained from the web service so that it can query the status of the purchase order later from the PO web service - allowing it to track the progress of this "long lasting business transaction" - possibly to the point where the order is unpacked in the stock receiving room ... all automatically.
Before web services this was usually accomplished through Electronic Data Interchange (EDI).
The objectives of REST web services are much simpler - make the web more machine accessible (and more interconnected just like the human web) in a way that makes sense with the pre-existing infrastructure and protocols (HTTP in particular) and the model of manipulating resource state through a uniform interface is a good fit. As it happens some people think that REST web services are also a good fit for data services in an SOA. (REST 'ideally suited' for SOA-style data services � Burton)
Also see the web service faq
[ April 04, 2008: Message edited by: Peer Reynders ]
Originally posted by pradeep jaladi:
Please check the posting "starting out" which is posted on posted Monday, February 18, 2008 2:16 PM.
Starting Out and Confusion in writing web service client + jax-ws
However those don't necessarily explain why you would want to use web services.
SOAP web services came into existence because of the realization that in many cases distributing components causes too much overhead
Martin Fowler (PEAA p.89) First Law of Distributed Object Design: Don't distribute your objects!
and that reuse might make more sense on the application level. On top of that a protocol that used HTTP and XML (i.e. text) could pass through firewalls unimpeded - something that other RPC protocols could not. This created the opportunity for people struggling to integrate distributed heterogeneous systems (which usually are under the control of different business owners) to get these systems to (automatically) work together to accomplish business goals (i.e. implement large scale business processes). Now these applications are called "services". This gave Services-Oriented Architecture (SOA) additional momentum. These services are "web services" because the are accessed over the web with the HTTP protocol. SOA predates web services and is independent of web services - however SOAP-based web services are technologies that enable SOA and as such, most SOA vendors use SOAP web services. For the most part SOAP is mainly an XML-message-based interface technology.
Example: Your inventory control application detects that the stock of a certain product dropped below reorder levels. If the supplier supports a purchase order web service, the inventory application can submit a (XML) purchase order for the minimum order quantity of the product. If the submission was successful the inventory application marks the stock as on order. It would also store a correlation identifier that it obtained from the web service so that it can query the status of the purchase order later from the PO web service - allowing it to track the progress of this "long lasting business transaction" - possibly to the point where the order is unpacked in the stock receiving room ... all automatically.
Before web services this was usually accomplished through Electronic Data Interchange (EDI).
The objectives of REST web services are much simpler - make the web more machine accessible (and more interconnected just like the human web) in a way that makes sense with the pre-existing infrastructure and protocols (HTTP in particular) and the model of manipulating resource state through a uniform interface is a good fit. As it happens some people think that REST web services are also a good fit for data services in an SOA. (REST 'ideally suited' for SOA-style data services � Burton)
Also see the web service faq
[ April 04, 2008: Message edited by: Peer Reynders ]
| It is sorta covered in the JavaRanch Style Guide. |