SERVICE-ORIENTED ARCHITECTURE

SOA
• Service-Oriented Architecture (SOA) is a stage in the evolution of
application development and/or integration.
• It defines a way to make software components reusable using the
interfaces.
• Formally, SOA is an architectural approach in which applications
make use of services available in the network.
• It is a mechanism that enables organizations to facilitate
communication between systems running on multiple platforms
through a network call over the internet.
• SOA is a collection of well defined services, each individual service
can be modified independently of other services to help respond to
the ever evolving market conditions of a business.
• Each service in SOA is a complete business function in itself. SOA-
based computing, packages functionalities into a set of
interoperable services, which can be integrated into different
software systems belonging to separate business domains.
 SOA contd…
• SOA presents a big picture of what you can do with web services.
• A web service is a standard representation for some computational or
information resource that can be used by other programs. These may be
information resources, such as a parts catalog; computer resources, such as a
specialized processor; or storage resources.
• The essence of a service, therefore, is that the provision of the service is
independent of the application using the service. Service providers can
develop specialized services and offer these to a range of service users from
different organizations.
• Service-oriented architectures (SOAs) are a way of developing distributed
systems where the system components are stand-alone services, executing on
geographically distributed computers.
• Standard XML-based protocols, such as SOAP and WSDL, have been designed
to support service communication and information exchange. Consequently,
services are platform and implementation-language independent.
• Software systems can be constructed by composing local services and external
services from different providers, with seamless interaction between the
services in the system.
 Roles within Service-oriented Architecture
• Service provider: Service providers design and implement services and
specify the interface to these services. They maintain the service and the
organization that makes available one or more services for others to use. To
advertise services, the provider can publish them in a registry, together with
a service contract that specifies the nature of the service, how to use it, the
requirements for the service, and the fees charged.
• Service consumer/Requestor: (sometimes called service clients) who wish
to make use of a service discover the specification of that service and locate
the service provider. They can locate the service metadata in the registry and
develop the required client components to use the service by binding their
application to that specific service and communicate with it, using standard
service protocols.
 Services as reusable components
• Services are a natural development of software components where the
component model is, in essence, a set of standards associated with web
services. A service can therefore be defined as the following: A loosely-
coupled, reusable software component that encapsulates discrete
functionality, which may be distributed and programmatically accessed. A
web service is a service that is accessed using standard Internet and
XMLbased protocols.
• Services have a ‘provides’ interface that allows access to the service
functionality, they do not have a ‘requires’ interface that, in CBSE, defines
the other system components that must be present.
• Services communicate by exchanging messages, expressed in XML, and
these messages are distributed using standard Internet transport protocols
such as HTTP and TCP/IP.
• A service defines what it needs from another service by setting out its
requirements in a message and sending it to that service. The receiving
service parses the message, carries out the computation and, on
completion, sends a reply, as a message, to the requesting service. This
service then parses the reply to extract the required information.
 Services as reusable components contd…

• Unlike software components, services do not use remote procedure or

method calls to access functionality associated with other services.
When you intend to use a web service, you need to know where the
service is located (its URI) and the details of its interface. These are
described in a service description expressed in an XML-based language
called WSDL.
• The WSDL specification defines three things about a web service: what
the service does, how it communicates, and where to find it:
– o The ‘what’ part of a WSDL document, called an interface, specifies what
operations the service supports, and defines the format of the messages that
are sent and received by the service.
– o The ‘how’ part of a WSDL document, called a binding, maps the abstract
interface to a concrete set of protocols. The binding specifies the technical
details of how to communicate with a web service.
– o The ‘where’ part of a WSDL document describes the location of a specific
 SOA Protocols and Standandization

• There has been an active standardization process for SOA, working alongside
technical developments. All of the major hardware and software companies
are committed to these standards. As a result, SOA have not suffered from the
incompatibilities that normally arise with technical innovations, where
different suppliers maintain their proprietary version of the technology.
• Because of this early standardization, problems, such as the multiple
incompatible component models in CBSE, have not arisen in service-oriented
system development.
• Web service protocols cover all aspects of SOAs, from the basic mechanisms
for service information exchange (SOAP) to programming language standards
(WS-BPEL). These standards are all based on XML, a human and machine-
readable notation that allows the definition of structured data where text is
tagged with a meaningful identifier. XML has a range of supporting
technologies, such as XSD for schema definition, which are used to extend and
manipulate XML descriptions.
• Some of the key standards that have been established to support web services
are below:
Web services standards

• SOAP(Simple Object Access Protocol): This is a

message interchange standard that supports
the communication between services. It
defines the essential and optional components
of messages passed between services.
• WSDL: The Web Service Definition Language
(WSDL) is a standard for service interface
definition. It sets out how the service
operations (operation names, parameters, and
their types) and service bindings should be
defined.
• WS-BPEL: The Web Service Business Process
Execution Language is a standard for a
workflow language that is used to define
process programs involving several different
services.
 Web services standards

• A service discovery standard, UDDI, was also proposed but this has not been
widely adopted. The UDDI (Universal Description, Discovery and Integration)
standard defines the components of a service specification, which may be used
to discover the existence of a service. These include information about the
service provider, the services provided, the location of the WSDL description of
the service interface, and information about business relationships.
Improvements in search engine technology have made UDDI registries
redundant. Service discovery using a standard search engine to search for
appropriately commented WSDL descriptions is now the preferred approach for
discovering external services.
 SOA Standards
• The principal SOA standards are supported by a range of supporting
standards that focus on more specialized aspects of SOA. There are a very
large number of supporting standards because they are intended to
support SOA in different types of enterprise application. Some examples
of these standards include the following:
• WS-Reliable Messaging, a standard for message exchange that ensures
messages will be delivered once and once only.
• WS-Security, a set of standards supporting web service security including
standards that specify the definition of security policies and standards
that cover the use of digital signatures.
• WS-Addressing, which defines how address information should be
represented in a SOAP message.
• WS-Transactions, which defines how transactions across distributed
services should be coordinated.
 Standards contd….

• Current web services standards have been criticized as being ‘heavyweight’ standards that are
over-general and inefficient. Implementing these standards requires a considerable amount of
processing to create, transmit, and interpret the associated XML messages. For this reason, some
organizations, such as Amazon, use a simpler, more efficient approach to service communication
using so-called RESTful services.
• REST (REpresentational State Transfer) is an architectural style based on transferring
representations of resources from a server to a client. It is the style that underlies the web as a
whole and has been used as a much simpler method than SOAP/WSDL for implementing web
services.
• A RESTful web service is identified by its URI (Universal Resource identifier) and communicates
using the HTML protocol. It responds to HTML methods GET, PUT, POST, and DELETE and returns a
resource representation to the client. Simplistically, POST means create, GET means read, PUT
means update, and DELETE means delete.
• RESTFul services involve a lower overhead than so-called ‘big web services’ and are used by many
organizations implementing service-based systems that do not rely on externally provided services.
• The RESTful approach supports efficient service interaction but it does not support enterprise-
level features such as WS-Reliability and WS-Transactions.
• Building applications based on services allows companies and other organizations to cooperate and
make use of each other’s business functions. Thus, systems that involve extensive information
exchange across company boundaries, such as supply chain systems where one company orders
goods from another, can easily be automated. Service-based applications may be constructed by
linking services from various providers using either a standard programming language or a
specialized workflow language.
 SOA Interaction Patterns

• SOAs are loosely coupled architectures where service

bindings can change during execution. This means that a
different, but equivalent version of the service may be
executed at different times. Some systems will be solely
built using web services and others will mix web services
with locally developed components.
• Services might aggregate information and data retrieved
from other services or create workflows of services to
satisfy the request of a given service consumer. This
practice is known as service orchestration
• Another important interaction pattern is service
choreography, which is the coordinated interaction of
services without a single point of control.
Components of SOA
 Guiding Principles of SOA
• Standardized service contract: Specified through one or more service
description documents.
• Loose coupling: Services are designed as self-contained components,
maintain relationships that minimize dependencies on other services.
• Abstraction: A service is completely defined by service contracts and
description documents. They hide their logic, which is encapsulated within
their implementation.
• Reusability: Designed as components, services can be reused more
effectively, thus reducing development time and the associated costs.
• Autonomy: Services have control over the logic they encapsulate and, from
a service consumer point of view, there is no need to know about their
implementation.
• Discoverability: Services are defined by description documents that
constitute supplemental metadata through which they can be effectively
discovered. Service discovery provides an effective means for utilizing third-
party resources.
• Composability: Using services as building blocks, sophisticated and complex
operations can be implemented. Service orchestration and choreography
provide a solid support for composing services and achieving business goals.
 Advantages of SOA
• Service reusability: In SOA, applications are made from existing
services. Thus, services can be reused to make many applications.
• Easy maintenance: As services are independent of each other they
can be updated and modified easily without affecting other services.
• Platform independent: SOA allows making a complex application by
combining services picked from different sources, independent of
the platform.
• Availability: SOA facilities are easily available to anyone on request.
• Reliability: SOA applications are more reliable because it is easy to
debug small services rather than huge codes
• Scalability: Services can run on different servers within an
environment, this increases scalability
 Disadvantages of SOA
• High overhead: A validation of input parameters of
services is done whenever services interact this
decreases performance as it increases load and
response time.
• High investment: A huge initial investment is required
for SOA.
• Complex service management: When services interact
they exchange messages to tasks. the number of
messages may go in millions. It becomes a cumbersome
task to handle a large number of messages.
 Practical applications of SOA
SOA is used in many ways around us whether it is mentioned
or not.
• SOA infrastructure is used by many armies and air forces to
deploy situational awareness systems.
• SOA is used to improve healthcare delivery.
• Nowadays many apps are games and they use inbuilt
functions to run. For example, an app might need GPS so it
uses the inbuilt GPS functions of the device. This is SOA in
mobile solutions.
• SOA helps maintain museums a virtualized storage pool for
their information and content.
 Service-oriented and component-oriented
software engineering
• Services and components obviously have much in common. They are both
reusable elements and it is possible to think of a component as a provider of
services. However, there are important differences between services and
components, and between a service-oriented and a component oriented
approach to software engineering.
• A service-oriented approach to software engineering is a newer software
engineering paradigm that is, as important a development as object-oriented
software engineering. This paradigm shift is accelerated by the development of
‘cloud computing’, where services are offered on a utility computing
infrastructure hosted by major providers, such as Google, Amazon, Microsoft.
This has had and will continue to have profound effects on systems products and
business processes.
• With the emergence of systems such as Google Apps and Salesforce.com,
service-oriented approaches at both the application and the implementation
level means that the Web is evolving from an information store to a systems
implementation platform.
 Service engineering
• Service engineering is the process of developing services for reuse in service
oriented applications. It has much in common with component engineering.
• Service engineers have to ensure that the service represents a reusable
abstraction that could be useful in different systems. They must design and
develop generally useful functionality associated with that abstraction and
ensure that the service is robust and reliable.
• They have to document the service so that it can be discovered and understood
by potential users.
• There are three logical stages in the service engineering process:
– 1. Service candidate identification, where you identify possible services that might be
implemented and define the service requirements.
– 2. Service design, where you design the logical and WSDL service interfaces.
– 3. Service implementation and deployment, where you implement and test the service
and make it available for use.