Web Services Tutorial
• Define Service Oriented Architecture (SOA)
• Define Web services
• Take a look at the advantages that SOA based systems provide
• Introduce the Web Services Stack
• Discuss the W3C and WS-I groups and understand what they are doing to standardize Web Services
Web Services have exploded in popularity and become a standard enterprise feature. The advantages provided by
SOAP and the web services stack of technologies have produced a new way of exposing software components and
has given rise to Service Oriented Architecture (SOA). SOA fundamentally changes the way that IT teams design
their applications and establishes an environment of reuse. The rise of SOA is largely possible due to the
established, and still emerging, techniques for passing SOAP messages, establishing security, routing and other basic
messaging needs.
In this tutorial we will take a look at what SOA is and investigate the pertinent ideas and specs needed to create web
service applications. We will instigate several additions to the SOAP message specification to understand what
technology is available and emerging.
Service Oriented Architecture (SOA)
SOA is an architectural style or way to build software applications.
- A way of integrating software applications or application elements.
- A style whose goal is to achieve loose coupling among the interacting application elements.
- Applications can request services of each other without regard to characteristics of the requester – fewer
assumptions.
Conceptually, SOA is based on software serving one of three roles.
- Provider of a service
- Registry (or broker) of a service – managing the list of providers for requestors.
- Requestor of services
On this basis, SOA can be used to integrate applications, or it can also be used to build a distributed application
comprised of services. In fact, SOA can blur the line between integration and distributed applications. The process
of developing an application on top of a SOA resembles building a distributed application.
SOA, along with loose coupling, usually applies a few other principles to the software. Protocol-independent:
Multiple protocols can transparently access a given service. Services are location-agnostic. A given service typically
performs a composite form of business logic and returns the result in a single call. Services are coarse-grained and
maintain no user state: clients don’t have to make a second call to the same location to get the job done. Services can
be accessed in the same manner no matter their location.
Choosing SOA architecture has distinct advantages. SOA offers cost savings by promising more code reuse. The
detail of how those “services” are implemented is hidden from the consumer (client/user) of the service. Providing
more flexibility and fewer maintenance issues. How a client interacts with the service can be defined and published.
Removing the need for direct coordination with all the clients.
Service Oriented Architecture is a way of creating systems that is seeing wide adoption and increased popularity.
Defining SOA is not a difficult concept to get, but there are several different angles that can be taken. Here are a few
published definitions of SOA.
The W3C defines SOA as:
“A set of components which can be invoked, and whose interface descriptions can be published and
discovered.”
From Hao He publishing for O’Reilly we get: (found at http://www.xml.com/pub/a/ws/2003/09/30/soa.html)
“SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents.”
A more casual-reader friendly definition can be found in Preston Gralla’s definition written for the Web Services
Advisor (found at http://searchwebservices.techtarget.com, sign up required)
“SOA is kind of an IT manager's holy grail, in which software components can be exposed as services on the
network, and so can be re-used time and time again for different applications and purposes.”
David Sprott and Lawrence Wilkes site the CBDI definition of SOA (found at http://msdn.microsoft.
com/architecture/soa/default.aspx?pull=/library/en-us/dnmaj/html/aj1soa.asp#aj1soa_topic3)
“The policies, practices, frameworks that enable application functionality to be provided and consumed as sets
of services published at a granularity relevant to the service consumer. Services can be invoked, published and
discovered, and are abstracted away from the implementation using a single, standards-based form of interface.”
SOA and Web Services
Web services and SOA are thought of synonymously. They are related but not the same. Web service is a form of
SOA implementation. A form of SOA that has request for services done typically (but not required) across the
Internet. SOA doesn’t require Web services. Web services is a set of implementation standards around service
oriented architectures.
SOA is not a new idea, it has been tried before with varying levels of success. CORBA, for example, was used to
create a “component reuse” and could be used to create SOA, but CORBA did not become dominant. Web service
technology and standards have emerged to support a new form of SOA. The rise of Web services has made SOA
easier to create.
Is SOA another component reuse scheme? Is it the same as Component Based Architecture? SOA brings a change
of how you think about reuse. Component thinking is very OO related and can result in “chatty” or “finely grained”
interfaces. SOA is more consumer oriented; focusing on a job to be completed. SOA views the relationship between
client and service as a passing of messages instead of an invoking of methods.
• Define Service Oriented Architecture (SOA)
• Define Web services
• Take a look at the advantages that SOA based systems provide
• Introduce the Web Services Stack
• Discuss the W3C and WS-I groups and understand what they are doing to standardize Web Services
Web Services have exploded in popularity and become a standard enterprise feature. The advantages provided by
SOAP and the web services stack of technologies have produced a new way of exposing software components and
has given rise to Service Oriented Architecture (SOA). SOA fundamentally changes the way that IT teams design
their applications and establishes an environment of reuse. The rise of SOA is largely possible due to the
established, and still emerging, techniques for passing SOAP messages, establishing security, routing and other basic
messaging needs.
In this tutorial we will take a look at what SOA is and investigate the pertinent ideas and specs needed to create web
service applications. We will instigate several additions to the SOAP message specification to understand what
technology is available and emerging.
Service Oriented Architecture (SOA)
SOA is an architectural style or way to build software applications.
- A way of integrating software applications or application elements.
- A style whose goal is to achieve loose coupling among the interacting application elements.
- Applications can request services of each other without regard to characteristics of the requester – fewer
assumptions.
Conceptually, SOA is based on software serving one of three roles.
- Provider of a service
- Registry (or broker) of a service – managing the list of providers for requestors.
- Requestor of services
On this basis, SOA can be used to integrate applications, or it can also be used to build a distributed application
comprised of services. In fact, SOA can blur the line between integration and distributed applications. The process
of developing an application on top of a SOA resembles building a distributed application.
SOA, along with loose coupling, usually applies a few other principles to the software. Protocol-independent:
Multiple protocols can transparently access a given service. Services are location-agnostic. A given service typically
performs a composite form of business logic and returns the result in a single call. Services are coarse-grained and
maintain no user state: clients don’t have to make a second call to the same location to get the job done. Services can
be accessed in the same manner no matter their location.
Choosing SOA architecture has distinct advantages. SOA offers cost savings by promising more code reuse. The
detail of how those “services” are implemented is hidden from the consumer (client/user) of the service. Providing
more flexibility and fewer maintenance issues. How a client interacts with the service can be defined and published.
Removing the need for direct coordination with all the clients.
Service Oriented Architecture is a way of creating systems that is seeing wide adoption and increased popularity.
Defining SOA is not a difficult concept to get, but there are several different angles that can be taken. Here are a few
published definitions of SOA.
The W3C defines SOA as:
“A set of components which can be invoked, and whose interface descriptions can be published and
discovered.”
From Hao He publishing for O’Reilly we get: (found at http://www.xml.com/pub/a/ws/2003/09/30/soa.html)
“SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents.”
A more casual-reader friendly definition can be found in Preston Gralla’s definition written for the Web Services
Advisor (found at http://searchwebservices.techtarget.com, sign up required)
“SOA is kind of an IT manager's holy grail, in which software components can be exposed as services on the
network, and so can be re-used time and time again for different applications and purposes.”
David Sprott and Lawrence Wilkes site the CBDI definition of SOA (found at http://msdn.microsoft.
com/architecture/soa/default.aspx?pull=/library/en-us/dnmaj/html/aj1soa.asp#aj1soa_topic3)
“The policies, practices, frameworks that enable application functionality to be provided and consumed as sets
of services published at a granularity relevant to the service consumer. Services can be invoked, published and
discovered, and are abstracted away from the implementation using a single, standards-based form of interface.”
SOA and Web Services
Web services and SOA are thought of synonymously. They are related but not the same. Web service is a form of
SOA implementation. A form of SOA that has request for services done typically (but not required) across the
Internet. SOA doesn’t require Web services. Web services is a set of implementation standards around service
oriented architectures.
SOA is not a new idea, it has been tried before with varying levels of success. CORBA, for example, was used to
create a “component reuse” and could be used to create SOA, but CORBA did not become dominant. Web service
technology and standards have emerged to support a new form of SOA. The rise of Web services has made SOA
easier to create.
Is SOA another component reuse scheme? Is it the same as Component Based Architecture? SOA brings a change
of how you think about reuse. Component thinking is very OO related and can result in “chatty” or “finely grained”
interfaces. SOA is more consumer oriented; focusing on a job to be completed. SOA views the relationship between
client and service as a passing of messages instead of an invoking of methods.
Web Services Tutorial
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any copying is strictly prohibited.
online learning aid. Any copying is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials
Services
