Service-Oriented Architecture

1
Service-Oriented Architecture
Sumber Practical Guide to Enterprise Architecture, A
By James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, Elias K. Jo
2
Service-Oriented Architecture

• Description Service-Oriented architecture (SOA)
  is an architectural style that formally separates
  services, which are the functionality that a
  system can provide, from service consumers, which
  are systems that need that functionality.

3
Description

• This separation is accomplished by a mechanism
  known as a service contract, coupled with a
  mechanism for providers to publish contracts and
  consumers to locate the contracts that provide
  the service that they desire (diinginkan).
• Rather than coupling (menggabungkan) the consumer
  with the service in terms of technical aspects of
  invoking (melibatkan) the service, SOA separates
  the contract from the component or implementation
  of that contract.

4
Description

• This separation produces an architecture in which
  the coupling between the consumer of the service
  and the modules that produce the work is
  extremely loose and easily reconfigured.

5
Benefits of an SOA

• SOA can be of enormous (sangat besar) benefit to
  the modern enterprise.
• It provides an important new avenue (kesempatan)
  for integration of applications.
• Creating new applications under an SOA offers a
  significant increase in the qualities of
  availability, interoperability, maintainability,
  and reliability (kehandalan) for those
  applications.

6
Benefits of an SOA

• SOA benefits flow primarily from breaking
  applications into modules with a well-defined
  interface contract that leads to very loose
  coupling between services and applications.
• Loose coupling between consumer and provider
  benefits the consumer because consumer
  applications are effectively protected from
  changes in service provider implementations and
  the consumer has a greater choice of providers.

7
Benefits of an SOA

• It benefits the provider because from an
  implementation of loosely coupled systems come
  applications that map much more closely to the
  business processes that represent a company's
  value proposition.
• In addition, these applications increase the
  enterprises' competitiveness because they are
  easier to modify to satisfy changing business
  conditions.
• In addition, applications and work processes
  assembled using an SOA are cheaper to maintain.

8
Benefits of an SOA

• Organizations that adopt a service-oriented
  philosophy of development will be able to handle
  change more quickly and cheaply.
• SOA can provide a major increase in the value of
  the data and application resources of a company
  by enabling a major new mode of integration of
  these assets.

9
Benefits of an SOA

• Decreased application development costs
• Decreased maintenance costs
• Increased corporate agility
• Increasing overall reliability by producing
  systems that are more resistant to application
  and equipment failure and disruption.
• Providing an application upgrade path that is
  considerably cheaper and less disruptive than the
  total application replacement that is the norm
  using monolithic applications.

10
Application development costs are reduced for the
following reasons

• Code reuse is extensive.
• Most of the code has been thoroughly tested.
• The presentation layer is the only layer
  requiring customization for different clients.
• RAD development via automated code generation
  becomes a possibility.

11
Characteristics of an SOA

• Services have well-defined interfaces (contract)
  and policies.
• Services usually represent a business function or
  domain.
• Services have a modular design.
• Services are loosely coupled (Keterikatan yang
  renggang).

12
Characteristics of an SOA

• Services are discoverable and support
  introspection.
• The location of services is transparent to the
  client.
• Services are transport independent.
• Services are platform independent.

13
Services Have Well-Defined Interfaces and Policies

• Well-defined interfaces (contract) are a central
  concept for SOAs. All services publish a
  contract.
• This contract encapsulates the agreement between
  the client of the service and the service.
• Contracts are what the consumer peruses when
  searching for a service.
• The contract contains all the information
  necessary to create an application that is
  capable of accessing the service. Using the
  information in the contract to access and utilize
  the service is called binding.

14
Services Have Well-Defined Interfaces and Policies

• Contracts are a new concept to many IT
  professionals. The old paradigm, carried over
  from procedural programming days from
  object-oriented development (OOD), is that
  applications are a set of classes that provide
  the desired functionality.
• Classes are organized into inheritance
  hierarchies with subclasses inheriting both data
  members and functionality from their chain of
  parent classes.

15
Services Have Well-Defined Interfaces and Policies

• Applications are built from a collection of
  classes that interact with each other via their
  functions. These functions consist of a
  hopefully) descriptive name and a function
  signature. The function signature states what
  data type the class will return and what data it
  requires as input. Function signatures imply
  synchronous, tightly coupled,procedures called
  interactions.
• Classes provide a type to which to bind during
  the compile.

16
Services Have Well-Defined Interfaces and Policies

• This system of classes and subclasses has several
  limitations. Tight (ketat) coupling introduces
  rigidity and makes future enhancements harder to
  implement, which is undesirable in a software
  system of any size. If changes are made in the
  parent, it can affect the functionality of the
  children.
• Incorporating functionality from more than one
  superclass involves multiple inheritance, which
  introduced even more fragility.
• Some object-oriented (OO) languages, Java being
  one of them, do not support multiple inheritance.

17
Web Services

• Web services have been chosen for in-depth
  discussion because they are a well known and
  extremely important example of an SOA
  implementation.
• Many enterprises have already started to
  implement Web services, and most others have
  plans to implement them in the future.

18
Web Services

• Web services are an example of an SOA. One very
  important thing that Web services have over most
  other SOA implementations is that they ad here to
  open standards.
• The open standards that form the basis of Web
  services theoretically allow any Web service to
  interact with any other Web service.
• Proprietary protocols, data translation, and
  vendor lock-in become a thing of the past. The
  menu of solutions for your IT problems grows
  enormously (besar/berkembang).

19
Web Services

• Following are the open standards utilized by Web
  services
• The transport protocols HTTP, FTP, and SMTP
• The messaging protocol SOAP (Simple Object Access
  Protocol)
• The interface description language WSDL(Web
  Services Description Language)
• Registry protocols such as UDDI (Universal
  Description, Discovery, and Integration) and
  repositories such as ebXML

20
Web Services

• One of the SOA principles is that services should
  be independent of the means of transport.
  Currently, all Web services communicate using a
  single transport HTTP. FTP and SMTP are listed
  as alternate Web services transport modalities,
  but they are not particularly popular because
  they preclude (menghalangi) carrying on a
  conversation between applications.
• However, HTTP will continue to be the most
  popular transport for Web services messages for
  some time to come.

21
Web Services

• HTTP is popular for Web services because HTTP
  messages can pass readily through firewalls.
• When you are contemplating connecting to a
  service physically located in a different
  enterprise, or even in a different location
  within the same enterprise, firewall transparency
  is attractive.

22
What is the SOA life cycle?

• The core IT assets of any organization include
  its data, legacy systems (current system),
  line-of-business applications, packaged
  applications, and trading partners. Each of these
  resources is a service provider responsible for
  producing numerous highly specific outputs, such
  as inventories and customer data.

23
What is the SOA life cycle?

• Service orientation ties together these disparate
  and autonomous sources of information, bridging a
  wide range of operating systems, technologies,
  and communication protocols.
• The process by which it does this is an iterative
  one of creating (exposing) new services,
  aggregating (composing) these services into
  larger composite applications, and making the
  outputs available for consumption by the business
  user.

24
What is the SOA life cycle?
25
Expose

• The expose phase of the SOA approach focuses on
  which services to create from the underlying
  applications and data. Service creation can be
  fine-grained (a single service that maps to a
  single business process) or coarse-grained
  (multiple services come together to perform a
  related set of business functions).

26
Expose

• The expose phase is also concerned with how the
  services are implemented. The functionality of
  underlying IT resources can be made available
  natively (secara asli) if they already speak Web
  services, or can be made available as Web
  services though the use of an adapter.

27
Compose

• Once services are created, they can be combined
  into more complex services, applications, or
  cross-functional business processes. Because
  services exist independently of one another as
  well as of the underlying IT infrastructure, they
  can be combined and reused with maximum
  flexibility. And as business processes evolve,
  business rules and practices can be adjusted
  without constraint from the limitations of the
  underlying applications.

28
Consume

• Once a new application or business process has
  been created, that functionality must be made
  available for access (consumption) by either
  other IT systems or by end users. The goal of the
  consumption process is to deliver new, dynamic
  applications that enable increased productivity
  and enhanced insight into business performance.
  Users can consume the composed service through a
  number of avenues, including Web portals, rich
  clients, Office business applications, and mobile
  devices.

29
SOA Issues

• Implementing an SOA environment will cost time
  and money. Some organizations have no budgetary
  process to finance infrastructure development. In
  such organizations, all information technology
  development projects are developed for and
  managed by a specific customer.
• This customer assumes all the costs associated
  with the development of the application. If it
  were decided, under this model, to develop an
  application for a customer using an SOA
  environment, the customer would have to assume
  the entire cost of developing the environment, as
  well as the cost of using it to build the
  application. This system of financing for IT
  projects punishes infrastructure development.

30
SOA Issues

• Applications built using an SOA will not only be
  cheaper to develop and have a faster time to
  market but will be significantly less expensive
  to maintain.
• Unfortunately, it is a common financial procedure
  in most enterprises to separate the cost of
  developing an application from the cost of
  maintaining it. It is well known to software
  engineers that the cost of maintaining an
  application is several times more than the cost
  of developing it. An effective method of
  financing application development is to have the
  customer pay for both development and maintenance
  costs. Using that financial model, what
  maintenance is really costing will become
  painfully evident to the business side of the
  enterprise. When cradle-to-grave financing is
  used, the lower maintenance costs of SOA
  applications will become quickly evident.
  Building an SOA and using it to develop
  applications will demonstrate a positive ROI that
  will more than justify the initial outlay
  required.

31
SOA Issues

• Distributed architectures such as SOA are at the
  other end of the spectrum when it comes to
  specifying and satisfying SLAs. The plus side is
  as follows
• The modular, layered nature of an SOA naturally
  lends itself to setting up parallel,redundant
  athways of communication between the various
  components that are required for the functioning
  of the service. This can help make a server
  resistant to network problems.

32
SOA Issues

• The simple, modular nature of the components in
  the service layer lends itself to achieving
  stated reliability levels through clustering of
  servers.
• Asynchronous communication can be much more
  tolerant of network disruption than synchronous
  communications.
• Since services are located and connected to at
  run-time, it is possible for system architects to
  easily change the location of components in
  response to systems architecture changes.
• Distributed architectures also provide the
  possibility of having applications recover from
  the unavailability of a component by binding to
  an alternative component, perhaps at an
  alternative location.

33
SOA Issues

• Following is the negative side
• The distributed nature of SOAs makes them very
  vulnerable to network issues. Not just gross
  network failures that are easy to spot, but also
  slow, easy-to-overlook network slowdowns and
  intermittent congestion.
• SOAs are hosted on many machines. A seemingly
  innocuous change in the availability any one of a
  number of computers has the potential to disrupt
  a service.
• The complex nature of some systems built on an
  SOA makes it very difficult to mathematically
  derive SLA parameters. Unless you have an
  extremely thorough system to monitor the elements
  of your execution platform, initially any SLA
  numbers will be speculative.
• Yes, there are numerous ways to tune and tweak
  SOA systems. However, that tuning and tweaking
  will cost time and money.

34
SOA Management

• An SOA will eventually become the backbone of
  your business. The business case for it is too
  compelling for it to be otherwise. The more
  central your SOA becomes to your business, the
  more you will require an effective set of
  management tools. The SOA attributes of loose
  coupling and decentralization of service modules
  mandate a centralized control structure. The
  ideal end result is for your SOA to be loosely
  coupled but tightly managed.

35
SOA Management

• Existing network management tools that are not
  designed for SOA management are inadequate to
  manage an SOA for the following reasons
• They are usually binary in nature they can tell
  if an application is up or down. Applications are
  now composed of interacting modules information
  about the health of the modules and of their
  connections is what is required.
• They have no awareness of business processes.
• They have no understanding of the concept of
  grouping modules into functional units.
• They have no way to effectively manage the
  security requirements between the modules in the
  SOA network.

36
SOA Management

• SOA management is a complex issue. We suggest
  examining your needs around the following topics
  before examining SOA management solutions
• Performance information
• Monitoring and management of running services
• Monitoring and management of network issues
• Dynamic method for a service to find and bind to
  its management agent or services
• Management of SOA security issues
• Management of SLAs
• Management of the evolution of services and the
  service life cycle
• Management having the capability to be extendable
  across enterprise boundaries

37
SOA Best Practices

• The following is a short and almost certainly
  incomplete list of SOA best practices. Feel free
  towrite your own in the margins.
• Do your business architecture work first.
  Understand the major business processes and how
  they relate to each other. Map the business
  processes to the data and systems architectures.
  Use that knowledge to plan your SOA.
• Start small Build incrementally. Use the first
  project to build the component infrastructure for
  your SOA. Add to your SOA on an ad hoc basis, and
  document and share what you have learned from
  each SOA project.
• When encapsulating existing legacy functionality,
  use the SOA.

38
SOA Best Practices

• Wire in what you have. Leverage the
  standards-based interoperability of the SOA to
  allow you to integrate your application
  infrastructure.
• Architecture is as important to your Web services
  as to your SOA. Use architectural principles to
  set the contracts that your services offer to
  consumers. Get the grain the size of the service
  you expose in the contract correct. The contract
  should expose a relatively coarse-grained
  contract and fulfill the contract by aggregating
  several fine-grained components.
• Think agile when building services. Make the
  creation of services an opportunity to increase
  the adaptability and efficiency of your
  organization.
• Maximize reuse of components by making them small
  and cohesive.
• Start building in your management tools early in
  your SOA effort. Do not allow yourself to get in
  the position of being forced to retrofit a
  management solution, at great cost to the
  business, when your SOA suddenly starts behaving
  poorly.