Service-oriented architecture
The Basic
• main concepts
– Service-orientation describes an architecture that
uses loosely coupled services to support the
requirements of business processes and users.
– Resources on a network in an SOA environment are
made available as independent services that can be
accessed without knowledge of their underlying
platform implementation
– a style of information systems architecture that
enables the creation of applications that are built by
combining loosely coupled and interoperable services
SOA
• Services inter-operate based on a formal
definition (or contract, e.g., WSDL)
– independent of the underlying platform and
programming language
• Interface definition hides the implementation of
the language-specific service
• Independent of development technologies and
platforms (such as Java, .NET etc)
• Support integration and consolidation activities
within complex enterprise systems
SOA definitions
• Design for linking business and
computational resources on demand to
achieve the desired results for service
consumers
OASIS (Organization for the Advancement
of Structured Information Standards)
Defiition
A paradigm for organizing and utilizing distributed
capabilities that may be under the control of different
ownership domains. It provides a uniform means to offer,
discover, interact with and use capabilities to produce
desired effects consistent with measurable preconditions
and expectations.
SOA Elements
Why SOA?
• Traditionally, IT works with the business
owners, who are influenced by application
vendors.
– using a point-to-point approach that
connected the application to both upstream
and downstream systems
• may not be integrated into the existing architecture
• Redundant infrastructure solutions
• Impossible and impractical to modify this portfolio
to reflect a change in a business process
Business Problems Impact IT
•
•
•
•
•
Globalization
Economic Pressures
Business Process Outsourcing
Technology
Lack of Cohesive Business Information
Strategy
• Standards
Business Problems Impact IT
• Business and IT operations teams
frequently differ in their approaches
– For example, some business operations
teams prefer to demonstrate “quick wins” to
validate an approach, while IT operations
prefer to build out the infrastructure.
– Fortunately, SOA offers both
Why SOA?
• main drivers
– links computational resources and promotes
their reuse
– help businesses respond more quickly and
cost-effectively to changing market conditions
– style of architecture promotes reuse at the
macro (service) level rather than micro level
(objects)
– simplify interconnection to - and usage of existing IT (legacy) assets
Why SOA?
• Considered an architectural evolution
– Better than a revolution and captures many of the
best practices of previous software architectures
• Different to modular programming (1970s),
event-oriented design (1980s) or
interface/component-based design (1990s)
– SOA separats users (consumers) from the service
implementations
– Services can therefore be run on various distributed
platforms and be accessed across networks
– maximise reuse of services
Service-oriented design and
development (SOAD)
• SOA uses SOAD concept.
• SOAD
– design methodology for developing highlyagile systems in a consumer/producer model
– abstracts implementation from process,
• a service-provider can be modified or changed
without affecting the consumer
Service-oriented design and
development (SOAD)
• Service contract
– Header
• Name - Name of the service
• Version - The version of this service contract
• Owner - The person/team in charge of the service
– RACI
» Responsible - the person/team responsible for the deliverables of
this contract/service.
» Accountable - Ultimate Decision Maker in terms of this
contract/service
» Consulted - Who must be consulted before action is taken
» Informed - Who must be informed that a decision or action is
being taken.
– Type - the type of the service
» Data
» Process
» Functionality
» Presentation
Service-oriented design and
development (SOAD)
– Functional
• Functional Requirement (From Requirements Document)
• Service Operations –
– Methods, actions etc.
– Must be defined in terms of what part of the Functionality it
provides.
• Invocation –
– Indicates the invocation means of the service.
– This includes the URL, interface, etc.
» Examples:
» SOAP
» REST
» Events Triggers
Service-oriented design and
development (SOAD)
– Non-Functional
• Security Constraints –
– Defines who can execute this service in terms of roles or individual
partners, etc.
– which invocation mechanism they can invoke
• Quality of Service –
– Determines the allowable failure rate
• Transactional –
– Is this capable of acting as part of a larger transaction
– and if so, how do we control that?
• Service Level Agreement –
– Determines the amount of latency the service is allowed to have to
perform its actions
• Semantics –
– Defines the meaning of terms used in the description and interfaces of
the service
• Process –
– Describes the process of the contracted service
SOA and Web service protocols
• Web services standards relevant to SOA
– XML
– HTTP (or HTTPS)
– SOAP
– Web Services Description Language (WSDL)
– Universal Description, Discovery, and
Integration (UDDI)
SOA and Web 2.0
• Web 2.0
– Refers to a "second generation" of web sites
– Distinguished by the ability of visitors to contribute
information for collaboration and sharing
– Use Web services and may include Ajax program
interfaces, Web syndication, blogs, and wikis
– no set standards for Web 2.0
• building on the existing web server architecture and using
services
• regarded as displaying some SOA characteristics
The challenges faced in SOA
adoption
• Managing services metadata
– SOA-based environments can include many services
which exchange messages to perform tasks
• E.g., a single application may generate millions of messages
• Provide appropriate levels of security
– Application-managed security is not the right model
for securing services
• Interoperability is another important aspect in
the SOA implementations
Criticisms of SOA
• Some criticisms of SOA are based on the
assumption that SOA is the equivalent of
Web Services
– SOA results in the addition of XML layers
introducing XML parsing and composition
• Applications may run slower and require more
processing power without RPC (Remote
Procedure Calls)
• Increases costs
Criticisms of SOA
• Stateful services
– require both the consumer and the provider to share
the same consumer-specific context
• included in or referenced by messages exchanged between
the provider and the consumer
– may reduce the overall scalability of the service
provider
• because it may need to remember the shared context for
each consumer
– Also increases the coupling between a service
provider and a consumer
• makes switching service providers more difficult
Criticisms of SOA
• WS standards and products are still
evolving
– E.g., transaction, security, etc
– Can thus introduce risk
• Need properly managed and estimated
• Aadditional budget and contingency needed for
additional Proof
SOA Lifecycle Stages
• Initiate SOA
– decide which business function and
underlying processes SOA will enable,
enhance, or even replace.
– The company establishes a project team,
objectives, and timelines & deliverables
– For the purpose to create a roadmap that
combines business and IT efforts
SOA Lifecycle Stages
• Develop Roadmap
– spells out the process for conducting an SOA
assessment
– developing the SOA principles
• define the SOA principles in a clear and concise manner
– defining the reference architecture
• describe the “future state” for the IT organization
• making the transition from the current situation to the future
state.
– define the phases for deploying business solutions
and the infrastructure required to support them.
SOA Lifecycle Stages
• SOA Execution Plan
– describes how to execute towards the SOA
roadmap.
– execute projects in the sequence described in
the roadmap
– build out the infrastructure as required to
provide the business capability
SOA Lifecycle Stages
IBM SOA Lifecycle Stages