Docstoc

SOA PART I WHAT IS SOA

Document Sample
SOA PART I WHAT IS SOA Powered By Docstoc
					SOA PART I: WHAT IS SOA?
        Eben Hewitt
         9.21.2007
           Presentation Goals
•   what is SOA and what do we get for it?
•   what are we doing with it?
•   what are relevant tools and APIs?
•   answer your questions
           SOA Team Goals
1. Needlessly rewrite perfectly good, tested,
  working code
2. Lock us into a proprietary platform
3. Take over the world
4. Have all of the fun
     Revised SOA Team Goals
1. Expose existing functionality and data in
  platform-agnostic wrappers
2. Use free, open source tools for new work
3. Reuse the best of what exists, use the right
  tool for the right job.
4. Communicate what we're doing, how we're
  doing it, and empower others to do it too
       SOA Defined (Take 1)
• a standards-based design approach to
  creating an integrated IT infrastructure
  capable of rapidly responding to changing
  business needs by implementing loosely
  coupled, dynamic, manageable applications.
       SOA Defined (Take 2)
• an architectural effort to organize
  development work into a unified and
  consistent design framework that enables
  the organization to identify and respond to
  workflow problems more efficiently.
       SOA Defined (Take 3)
• "SOA isn’t about finding a single
  infrastructure product that addresses all of
  your technology challenges, but instead
  about using architectural guidelines and
  practices to enable the creation and ongoing
  management of a new breed of agile
  applications" --ZapThink
           What is a Service?
• Service-Oriented is not Object-Oriented. (We lose
  features in translation (polymorphism--even though
  it is in Schema))
• It’s not a Java class or a new way to share libraries.
• It's not procedural. Don’t expose your functions.
• Services exchange business documents (Purhcase
  Order, Pre-Approve Application)
• Services can be invoked by desktop, Web, rich client,
  back-end, and mobile presentation layers.
             The "SO" in SOA
• Not OO--not Java++
• Services are typically what humans would call a
  service:
   – Search (GOOG, AMZN)
   – Book a reservation
   – Apply for a credit card
   – Make payments
• Services have a larger atomic level than an object or
  a function
• Service descriptions are dynamically discoverable
  and invokable
           Designing a Service
A Service should:
• be designed to perform discrete functions
• have limited knowledge of how messages are passed
  to or retrieved from it
• have clear boundaries: basic OO principles of
  encapsulation and interface design are important
• be autonomous. Services are isolated and decoupled,
  deployed independently, and communicate only
  using contract-driven messages and external policies.
                 How it works
• Providers publish specific, project-agnostic
  functions that are described in a standard
  description format.
• Clients need use only those descriptions to
  consume a service in a language-independent
  manner.
• Service consumers can be client end-points,
  another service, or a software component that
  orchestrates a set of services to create a business
  rules-based workflow.
         Services Foreground...
•   Separating interface from implementation
•   Separation of concerns (high cohesion)
•   Description over implementation
•   Combinatory design
                   Implications
• A "service" means a collection of specific functions, usable
  across projects.
• Services can be written and consumed in any language.
• The service description must be sufficient to allow a client
  to use the service.
• Tools can automate the process of interacting with the
  service.
• Services can be indirectly invoked via workflows.
• Workflows can combine services to make "composite"
  services.
• Cross-cutting concerns can be factored out of service
  implementations into flows.
             A Code Puzzle
Quick: without having to know Java, which code
 is better?
 This:
aFrame.getPanelA().getWidgetX().
 setText("Hello");

 or this:

aFrame.setWelcomeText("Hello");
             Put Another Way
How would you rather pay the bill for your paper
   delivery?
The paperboy comes to the door, demands $2 for
   that week's paper. Do you...
1) Tell the paper boy where your wallet is, turn
   around to let the paperboy get your wallet out of
   your back pocket, he pulls $2 out of your wallet,
   closes it, puts it back in your pocket.
OR
2) Give him $2.
          What Does that Mean?
• SOA is built on loose-coupling. How do you do that?
• Tell objects what to do, don't ask them for their state!
• Clients want the $2--the paper boy doesn't care if it's in
  your cookie jar or your wallet or in a check or quarters or a
  $2 bill or 2 singles
• Systems are the same--objects are microcosms of systems!
• Queries must be free of side effects: Either Command OR
  Query--not both!
• Decoupling is a Good Thing!
Decoupling:The Law of Demeter
• AKA “Principle of Least Knowledge”
• A method of an object should only use:
  itself, its parameters, any objects it creates, or its direct
  component objects
• Objects should avoid invoking methods of a member
  object returned by another method.
• The resulting software tends to be more maintainable and
  adaptable. Since objects are less dependent on the internal
  structure of other objects, object containers can be changed
  without reworking their callers.
  What Does this Teach us about
             SOA?
• Service Orientation retains the benefits of
  component-based development (self-description,
  encapsulation, dynamic discovery and loading).
• But it shifts focus from remotely invoking
  methods on objects (EJB/Message Transactions),
  to one of passing generic messages between
  services.
• Generic means not transparently tied to any single
  method invocation, any client language can be
  used to read or operate on the messages, and any
  human can read and understand them.
The "A" in SOA
   The Winchester Mystery House
• An intriguing tourist attraction in the USA near San Jose, CA.
• It was home to the heiress of the Winchester fortune (amassed
  from the sales of Winchester rifles). According to the legend,
  the heiress went to see a fortune teller and learned she was
  cursed to be haunted by the spirits of everyone ever killed by a
  Winchester rifle. The only way to avoid the curse was to build
  a mansion – as long as she kept building the spirits would leave
  her alone.
• She promptly hired 147 builders, all of whom began working
  on the mansion simultaneously.
    Facts Regarding the Winchester
            Mystery House
•   It took 38 years to complete
•   Of the 950 doors, 65 of them open to blank walls
•   13 staircases were built and abandoned
•   1 staircase leads into the ceiling
•   The mansion contains 2 basements
•   It has 17 chimneys with evidence of 2 others
•   There are either 5 or 6 kitchens
•   52 skylights were installed into various floors.
•   No architects were hired.
•   No architectural blueprint for the mansion was ever created.
•   This is a classic example of the problems we invite doing
    implementation without architecture
              SOA Governance
• IT governance: responsibility of executive
  management. It is an integral part of enterprise
  governance and consists of the leadership and
  organizational structures and processes that ensure
  that the organization's IT sustains and extends the its
  strategies and objectives.
• SOA Governance: Process of enforcing
  organizational policies and standards and tracking the
  life cycle of each service within a SOA deployment at
  both the Strategic and Technical levels.
    Layers of SOA Governance
• Strategic:
   – Management side. Vision. Align with business.
     What services? What processes? How to
     optimize business processes? Guidance.
     Platforms.
• Technical:
   – how to build, bundling, repository, deploying,
     operating, versioning, mentoring.
• Decouple compliance from services and apps
                 Assertions
•   standards are not architecture
•   architectures are not implementations
•   implementations make business value
•   we need all of them to succeed
•   we therefore work on them concurrently
                Creating a SOA

• Start with a clear understanding of the business vision
• Have well-defined business initiatives and outcomes
• Incrementally deliver “slices” of our SOA
  infrastructure that deliver upon these objectives
• Take an incremental approach to integrating across
  diverse systems
• Because the underlying applications are accessed
  through a standard interface, IT assets are insulated
  from direct change.
         SOA Myths Debunked
• SOA is a technology: it's a design philosophy
• SOA requires Web Services over SOAP: this is often
  the case, but EDI and CORBA are conceptually
  similar, and many people use REST
• SOA requires total overhaul of technology: Smart
  SOAs are built incrementally
• There is a single SOA RA: no two SOAs are the
  same.
• Focus on building a SOA: focus on delivering
  business value.
 What Do You Need To Make A
           SOA?
• Language-Independent Web Services
  Technologies Presentation
  –   XML
  –   XML Schema
  –   SOAP
  –   WSDL 2.0
  –   BPEL
  –   ESB
                        XML Example
<?xml version="1.0" encoding="UTF-8"?>
<dte:person xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:dte="http://schemas.dte.com/dtc/general”
    xsi:schemaLocation="http://schemas.dte.com/dtc/general
    http://schemas.dte.com/dte/general/Person.xsd">
    <name>
           <firstName>Eben</firstName>
           <middleInitial />
           <lastName>Hewitt</lastName>
    </name>
    <usAddress>
       <street>123 My Street</street>
       <city>Scottsdale</city>
       <state>AZ</state>
       <postalCode>85266</postalCode>
       </usAddress>
</dte:person>
                            SOAP Example
<soapenv:Envelope xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/
    http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
    instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:dte="http://ns.dte.com/dtc">
  <soapenv:Body>
       <dte:cc1PreApproveApplication>
           <person>
             <name>
                <firstName>Eben</firstName><middleInitial /><lastName>Hewitt</lastName>
             </name>
             <usAddress>
                <street>123 My Street</street>
               <city>Scottsdale</city><state>AZ</state><postalCode>85266</postalCode>
             </usAddress>
           </person>
           <storeCode>RIP 22</storeCode>
       </dte:cc1PreApproveApplication>
  </soapenv:Body>
</soapenv:Envelope>
         Enterprise Service Bus
• Could be product or set of patterns.
• Brokering various legacy protocols
   – GlassFish does it with JBI--pluggable HTTP, SMTP,
     SQL, JMS
• Orchestration
• Message Transformation
• Message Routing
• State management
• Mediation of integration patterns
• Governance point--automated SLAs: ”X service may only
  invoke other services inside the firewall”
           Benefits of ESB
• Maximize co-existence--necessary for
  incremental adoption
• Allows best bet for reuse--rules are
  extrapolated.
• Allows outward point to rules engine
Implementing Java-Based Web
    Services Presentation
– Creating a Web Service in Java
– JAX WS 2.0
– Creating a Web Service Client
– JAXB 2.0
– Ant tasks: wsimport, jwsc, xjc
– XML Catalogs
  Quick Screen Pilot Project
• Pre-Approve and sign up customers for
  our CarCare One Card
• Pilot project to see immediate ROI
• Business-driven, not IT-driven
The Life of a Pre-Approval
            Demonstration
• QuickScreen Pre-Approval build, deploy,
  and test
• NetBeans BPEL Designer
            Dis/Advantages
• Highly distributed
• Highly scalable b/c throughput is increased
• Added complexity, variety of technologies
  to know
• XML can be verbose, esp when encrypted.
           What’s Missing?
• Presentation Tier (clients)
• Corner cases (reporting)
• Projects--a service is not a complete app or
  subsystem
    More Web Services Standards
•   UDDI 3.0
•   WS-Security
•   Ws-Policy
•   WS-Transaction
•   WS-Reliable Messaging
•   WS-IT
•   WS-Human Task
•   WS-Federation
       Related Technologies
• XSLT
• Xquery
• Xlink
• Native XML Databases (eXist, Xindice,
  Berkeley XMLDB)
• Repositories
        Future SOA Directions
• Continue Creating Business Services
   – Payment
   – Fitment
• Build out Common Services (Customer Lookup) as we go
• Use WS-Policy
• Brokered Regional ESBs
• Incorporate Repositories for Monitoring
• Incorporate Human Task and Federation
• Create More Knowledge Resources
Reference Architecture Site
        http://dtcra
             More Information
• See the “SOA” Wiki page
   – Click “Enterprise Architecture and SOA” on the home
     page
Questions

				
DOCUMENT INFO