RESTful SOA Using XML

Service Oriented Architecture (SOA) is used in companies that have
large numbers of applications for employees in different departments
with varying responsibilities. Many of these applications share
functionalities, but the combinations of functionalities, user-interface
specifics, and usability requirements differ. Like many enterprise
architectures, SOA follows a multitier model, but it doesn't stop there.
Within the server, functionalities are divided over separate services.
A client can consume one or more of the services, and one service can
be consumed by many clients. The result is a loosely coupled architecture
that propagates the reusability of existing software. SOA fits
particularly well in large companies that have several hundred poorly
integrated applications and that need to clean up their IT
infrastructures. SOA is a proven practice, capable of working effectively
in large environments. Adapters can to translate legacy applications to
services that integrate as backends to modern applications. Middleware
technology is available to orchestrate services and control access to
specific functionalities in the service. Because the need for SOAs is
highest in this area, vendors of middleware technology typically focus
their products toward large and heavyweight solutions. Usually, SOA is
implemented with the SOAP protocol, described by a Web Services
Description Language (WSDL) document. Although many developer tools make
it relatively easy to work with SOAP and WSDL, I consider them heavyweight
technology, because they're hard to work with if you don't use those
tools. You can implement SOA just as well by sending simple messages
over Hypertext Transfer Protocol (HTTP). Basically, this is what RESTful
Web services do. Representational State Transfer (REST; the name was
coined by Roy Fielding) isn't a protocol or technology: It's an
architectural style. REST, a lightweight alternative to SOAP, is resource
oriented rather than action oriented. It's often summarized as bringing
back remote procedure calls to GET, POST, PUT, and DELETE statements
using HTTP. In my opinion, this is the second important step. More Information