[e-mail]

1
Service-Oriented Architecture

• ???
• ?????
• ?????????????
• lzwang_at_nju.edu.cn
• http//cs.nju.edu.cn/lzwang

2
Why SOA?

• IT??
• ?????????,????,???????????(application
  infrastructure)????
• ?????????????????????(business processes),????????
  ????????????
• ?????
• ??????????????????
• ??????????????????(application infrastructure)
• ???,?????????????????

3
The business drivers for a new approach

• While IT executives have been facing the
  challenge of
• cutting costs
• maximizing the utilization of existing technology
• At the same time they have to
• continuously strive to serve customers better
• be more competitive
• be more responsive to the businesss strategic
  priorities.
• There are two underlying themes behind all of
  these pressures Heterogeneity and change

4
The business drivers for a new approach

• Heterogeneity
• Most enterprises today contain a range of
  different systems, applications, and
  architectures of different ages and technologies.
  
• Integrating products from multiple vendors and
  across different platforms were almost always a
  nightmare.
• But we also cannot afford to take a single-vendor
  approach to IT, because application suites and
  the supporting infrastructure are so inflexible.
• Change
• Globalization and e-business are accelerating the
  pace of change.
• Improvements in technology continue to
  accelerate, feeding the increased pace of
  changing customer requirements.

5
The business drivers for a new approach

• As a result, business organizations are evolving
• from the vertical, isolated business divisions of
  the 1980s and earlier
• to the horizontal business-process-focused
  structures of the 1980s and 1990s
• towards the new ecosystem business paradigm.
  Business services now need to be componentized
  and distributed.
• There is a focus on the extended supply chain,
  enabling customer and partner access to business
  services.

6
The business drivers for a new approach

• Questions
• How do I make my IT environment more flexible and
  responsive to the ever changing business
  requirements?
• How can we make those heterogeneous systems and
  applications communicate as seamlessly as
  possible?
• How can we achieve the business objective without
  bankrupting the enterprise?
• Currently many IT executives and professionals
  alike believe that now we are getting really
  close to providing a satisfactory answer with
  service-oriented architecture.

7
The business drivers for a new approach

• In order to alleviate the problems of
  heterogeneity, interoperability and ever changing
  requirements, such an architecture should provide
  a platform for building application services with
  the following characteristics
• Loosely coupled
• Location transparent
• Protocol independent
• Based on such a service-oriented architecture, a
  service consumer does not even have to care about
  a particular service it is communicating with
  because the underlying infrastructure, or service
  bus, will make an appropriate choice on behalf
  of the consumer.
• The infrastructure hides as many technicalities
  as possible from a requestor. Particularly
  technical specificities from different
  implementation technologies such as J2EE or .NET
  should not affect the SOA users.
• We should also be able to reconsider and
  substitute a better service implementation if
  one is available, and with better quality of
  service characteristics.

8
Object-oriented analysis and design

• Object-oriented analysis and design
• Larman describes the essence of the
  object-oriented analysis and design as
  considering a problem domain and logical
  solution from the perspective of objects (things,
  concepts, or entities) in
• Applying UML and Patterns An Introduction to
  Object-Oriented Analysis and Design.
• Jacobson, et al, define these objects as being
  characterized by a number of operations and a
  state that remembers the effects of these
  operations in
• Object-Oriented Software Engineering A Use Case
  Driven Approach.
• In object-oriented analysis, such objects are
  identified and described in the problem domain,
  while in object-oriented design, they are
  transitioned into logical software objects that
  will ultimately be implemented in a
  object-oriented programming language.
• With object-oriented analysis and design, certain
  aspects of the object (or group of objects) can
  be encapsulated to simplify the analysis of
  complex business scenarios.
• Certain characteristics of the object(s) can also
  be abstracted so that only the important or
  essential aspects are captured, in order to
  reduce complexity.

9
Component-based design

• Component-based design is not a new technology.
  It is naturally evolved from the object paradigm.
  
• Packaged solution suites can also be encapsulated
  as such components.
• Once the organization achieves a higher level of
  architectural maturity based on distinctly
  separate functional components, the applications
  that support the business can be partitioned into
  a set of increasingly larger grained components.
• Components can be seen as the mechanism to
  package, manage and expose services.
• They can use a set of technologies in concert
  Large-grained enterprise components, that
  implement business-level use-cases, can be
  implemented using newer object-oriented software
  development in combination with legacy systems.

10
Service-oriented design

• In Component-Based Development for Enterprise
  Systems, Allen includes the notion of services,
  describing a component as
• an executable unit of code that provides
  physical black-box encapsulation of related
  services. Its service can only be accessed
  through a consistent, published interface that
  includes an interaction standard. A component
  must be capable of being connected to other
  components (through a communications interface)
  to a larger group.
• A service is generally implemented as a
  course-grained, discoverable software entity that
  exists as a single instance and interacts with
  applications and other services through a loosely
  coupled, message-based communication model.

11
SOA

• SOA?????????????IT?????????Gartner?1996???
• A service-oriented architecture is a style of
  multitier computing that helps organizations
  share logic and data among multiple applications
  and usage modes.?

12
SOA

• OASIS defines SOA as the following
• 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.

13
SOA

• Wikipedia
• In computing, the term Service-Oriented
  Architecture (SOA) expresses a perspective of
  software architecture that defines the use of
  services to support the requirements of software
  users. In an SOA environment, resources on a
  network are made available as independent
  services that can be accessed without knowledge
  of their underlying platform implementation?

14
SOA

• ?????,?????????????????????,?????????????????????S
  OA???,???????????????????,???????????????????????
• ??????????,????????,?????????????,???????????????
  ?,???????????????????????

15
SOA

• ?????????(SOA)???????,?????????????(????)?????????
  ?????????????????????????????,????????????????????
  ?????????????????????????????????????????

16
Service-oriented design

• important service-oriented terminology
• Services Logical entities, the contracts defined
  by one or more published interfaces.
• Service provider The software entity that
  implements a service specification.
• Service consumer (or requestor) The software
  entity that calls a service provider.
  Traditionally, this is termed a client. A
  service consumer can be an end-user application
  or another service.

• Service locator A specific kind of service
  provider that acts as a registry and allows for
  the lookup of service provider interfaces and
  service locations.
• Service broker A specific kind of service
  provider that can pass on service requests to one
  or more additional service providers.

17
Interface-based design

• In both component and service development, the
  design of the interfaces is done such that a
  software entity implements and exposes a key part
  of its definition.
• Therefore, the notion and concept of interface
  is key to successful design in both
  component-based and service-oriented systems.
• The following are some key interface-related
  definitions
• Interface Defines a set of public method
  signatures, logically grouped but providing no
  implementation. An interface defines a contract
  between the requestor and provider of a service.
  Any implementation of an interface must provide
  all methods.
• Published interface An interface that is
  uniquely identifiable and made available through
  a registry for clients to dynamically discover.
• Public interface An interface that is available
  for clients to use but is not published, thus
  requiring static knowledge on the part of the
  client.
• Dual interface Frequently interfaces are
  developed as pairs such that one interface
  depends on another for example, a client must
  implement an interface to call a requestor
  because the client interface provides some
  callback mechanism.

18
Interface-based design

• The following figure shows the UML definition of
  a customer relationship management (CRM) service,
  represented as a UML component, that implements
  the interfaces AccountManagement,
  ContactManagement, and SystemsManagement.
• Only the first two of these are published
  interfaces, although the latter is a public
  interface.
• Note that the SystemsManagement interface and
  ManagementService interface form a dual
  interface.

19
Layered application architectures

• Object-oriented technology and languages are
  great ways to implement components. While
  components are the best way to implement
  services, though one has to understand that a
  good component-based application does not
  necessarily make an good service-oriented
  application.
• The term the application edge reflects the fact
  that a service is a great way to expose an
  external view of a system, with internal reuse
  and composition using traditional component
  design.

20
A closer look at service-oriented architecture

• Service-oriented architecture presents an
  approach for building distributed systems that
  deliver application functionality as services to
  either end-user applications or other services.
  It is comprised of elements that can be
  categorized into functional and quality of
  service.

21
A closer look at service-oriented architecture

• Functional aspects include
• Transport is the mechanism used to move service
  requests from the service consumer to the service
  provider, and service responses from the service
  provider to the service consumer.
• Service Communication Protocol is an agreed
  mechanism that the service provider and the
  service consumer use to communicate what is being
  requested and what is being returned.
• Service Description is an agreed schema for
  describing what the service is, how it should be
  invoked, and what data is required to invoke the
  service successfully.
• Service describes an actual service that is made
  available for use.
• Business Process is a collection of services,
  invoked in a particular sequence with a
  particular set of rules, to meet a business
  requirement. Note that a business process could
  be considered a service in its own right, which
  leads to the idea that business processes may be
  composed of services of different granularities.
• The Service Registry is a repository of service
  and data descriptions which may be used by
  service providers to publish their services, and
  service consumers to discover or find available
  services. The service registry may provide other
  functions to services that require a centralized
  repository.

22
A closer look at service-oriented architecture

• Quality of service aspects include
• Policy is a set of conditions or rules under
  which a service provider makes the service
  available to consumers. There are aspects of
  policy which are functional, and aspects which
  relate to quality of service therefore we have
  the policy function in both functional and
  quality of service areas.
• Security is the set of rules that might be
  applied to the identification, authorization, and
  access control of service consumers invoking
  services.
• Transaction is the set of attributes that might
  be applied to a group of services to deliver a
  consistent result. For example, if a group of
  three services are to be used to complete a
  business function, all must complete or none must
  complete.
• Management is the set of attributes that might be
  applied to managing the services provided or
  consumed.

23
SOA collaborations

• The following figure shows the collaborations in
  a service-oriented architecture. The
  collaborations follows the find, bind and
  invoke paradigm.
• A service consumer performs dynamic service
  location by querying the service registry for a
  service that matches its criteria.
• If the service exists, the registry provides the
  consumer with the interface contract and the
  endpoint address for the service.

24
SOA collaborations

• The roles in a service-oriented architecture are
• Service consumer The service consumer is an
  application, a software module or another service
  that requires a service. It initiates the enquiry
  of the service in the registry, binds to the
  service over a transport, and executes the
  service function. The service consumer executes
  the service according to the interface contract.
• Service provider The service provider is a
  network-addressable entity that accepts and
  executes requests from consumers. It publishes
  its services and interface contract to the
  service registry so that the service consumer can
  discover and access the service.
• Service registry A service registry is the
  enabler for service discovery. It contains a
  repository of available services and allows for
  the lookup of service provider interfaces to
  interested service consumers.
• Each entity in the service-oriented architecture
  can play one (or more) of the three roles of
  service provider, consumer and registry.

25
SOA collaborations

• The operations in a service-oriented architecture
  are
• Publish To be accessible, a service description
  must be published so that it can be discovered
  and invoked by a service consumer.
• Find A service requestor locates a service by
  querying the service registry for a service that
  meets its criteria.
• Bind and invoke After retrieving the service
  description, the service consumer proceeds to
  invoke the service according to the information
  in the service description.
• The artifacts in a service-oriented architecture
  are
• Service A service that is made available for use
  through a published interface that allows it to
  be invoked by the service consumer.
• Service description A service description
  specifies the way a service consumer will
  interact with the service provider. It specifies
  the format of the request and response from the
  service. This description may specify a set of
  preconditions, post conditions and/or quality of
  service (QoS) levels.

26
SOA collaborations

• In addition to dynamic service discovery and
  definition of a service interface contract, a
  service-oriented architecture has the following
  characteristics
• Services are self-contained and modular.
• Services support interoperability.
• Services are loosely coupled.
• Services are location-transparent.
• Services are composite modules, comprised of
  components.
• These characteristics are also central to
  fulfilling the requirements for an e-business on
  demand operational environment.

• Finally, service-oriented architecture is not a
  new notion.

27
Services vs. components

• A service is a coarse-grained processing unit
  that consumes and produces sets of objects
  passed-by-value.
• It is not the same as an object in programming
  language terms. Instead, it is perhaps closer to
  the concept of a business transaction such as a
  CICS or IMS transaction than to a remote CORBA
  object.
• A service consists of a collection of components
  that work in concert to deliver the business
  function that the service represents.
• Thus, in comparison, components are finer-grained
  than services.
• In addition, while a service maps to a business
  function, a component typically maps to business
  entities and the business rules that operate on
  them.
• As an example, let us look at the Purchase Order
  component model for the WS-I Supply Chain
  Management sample.

28
Services vs. components

• In a component-based design, components are
  created to closely match business entities (such
  as Customer, Purchase Order, Order Item) and
  encapsulate the behavior that matches the
  entities expected behavior.
• Purchase Order component provides functions to
  obtain information about the list of products
  ordered and the total amount of the order
• Item component provides functions to obtain
  information about the quantity and price of the
  product ordered.

• In a service-oriented design, services are not
  designed based on business entities. Instead,
  each service is a holistic unit that manages
  operations across a set of business entities.
• For example, a customer service will respond to
  any request from any other system or service that
  needs to access customer information.
• The customer service can process a request to
  update customer information add, update, delete
  investment portfolios and enquire about the
  customers order history.
• The customer service owns all the data related to
  the customers it is managing and is capable of
  making other service inquiries on behalf of the
  calling party in order to provide a unified
  customer service view.
• This means a service is a manager object that
  creates and manages its set components.

29
Service-oriented architecture benefits

• With a service-oriented architecture, we can
  realize several benefits to help organizations
  succeed in the dynamic business landscape of
  today
• Leverage existing assets.
• Easier to integrate and manage complexity.
• More responsive and faster time-to-market.
• Reduce cost and increase reuse.
• Be ready for what lies ahead.
• Service-oriented architecture is by no means a
  silver bullet, and migration to SOA is not an
  easy task. Rather than migrating the whole
  enterprise to a service-oriented architecture
  overnight, the recommended approach is to migrate
  an appropriate subset of business functions as
  the business need arises or is anticipated.

30
Service-Oriented Architecture

• Architecture Classification for SOA-Based
  Applications
• W.T. Tsai, Chun Fan, Yinong Chen
• Arizona State University,Tempe, AZ 85287
• wtsai, fanchun, yinong_at_asu.edu
• Raymond Paul
• Department of Defense, Washington, DC
• Raymond.Paul_at_osd.mil
• Jen-Yao Chung
• IBM T. J. Watson, Research Center
• jychung_at_us.ibm.com

31
Service-Oriented Architecture

• The architecture of SOA-based applications is
  different from traditional software architecture
  where the architecture is mainly static.
• The architecture of an SOA-based application is
  dynamic, i.e., the application may be composed at
  runtime using existing services.
• Thus SOA has provided a new direction for
  software architecture study, where the
  architecture is determined at runtime and
  architecture can be dynamically changed at
  runtime to meet the new software requirements.
• Thus a target application is built through
  service discovery and composing instead of
  traditional process of designing and coding
  software.

32
Service-Oriented Architecture

• SOA software has the following characteristics
  that are different from traditional software
• Standard-based Interoperability
• SOA emphasizes on stand-based interface,
  protocols, communication, coordination, workflow,
  discovery, collaboration, and publishing via
  standard protocols such as XML, SOAP, WSDL, UDDI,
  HTTP, CPP, ebXML, ebSOA, BPEL, FERA, and OWL-S.
• These standards allow services developed on
  different platforms can interoperate with each
  other with the knowledge of service
  specifications only.
• Dynamic Composition via Discovery
• SOA provides a new way of application development
  by using services just discovered. Furthermore,
  the composition and discovery can be carried out
  at runtime.

33
Service-Oriented Architecture

• Dynamic Governance and Orchestration
• Execution of services needs to be controlled and
  several mechanisms are available. One is service
  governance by policy. More specifically, policies
  can be specified, checked, and enforced during
  development time and at runtime.
• The other is orchestration where process
  execution will be coordinated by a central
  controller and it is responsible for scheduling
  the execution of services that may be distributed
  across a connectivity network such as ESB
  (Enterprise Service Bus).

34
Service-Oriented Architecture

• Architecture of SOA applications, including IBM
  SOA Foundation architecture, Microsofts
  Whitehorse, SAPs NetWeaver, OASISs FERA and
  various enterprise SOA applications such as
  Enterprise SOA and Service-Oriented Enterprise.

35
Application Architecture Issues

• Due to dynamic nature of SOA, the architecture of
  SOA-based applications has the following
  characteristics that are distinct from
  traditional software architectures
• Dynamic architecture and dynamic re-architecture
• Lifecycle management embedded in the operation
  infrastructure architecture
• In traditional software design, the architecture
  can not be changed after its deployment. In SOA,
  the basic building block is not a component but a
  service.
• Services are usually connected to a bus-like
  communication backbone such as an ESB (Enterprise
  Service Bus). Communications among the services
  are controlled by a control center, which is also
  attached to the communication backbone.

36
Application Architecture Issues

• This new approach allows new services to be added
  into the system without stopping the application.
• Furthermore, a new application can be composed
  from the existing services by just changing the
  workflow specification without changing the basic
  SOA framework.

37
Application Architecture Issues

• IBM SOA Foundation architecture consists of
  stages modeling, assembling, deployment, and
  management.
• Furthermore, runtime governance activities are
  performed to provide guidance and oversight for
  the target SOA application.
• The activities in the four stages are performed
  iteratively.
• Modeling Gather requirements and establish the
  application model to represent the system using a
  set of services.
• Assembling The designer can either create
  required services from scratch or find an
  existing service from a service broker to develop
  the application according to the model
  constructed.
• Deployment The runtime environment is configured
  to meet the applications requirements, and the
  application is deployed into that environment for
  execution.
• Management After the application is deployed,
  the services used in the application are
  provisioned and monitored for information needed
  to prevent, isolate, diagnose, and fix any
  problem that might occur during application
  runtime.

38
SOA Architecture Classification

• SOA Architecture Classification (SOAC) for
  SOA-based applications, which is based on four
  parameters
• The structure of the application. It can be
  either static or dynamic.
• The runtime re-composition capability. If the
  architecture can support runtime re-composition,
  services in the applications using this type of
  architectures can be replaced by some other
  services to meet changing requirements or to fix
  runtime failures. Note that it is not necessary
  to classify an architecture base on dynamic
  composition as this is already a part of SOA
  definition.
• The fault-tolerance capability. This can be
  further decomposed into two sub-factors
  fault-tolerant control center and fault-tolerant
  communication backbone.
• The system engineering support for SOA
  applications will be needed as a part of the
  lifecycle management. Some sample system
  engineering support includes model-based
  development, policy specification and
  enforcement, completeness and consistency
  checking, model checking, simulation, reliability
  assessment, automated code generation,
  monitoring, and data collection.

39
SOA Architecture Classification

• With these parameters, one can specify the
  classification of an SOA application using a
  tuple (Structure, Re-composition,
  Fault-tolerance, System engineering), where
• Structure an application can have S (for static
  structure) or D (dynamic structure), but not
  both
• Re-composition an application can have R (for
  with dynamic re-composition capability) or N (for
  without it), but not both
• Fault-tolerance an application can have FB
  (faulttolerant communication backbone), FC
  (faulttolerant control services), or FN (no
  faulttolerance)
• System engineering support SOA application
  architecture has the SOSE supports, it is denoted
  with SY. On the contrary if an SOA application
  architecture has no SOSE support, it is denoted
  with SN.

40
SOA Architecture Classification

• (S,N,FN,SN) Architecture
• Once the application is deployed, it cannot be
  changed or recomposed.
• (D,N,FN,SN) Architecture
• Services are connected to the shared
  communication backbone.
• These services are loosely coupled such that an
  individual service does not need to know the
  details or even the existences of other services.
• The dynamic composition as well as orchestration
  will be managed by Application Composition
  Manager.
• The workflow specification defines the execution
  sequence of services to deliver the desired
  functionalities.

41
SOA Architecture Classification

• (D,R,FN,SN) Architecture
• In this way, after the application is deployed,
  the Data Collection service will keep on
  monitoring the behaviors of the participating
  services and collect data at runtime.
• The data collected will be continuously analyzed
  to decide if it is necessary to trigger a
  reconfiguration.
• If a reconfiguration is triggered, the
  application specification including the workflows
  and participating services will be dynamically
  updated according to the reconfiguration policy.
• (D,R,FC,SN) Architecture
• The control center is now more complex as it not
  only needs to keep track of the status of
  participating services, but also needs to check
  itself continuously to ensure the control center
  can tolerate its own faults.

42
SOA Architecture Classification

• (D,R,FB/FC,SN) Architecture
• In the previous architecture, the control center
  is fault tolerant, but failures occurred in the
  communication backbone are not handled.
• Since the control center is also built on top of
  the communication backbone, i.e., it uses the
  backbone for communication.
• In this case, if the backbone fails, the
  fault-tolerant control center will fail too.
• The communication backbone can be a computing
  platform, such as .NET, or ESB. Microsoft
  developed a reliable messaging service called
  Indigo that provides fault-tolerant
  communications between services.
• ESB is essentially a service-oriented middleware
  that allows services to communicate with each
  other.
• (D,R,XX,SY) Architecture
• In (D, R, XX, SY), if X and Y are variables, it
  introduces a family in which different system
  engineering supports are added to the operation
  infrastructure.
• IBM SOA Foundation architecture includes
  modeling/specification, verification and
  validation, assembling, deployment, and
  management.
• Automated tools can help tune the deployment
  environment and deploy the application into the
  tuned environment.

43
SOA Architecture Classification

• Evaluation criteria for the different
  architectures
• Complexity The architecture complexity will
  increase as we move the architecture from the top
  to the bottom and from the left to the right in
  the architecture roadmap. Thus (S, N, FN, SN) is
  the simplest architecture and the (D, R, FB/FC,
  SY) is the most complex one.
• Dependability If the fault-tolerant mechanisms
  are implemented properly, the dependability
  should enhance as we move the architecture from
  top to bottom and from left to right of the map,
  because more and more fault-tolerance
  capabilities areintroduced into the
  architectures.
• Efficiency As the complexity increases, the
  efficiency can decrease if additional resources
  and computation power outperform the benefit.
  Evaluation is necessary to evaluate the
  efficiency.
• Adaptability Architecture styles with the
  recomposition capability have higher adaptability
  than those without the capability. Thus the
  adaptability should increase when the
  architecture moves from the top to the bottom and
  from the left towards the right of the map.
  Higher adaptabilityalso indicates the better
  self-monitoring, selfhealing, and self-governing
  capabilities.

44
SOA Architecture Classification

• Difficulty to implement The simplest
  architecture style is the easiest one to use
  because it doesnt require many complex
  techniques.
• Cost of Development The architecture that is the
  easiest to implement has the lowest development
  cost.
• Cost of Maintenance As one advances from the top
  towards the bottom of the SOA application
  architecture roadmap, one can see that the
  architecture styles near the bottom have more
  selfmonitoring, self-governing, and self-healing
  capabilities. Thus the cost of maintenance will
  decrease accordingly. On the other hand, the
  increasing complexity can increase the
  maintenance cost. Careful evaluation is needed.
• System engineering support SOSE supports are
  vital to deliver better SOA applications and
  services, especially at enterprise level.
  Automated tools shall be adopted to facilitate
  these supports. Obviously SY gt SP gt SN.

45
Recent SOA Application Architectures

• IBM WebSphere
• WebSphere Integration Reference Architecture aims
  at providing a comprehensive set of services to
  enable business integration in a large diverse
  enterprise environment.
• and WebSphere Integration Reference Architecture,
  WebSphere architecture is (D, R, FN, SN)
  according to the SAC, and an SOA application
  using this architecture can be monitored after
  deployment.

46
Recent SOA Application Architectures

• OASIS FERA
• FERA (Federated Enterprise Reference
  Architecture) presents a set of principles and
  guidelines for the development and deployment of
  an SOA application with loosely coupled
  collaboration.
• FERA is an (D, N, FN, SN) architecture according
  to the SAC.

47
Recent SOA Application Architectures

• Process Embedded SOA Infrastructure
• The Process-Embedded Service-Oriented
  Infrastructure (PESOI) is an approach that
  integrates development and operation
  infrastructure into the application developed.
  This approach

48
SOA ??

• ????????????
• ????????
• ?????????
• ???????
• ????,??????
• ???
• ???
• ???
• ?????
• ???.

49
SOA??

• ?????????
• ????????
• ???,????,???????
• ?????????????,???????????,????????
• ?????????
• ??????????????????????????????

50
SOA??

• ???????????,???????????,?????????????????????SOA??
  ,?????????????????,????????????? 
• ?????,??????????????????????????????????,???????
  ???????????? 
• ????????,?????????????????????????????????????????
  ??,??????????? 
• ????????????????????????????,??????????????? 

51
SOA??

• ???????
• ??????
• ????
• ???
• ????
• ?????????????????????

52
Summary

• SOA-based applications have dynamic instead of
  static architecture, and thus they have
  drastically different characteristics than
  traditional software architecture.