SOA PART I: WHAT IS SOA?
• 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,
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
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
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
– Search (GOOG, AMZN)
– Book a reservation
– Apply for a credit card
– Make payments
• Services have a larger atomic level than an object or
• Service descriptions are dynamically discoverable
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
• Clients need use only those descriptions to
consume a service in a language-independent
• Service consumers can be client end-points,
another service, or a software component that
orchestrates a set of services to create a business
• Separating interface from implementation
• Separation of concerns (high cohesion)
• Description over implementation
• Combinatory design
• A "service" means a collection of specific functions, usable
• 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
• Services can be indirectly invoked via workflows.
• Workflows can combine services to make "composite"
• Cross-cutting concerns can be factored out of service
implementations into flows.
A Code Puzzle
Quick: without having to know Java, which code
Put Another Way
How would you rather pay the bill for your paper
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.
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
• 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
• 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
• 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
• 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
• She promptly hired 147 builders, all of whom began working
on the mansion simultaneously.
Facts Regarding the Winchester
• 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
• 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
– Management side. Vision. Align with business.
What services? What processes? How to
optimize business processes? Guidance.
– how to build, bundling, repository, deploying,
operating, versioning, mentoring.
• Decouple compliance from services and apps
• 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
• 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
• Focus on building a SOA: focus on delivering
What Do You Need To Make A
• Language-Independent Web Services
– XML Schema
– WSDL 2.0
<?xml version="1.0" encoding="UTF-8"?>
<street>123 My Street</street>
<street>123 My Street</street>
Enterprise Service Bus
• Could be product or set of patterns.
• Brokering various legacy protocols
– GlassFish does it with JBI--pluggable HTTP, SMTP,
• 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
• Allows best bet for reuse--rules are
• Allows outward point to rules engine
Implementing Java-Based Web
– 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
• QuickScreen Pre-Approval build, deploy,
• NetBeans BPEL Designer
• Highly distributed
• Highly scalable b/c throughput is increased
• Added complexity, variety of technologies
• XML can be verbose, esp when encrypted.
• Presentation Tier (clients)
• Corner cases (reporting)
• Projects--a service is not a complete app or
More Web Services Standards
• UDDI 3.0
• WS-Reliable Messaging
• WS-Human Task
• Native XML Databases (eXist, Xindice,
Future SOA Directions
• Continue Creating Business Services
• 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
• See the “SOA” Wiki page
– Click “Enterprise Architecture and SOA” on the home