SOA PART I: WHAT IS SOA

1
SOA PART I WHAT IS SOA?

• Eben Hewitt
• 9.21.2007

2
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

3
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

4
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

5
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.

6
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.

7
SOA Defined (Take 3)

• "SOA isnt 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

8
What is a Service?

• Service-Oriented is not Object-Oriented. (We lose
  features in translation (polymorphism--even
  though it is in Schema))
• Its not a Java class or a new way to share
  libraries.
• It's not procedural. Dont 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.

9
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

10
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.

11
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.

12
Services Foreground...

• Separating interface from implementation
• Separation of concerns (high cohesion)
• Description over implementation
• Combinatory design

13
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.

14
A Code Puzzle

• Quick without having to know Java, which code is
  better? This
• aFrame.getPanelA().getWidgetX().setText("Hello")
  
• or this
• aFrame.setWelcomeText("Hello")

15
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.
• -Source, IEEE

16
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!

17
DecouplingThe 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.

18
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.

19
The "A" in SOA

20
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.

21
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

22
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.

23
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

24
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

25
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.

26
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.

27
What Do You Need To Make A SOA?

• Language-Independent Web Services Technologies
  Presentation
• XML
• XML Schema
• SOAP
• WSDL 2.0
• BPEL
• ESB

28
XML Example

• lt?xml version"1.0" encoding"UTF-8"?gt
• ltdteperson xmlnsxsi"http//www.w3.org/2001/XMLS
  chema-instance" xmlnsdte"http//schemas.dte.com
  /dtc/general xsischemaLocation"http//schemas.d
  te.com/dtc/general http//schemas.dte.com/dte/gene
  ral/Person.xsd"gt
• ltnamegt
• ltfirstNamegtEbenlt/firstNamegt
• ltmiddleInitial /gt
• ltlastNamegtHewittlt/lastNamegt
• lt/namegt
• ltusAddressgt
• ltstreetgt123 My Streetlt/streetgt
• ltcitygtScottsdalelt/citygt
• ltstategtAZlt/stategt
• ltpostalCodegt85266lt/postalCodegt
• lt/usAddressgt
• lt/dtepersongt

29
SOAP Example

• ltsoapenvEnvelope xsischemaLocation"http//schem
  as.xmlsoap.org/soap/envelope/ http//schemas.xmlso
  ap.org/soap/envelope/" xmlnsxsi"http//www.w3.or
  g/2001/XMLSchema-instance" xmlnsxsd"http//www.w
  3.org/2001/XMLSchema" xmlnssoapenv"http//schema
  s.xmlsoap.org/soap/envelope/" xmlnsdte"http//ns
  .dte.com/dtc"gt
• ltsoapenvBodygt
• ltdtecc1PreApproveApplicationgt
• ltpersongt
• ltnamegt
• ltfirstNamegtEbenlt/firstName
  gtltmiddleInitial /gtltlastNamegtHewittlt/lastNamegt
• lt/namegt
• ltusAddressgt
• ltstreetgt123 My
  Streetlt/streetgt
• ltcitygtScottsdalelt/citygtltstategtAZlt/stategtltpos
  talCodegt85266lt/postalCodegt
• lt/usAddressgt
• lt/persongt
• ltstoreCodegtRIP 22lt/storeCodegt
• lt/dtecc1PreApproveApplicationgt
• lt/soapenvBodygt
• lt/soapenvEnvelopegt

30
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

31
Benefits of ESB

• Maximize co-existence--necessary for incremental
  adoption
• Allows best bet for reuse--rules are
  extrapolated.
• Allows outward point to rules engine

32
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

33
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

34
The Life of a Pre-Approval
35
Demonstration

• QuickScreen Pre-Approval build, deploy, and test
• NetBeans BPEL Designer

36
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.

37
Whats Missing?

• Presentation Tier (clients)
• Corner cases (reporting)
• Projects--a service is not a complete app or
  subsystem

38
More Web Services Standards

• UDDI 3.0
• WS-Security
• Ws-Policy
• WS-Transaction
• WS-Reliable Messaging
• WS-IT
• WS-Human Task
• WS-Federation

39
Related Technologies

• XSLT
• Xquery
• Xlink
• Native XML Databases (eXist, Xindice, Berkeley
  XMLDB)
• Repositories

40
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

41
Reference Architecture Site http//dtcra
42
More Information

• See the SOA Wiki page
• Click Enterprise Architecture and SOA on the
  home page

43
Questions