ServiceOriented Computing SOC and ServiceOriented Architecture SOA

1
Service-Oriented Computing (SOC) and
Service-Oriented Architecture (SOA)

• W. T. Tsai
• Department of Computer Science and Engineering
• Arizona State University
• Tempe, AZ 85287
• wtsai_at_asu.edu

2
Definition of Service

• A service is a unit of work done by a service
  provider to achieve desired end results for a
  service consumer. Both provider and consumer are
  roles played by software agents on behalf of
  their owners.
• A service in SOA can be a web service (WS), but
  not necessarily be. Any self-contained
  well-defined components, not necessarily on the
  web, can be used in an SOA application.

3
Definition of SOA

• A Service-Oriented Architecture (SOA) is a system
  consisting of modular software components with
  standardized component-access and usage
  interfaces that are independent of any specific
  platform or implementation technology.
• At its most basic, an SOA is simply a collection
  of standardized services on a network that
  communicate with one another in the context of a
  business process.

4
Example of SOA

• This definition of SOA is a bit too abstract, but
  SOA is actually everywhere.
• Let's look at an example of SOA which is likely
  to be found in your living room. Take a CD for
  instance. If you want to play it, you put your CD
  into a CD player and the player plays it for you.
  The CD player offers a CD playing service. Which
  is nice because you can replace one CD player
  with another. You can play the same CD on a
  portable player or on your expensive stereo. They
  both offer the same CD playing service, but the
  quality of service is different.

5
Difference from OO Programming

• The idea of SOA departs significantly from that
  of OO programming, which strongly suggests that
  you should bind data and its processing together.
  So, in OO programming style, every CD would come
  with its own player and they are not supposed to
  be separated. This sounds odd, but it's the way
  we have built many software systems.

6
Difference from Web Service

• Web services does not equal service-oriented
  architecture. Web services is a collection of
  technologies, including XML, SOAP, WSDL, and
  UDDI, which let you build programming solutions
  for specific messaging and application
  integration problems.
• Over time, you can reasonably expect these
  technologies to mature, and eventually be
  replaced with better, more efficient, or more
  robust ones.
• They are, at the very least, a proof of concept
  that SOAs can finally be implemented. So what
  actually does constitute a SOA?

7
Difference from Web Service (Cont.)
The above table is from Microsofts website 1
8
Difference from Web Service (Cont.)

• SOA is just an architecture. It is more than any
  particular set of technologies, such as Web
  services it transcends them, and, in a perfect
  world, is totally independent of them. Within a
  business environment, a pure architectural
  definition of a SOA might be something like "an
  application architecture within which all
  functions are defined as independent services
  with well-defined invokable interfaces which can
  be called in defined sequences to form business
  processes". Note what is being said here
• All functions are defined as services.
• All services are independent.
• In the most general sense, the interfaces are
  invokable

9
Why we need SOA for IT management?

• Systinet 3 discusses the advantages to apply
  SOA on IT management.
• An SOA enables software components to become
  standard services that can be invoked at runtime
  or on demand.
• A business-driven SOA strategy will help focus on
  the goal of Dynamic Business Interoperability and
  lead to achievement of desired business outcomes.

10
Advantages of SOA

• First, SOAs make interoperability an innate
  characteristic of IT systems and applications
  built using this approach because the resulting
  loosely coupled and modular components share
  common communication and interface description
  mechanism. Organizations dont have to invest
  inordinate amounts of time and resources writing
  code to connect applications, only to have to
  rewrite code again if small changes are made to
  the system.
• Second, SOAs make IT more agile and more
  responsive to business process changes. Since
  services represent high-level business logic, IT
  is encouraged to think in terms of business
  functions. With SOA, IT systems begin to
  accurately and quickly adapt to organizational
  goals and processes. SOAs also make IT highly
  tolerant of change because reconfiguring loosely
  coupled services is simple, fast and low-cost.
  With an SOA, IT is able to react quickly to
  changing business demands, new requirements, or
  new processes.

11
What you need to think about when building SOA?

• Understand the Business Model
• Focus on Interoperability
• Focus on Business Agility
• Define and Enforce Application Interoperability
  Policies
• How Web services will be used?
• What standards and interoperability policies must
  be defined and enforced?
• How these will be driven within a SOA context?
• Change IT Procurement Policies
• Ongoing management of your SOA will demand vendor
  compliance to your SOA strategy and
  interoperability policy.

12
What you need to think about when building SOA?
(Cont.)

• Transform Your IT Development Processes and
  Policies
• The compliance to WS-I and internal standards
  should be enforced at design and runtime using
  available WSM and SOA enforcement tools.
• Define and Enforce Your Business Interoperability
  Policies
• Monitor, Measure and Analyze SOA Service Network
• Are the services leveraging one another in a
  symbiotic network fashion?
• Are we getting the maximum interoperability and
  services reuse from our SOA? If not, why not? Are
  policies being enforced at design and run-time?
• Do we have a truly interoperability-based SOA or
  do we have islands of business and Web services?
  How can we unite these services?
• Finally, were your initial SOA business goals
  met? How can we improve our performance? If our
  goals were not met, why not? What must be done?

13
Top-Level Processes

• The process of delivering the service
  implementation
• 'Traditional' Development
• Programming
• Web Services automated by tools
• The provisioning of the servicethe life cycle of
  the service as a reusable artifact
• Commercial Orientation
• Internal and External View
• Service Level Management
• The consumption process
• Business Process Driven
• Service Consumer could be internal or external
• Solution assembly from Services, not code
• Increasingly graphical, declarative development
  approach
• Could be undertaken by business analyst or
  knowledge worker

14
SOA Process

• SOA Planning
• SOA business services are defined and created
  based on the business model.
• SOA Enablement
• Service Provider-enablement.
• Service Consumer-enablement.
• Standards-based business service registry.
• Supporting infrastructure such as Web services
  management, identity management, and
  service-oriented messaging services.
• SOA Publishing
• Definition of the procedures and policies, like
• Who is allowed to publish a service to the
  registry?
• What release procedures must be followed?
• How will various designs, standards and security
  policies be approved, certified and enforced in
  the SOA?

15
SOA Process (Cont.)

• SOA Discovery
• Use UDDI
• SOA Management
• Building and deploying the ability to understand
  and manage relationships between business
  services
• Component versioning and dependencies
• Effecting reconfiguration of various aspects of a
  deployment such as location, transport, security
  and policy parameters
• SOA Analysis
• Monitoring and feedback mechanisms to help
  optimize SOA and ultimately, enable an
  organizations business processes by SOA
• Monitoring services status, users, usages, and
  metrics that indicate relative success of various
  business services in the SOA services portfolio
• Providing impact and dependency analysis of
  individual services, groupings of services based
  on custom taxonomies (enabled by the registry)
• Reporting on a wide variety of issues business,
  IT, SOA, reuse, policy violations or compliance
  reporting, and so on

16
SOA Dynamic Discovery

• Dynamic discovery is an important piece of SOA.
  At a high level, SOA is composed of three core
  pieces service providers, service consumers, and
  the directory service. The role of providers and
  consumers are apparent, but the role of the
  directory service needs some explanation. The
  directory service is an intermediary between
  providers and consumers. Providers register with
  the directory service and consumers query the
  directory service to find service providers. Most
  directory services typically organize services
  based on criteria and categorize them. Consumers
  can then use the directory services' search
  capabilities to find providers. Embedding a
  directory service within SOA accomplishes the
  following
• Scalability of services you can add services
  incrementally.
• Decouples consumers from providers.
• Allows for hot updates of services.
• Provides a look-up service for consumers.
• Allows consumers to choose between providers at
  runtime rather than hard-coding a single
  provider.

17
A Typical Architecture for a Service-Oriented
Application

• Like any distributed application,
  service-oriented applications are multi-tier
  applications and have presentation, business
  logic, and persistence layers. The two key tiers
  in SOA are the services layer and the business
  process layer.

18
SOA Architectural Perspective

• The following three SOA architectures need to be
  considered
• The Application Architecture. This is the
  business facing solution which consumes services
  from one or more providers and integrates them
  into the business processes.
• The Service Architecture. This provides a bridge
  between the implementations and the consuming
  applications, creating a logical view of sets of
  services which are available for use, invoked by
  a common interface and management architecture.
• The Component Architecture. This describes the
  various environments supporting the implemented
  applications, the business objects and their
  implementations.

19
SOA Architectural Perspective (Cont.)
20
Basic Components of SOA Architecture

• Service providers. A service provider is a
  component or set of components that execute a
  business function in a stateless fashion,
  accepting predefined inputs and outputs.
• Service consumers. A service consumer is a set of
  components interested in using one or more of the
  services provided by service providers.
• Service repository. A service repository contains
  the descriptions of the services. Service
  providers register their services in this
  repository and service consumers access the
  repository to discover the services being
  provided.

21
Basic Components of SOA Architecture (Cont.)
22
SOA Challenges and Solutions

• While implementing a SOA, a company faces up to
  eight key challenges. These challenges align to
  the steps in a typical project deployment plan
• Service identification. What is a service? What
  is the business functionality to be provided by a
  given service? What is the optimal granularity of
  the service?
• Service location. Where should a service be
  located within the enterprise?
• Service domain definition. How should services be
  grouped together into logical domains?
• Service packaging. How is existing functionality
  within legacy mainframe systems to be
  re-engineered or wrapped into reusable services?
• Service orchestration. How are composite services
  to be orchestrated?
• Service routing. How are requests from service
  consumers to be routed to the appropriate service
  and/or service domain?
• Service governance. How will the enterprise
  exercise governance processes to administer and
  maintain services?
• Service messaging standards adoption. How will
  the enterprise adopt a given standard
  consistently?

23
Another Challenge of Current SOA

• However, current SOA can not satisfy the
  survivability requirements. It fails to discover
  and rebind to available services automatically
  upon the failure or overload of the on-duty
  service.
• Mission-critical systems will be subjected to
  various attacks including physical attacks as
  well as electronic attacks.
• One key feature of survivability is that the
  system is able to dynamically reconfigure in case
  of failures or overload.
• The solution of this problem is service-oriented
  distributed dynamic reconfiguration.

24
Potential Application NCES Vision
Support real-time near-real-time warrior needs
and business users
Users
Community-of-Interest (COI) Capabilities
Levels of Services above core level
Comms Backbone
Core Enterprise Services (CES)
Messaging
ESM
Mediation
Security/IA
User Asst
Discovery
Collaboration
App
Storage
2009-9-15
25
Requirements for the distributed dynamic
reconfiguration.

• Efficiency the reconfiguration algorithm should
  introduce minimum disruption to the system
• Consistency the reconfiguration action should
  maintain the consistency of related components
  after reconfiguration.
• Correctness Reconfiguration constraints must be
  satisfied at all the times.
• Real time Reconfiguration must be carried out in
  real time at runtime for mission-critical C2
  system.
• Real time means within a time limit
• Runtime means that the reconfiguration must be
  carried out while the system is still in
  operation.

26
Requirements for the distributed dynamic
reconfiguration (cont)

• Policy driven system is governed by business
  policy, possibly distributed policies.
• Distributed and parallel execution.
• Reconfiguration actions are executed by the
  distributed agents and the reconfiguration
  actions are done in parallel among these agents.
• Service-oriented
• The dynamic reconfiguration server or agents are
  themselves services in the SOA, so that they can
  be reconfigured too in case of their own
  failures.
• Dynamic Reconfiguration with hierarchical and
  layered system
• This promotes survivability

27
Solution Dynamic Reconfiguration Model for SOA
28
A Layered Partitioning of System with Dynamic
Reconfiguration A Systematic View
Network Services
29
A Layered Partitioning of System with Dynamic
Reconfiguration A Systematic View(cont)

• Dynamic Reconfigurability is embedded in each
  layer of the entire system, and at each level
  multiple DRS synchronized with each other to
  avoid any single point of failure.

30
Hierarchic System Composition with Dynamic
Reconfiguration
31
Hierarchic System Composition with Dynamic
Reconfiguration

• For large scale applications, hierarchic dynamic
  reconfiguration allows the distributed systems to
  be constructed in a hierarchical manner.
• A composite system can be constructed from
  primitive systems with dynamic reconfigurability
  and these in turns can be constructed into more
  complex composite system with dynamic
  reconfigurability.

32
SOA with Dynamic Reconfiguration

• Every participating service, including DRS, is a
  service and each service is treated the same. As
  a service, the DRS provides the following
  functions
• Dynamic service lookup, service publication,
  service binding, and service profiling,
• Registration and de-registration,
• Runtime services verification including
  constraint verification such as security
  verification, interoperability checking, and
  performance monitoring.

33
SOA with Dynamic Reconfiguration (cont)

• The Dynamic Reconfiguration Service (DRS) is
  implemented as a critical service with redundancy
  and the reconfiguration strategies and algorithms
  can be changed at runtime to fit the warfighting
  needs.
• With this kind of mechanism, the behavior of the
  SOA can be changed in real time at runtime, and
  even the behavior of DRS can be changed too.

34
Architecture of DRS and its Distributed Agents
Clients
Service Register
Access Control
DRS Coordination Services
Business Polices
Proxy Services
Auditing Services
COIs
Services
35
Architecture of DRS (cont) Major Agents

• Service Directory (SD) This stores and organizes
  services in a hierarchical tree with internal
  tree node representing a group of related
  services.
• Proxy Agents An Proxy Agent (PA) is responsible
  for interoperability and integration between DRS,
  services and their clients. In addition, it also
  enforces security accessing control.
• Auditing Agents An Audit Agent (AA) monitors and
  checks the performance and user concerned
  properties of the participating services at
  runtime and updates their profiles.

36
Reconfiguration Process
37
Cyclic Flow of Dynamic Reconfiguration Process
Human Participation
Dynamic Reconfiguration Services
Monitoring Services
Real-time Data
Policies
COIs
Reconfiguration Actions
Data
Reconfiguration Actions
Services
38
Dynamic Policy Adaptation and Validation

• Dynamic Policy Adaptation
• Through the cyclic flow of situation aware of
  environment data collect and monitoring,
  reconfiguration policy formation, policy
  validation and reconfiguration execution.
• Commander in the loop
• Policy Validation
• Reconfiguration Constraints are represented by
  Meta Business Policy and it will validate the
  reconfiguration policy in real time at runtime

39
GIG Enterprise Services
SOADR Supports real-time near-real-time warrior
needs
DoD (Title 10)
IC (Title 50)
Business Domains
Warfighter Domains
National Intelligence Domain
Users
Users
Governance
IC Org Spaces
Domain/ COI Capabilities
Human Resources Management
Installations Environment
Strategic Planning Budget
Acquisition
Logistics
Accounting Finance
Levels of Services Above Core Level
Capability Integrator
ICSIS Community Space
Technical Infrastructure Domain
Transformational Communications (TC) Computing
Infrastructure
40
Cyclic Flow of Dynamic Reconfiguration Process
(cont)

• The dynamic reconfiguration mechanism is
  controlled by a set of business policies, and
  these policies specify appropriate actions to
  take under various situations.
• These policies can be pre-specified before system
  operations, but also they can be updated during
  runtime in real-time by the COI (community of
  interest) within the system.
• The distributed situation-aware COI monitoring
  agent detects the changes in the operation
  environment, it informs the concerned COIs and
  then these COIs may update their polices to
  adjust to the changing environment.

41
Cyclic Flow of Dynamic Reconfiguration Process
(cont)

• Once the business policies are changed, the
  dynamic reconfiguration is changed as it is ruled
  by the policies, even though the overall
  reconfiguration mechanism remains the same.
• In this way, commanders and decision makers make
  high-level decisions, based on the latest
  situation assessment, and let the SOA to actually
  implementation the transition plan.
• Multiple monitoring agents, COIs, and DRS can
  participate in this process, and this process is
  done in a distributed but collaborative manner.

42
Ontology

• Why do we use ontology?
• To describe the semantics of the data (which we
  name as Meta-Data)
• Why do we describe the semantics?
• In order to provide a uniform way to make
  different parties to understand each other
• Which data?
• Any data (on the web, or in the existing legacy
  databases)

43
Why Do We Need Ontology in SOA?

• First reason is that ontology can be used to
  represent the relationship and dependencies
  between services as well as service interactions.
  It is also useful to perform dynamic service
  matching.
• Another reason is that, the use of ontology can
  greatly enhance the service reusability in SOA. A
  typical example is FERA 4, a collaboration
  framework proposed by Intel, which enables
  enterprises to expose their business processes
  across a federation of enterprises through SOA
  and therefore enhance the service reusability.
  One of the weapon to achieve this goal is via
  ontology. In FERA, the context of collaboration
  needs to be defined using open standard
  semantics, while the ontology of contents needs
  to be consistent across all shared meta-data
  definitions. This enables the processes to be
  configured as they fit the business needs and
  reconfigured when the needs change.

44
Problems on Testing SOA

• Even small changes can cause major disruptions in
  todays highly interactive and independent
  applications.
• Unfortunately, the pace of changes means
  traditional testing architectures with lengthy
  development and testing will not work.
• But the testing must be done.
• Several SOA testing frameworks have been
  proposed. Worksofts Certify 2 will be
  discussed as the test management repository and
  framework solution to this testing problem for
  XML-based applications.

45
A Typical SOA-architected Service Solution

• The following figure shows a typical
  SOA-architected service solution for an insurance
  company.

46
Traditional Solutions

• Indirect testing and standardization have
  traditionally provided ways to work around at
  least some of difficulties associated with these
  problems.
• But both traditional solutions doesnt work well
  on SOA testing.

47
Problem of Indirect Testing

• Can these services be tested indirectly? Wont
  exercising the provider and consumer applications
  those that enable or use the services allow us
  to uncover problem? The problem is one of timing
  and data. Such indirect testing cant be done
  until late in the development cycle when the cost
  of correction is very high. Nor does indirect
  testing provide an effective way to find the
  source of a problem. These is no enough data
  about an incorrect transaction or failed result
  to identify with of at least five places caused
  the problem the provider application, the
  encoding, the transport, the message content or
  the consumer application.
• Another frustration to indirect testing is found
  in the boundless nature and fundamental promise
  and power of SOA. A significant part of the
  attractiveness of SOA comes from the
  unpredictability of its utilization. SOA
  applications can be utilized by any application
  including those not yet developed and accessed by
  consumers outside the enterprise. It has
  boundless potential for use. Cant standards
  provide us a way out of this dilemma? The answer
  is not completely.

48
Standards Dont Always Help

• While this standard makes applications
  integration much more flexible than previously
  hard-wired connections, it makes testing more
  complex. A traditional monolithic application has
  a user interface to allow verification of
  business functionality, but the layers of an SOA
  do not offer such an interface yet they must be
  tested individually as they are developed and
  together as they are integrated.
• The only way to test the business functionality
  of XML messages is through a test interface that
  allows messages to be created, sent, received and
  verified either simulated or live. Without it,
  there is no means of verifying functionality at
  each integration point.
• Until now, each development group has had to
  write customized code to provide a test interface
  to the messaging layer. This adds time and cost
  to the overall project as well as ongoing
  maintenance into the future. Further, testing the
  integration of all layers requires an interface
  that allows business processes be executed end to
  end, across applications, platforms and perhaps
  enterprises.
• Is there no way out of this testing trap? Lets
  examine one approach from Worksoft.

49
Introducing Worksofts Certify

• Worksoft introduced Certify to bring the power
  of a proven test automation repository and
  framework to the testing of XML messages. Certify
  provides a straightforward interface for
  developers, testers, business analysts and expert
  users to define the format and content of the
  messages they want to send and receive, whether
  across a transport protocol or between files.
  Layers can be tested either standalone or
  together. Certify can be used to configure the
  enterprise environment, define the messages, and
  start exercising business process functionality
  at every level and interface.
• Certify provides
• A central repository for all test assets
• Business process automation and verification
  across both the UI and services
• Exercise messaging either emulated or live
• Test object management and maintenance
• Traceability from business processes to messages
  to applications
• End-to-end execution across platforms,
  applications and layers
• Detailed result logs, management reports and
  analysis
• Certifys approach has the potential to deliver
  dramatic productivity gains in automating and
  maintaining XML test cases. User of Certify means
  that custom code does not need to be developed.
  All test cases are developed in a repository
  using a standard, structured format. Test
  coverage can be quickly extended using data
  variations.

50
Certifys operational process

• The first step is for the systems architect to
  configure the transport that will be used to send
  and receive XMl messages. While XMl is a
  standard, the implementation of the messaging
  layer is not. There are a number of transports
  and protocols, including both public and private
  APIs.
• Next, the architect constructs a set of shared
  Certify processes that handle the sending and
  receiving of messages so that analysts can simply
  call them. This removes the need for analysts to
  understand the system infrastructure or transport
  protocol.
• The next step is to import the schema or messages
  into the Certify application map, then
  rationalize the object names so they are useful
  and meaningful for test or business analysts. The
  message itself is presented to the user as a
  window, and each element within the message
  becomes an object.

51
Business Meaningful Element Names in All Messages
52
Perform Edit/Execute Command

• The message map provides users with a point and
  click editor for defining message data content to
  be sent or verified. As shown in Figure 4, the
  analyst selects the message, then the element
  within the message, then the action to be
  performed, such as to set or verify the value.
  Once the message contents are defined, the
  message can be generated and sent or received and
  verified.

53
Reference

• 1 Microsoft, Service Oriented Architecture,
  http//msdn.microsoft.com/architecture/soa/default
  .aspx.
• 2 Ptak, Noel Associates, Automated Testing
  Preventing DOA for SOA, http//www.worksoft.com/C
  ontentDisplay/UploadDocs/Worksoft20Preventing20S
  OA20DOArppdf.pdf.
• 3 Systinet, A Practical Guide to SOA for IT
  Management.
• 4 George Brown and Robert Carpenter,
  Successful Application of Service-Oriented
  Architecture Across the Enterprise and Beyond,
• http//developer.intel.com/technology/itj/2004/vo
  lume08issue04/art09_successful/p01_abstract.htm.
• 5 Nick Kushmerick, Semantic Web Vaporware or
  Worthy Dream?, http//rakaposhi.eas.asu.edu/cse49
  4/notes/semantic-web.ppt.
• 6 Linda G. Hayes, Testing SOA Could Test Your
  Nerves, http//itmanagement.earthweb.com
  /columns/quaquest/article.php/3416971.