1. Service Oriented Architecture
(SOA)
Gabriel Orce
June 2010
© Accenture 2010. All Rights Reserved.

2. Centra Tools
Raise Hand Audio/Connectivity Tips
• Run the Audio Wizard
Yes / No • Choose Tools/Audio Wizard from the
menu at top of screen
Applause • Close all network based
applications
• Outlook, MSN/AOL, other websites,
Office Communicator, etc
Laugh
• Connect via an Accenture LAN or
high speed internet connection
• If using a wireless connection, ensure
Text Chat your signal is as strong as possible
• Monitor the Network Connectivity
Centra Volume Control Bar
• Contact Learning Product Support if
issues continue
Network Connectivity Bar

3. Asking Questions
Two Options:
1. Ask live questions during the designated Q&A sessions:
 Press Raise Hand icon to get faculty’s attention
 Once called upon, there are two options to speak:
- Click the Talk button or
- Press the Ctrl key
When done speaking, unselect the Talk button or release
the Ctrl Key.
2. Post questions at any time in the chat room.

4. Agenda
•Introduction
•SOA architectural principles
•Web enabled technologies for SOA
•SOA and Java
•Case study
•Q & A
© Accenture 2010. All Rights Reserved. 4

5. Introduction
To better understand what Service Oriented
Architecture is, we must first understand what
Service is, and what we mean by Architecture.
© Accenture 2010. All Rights Reserved. 5

6. Services
From a SOA perspective, a service is an abstracted, logical
view of a well-defined business functionality, which could be
consumed by clients in different applications or business
processes.
Services can be new software modules or can wrap around
existing legacy software to give them “service interfaces”.
Examples of typical services:
GetOrderStatus (input: order number, order type.
Returned: the status of the order).
SearchByAuthor (input: Name of author, type of product.
Returned: Titles of the products written by this author).
© Accenture 2010. All Rights Reserved. 6

7. Architecture
Software Architecture is the logical design of
interconnected software components that work towards
the objective of an existing or potential system given the
required resources.
© Accenture 2010. All Rights Reserved. 7

8. Service Oriented Architecture (SOA)
Service Oriented Architecture is a logical way of
designing a software system consisting of a collection of
loosely coupled services (components) that communicate
with each other via standard message exchanging
protocols and through standard interfaces. These service
components may provide services either to end-user
applications or other services distributed in a network.
© Accenture 2010. All Rights Reserved. 8

9. Related Concepts
Service Oriented Integration (SOI): It is the act of
adapting applications and protocols to a SOA environment.
SOI addresses the integration of an IT legacy systems as
reusable services for a SOA environment from an IT
organization. As such, the problems of integrating legacy
and inflexible heterogeneous systems are addressed by
enabling IT organizations to offer the functionality locked in
existing applications as reusable services.
Service Oriented Computing (SOC): It refers to the
paradigm that represents computation in SOA.
© Accenture 2010. All Rights Reserved. 9

10. Agenda
•Introduction
•SOA architectural principles
•Web enabled technologies for SOA
•SOA and Java
•Case study
•Q & A
© Accenture 2010. All Rights Reserved. 10

11. Key Characteristics for Services in SOA
•Loose coupling — Services should be connected to
clients and other services using standard, decoupled
message-based methods. XML document exchanging is
most common.
•Interface-based design — Services implement separately
defined interfaces. The benefit of this is that multiple
services can implement a common interface and a service
can implement multiple interfaces.
•Discoverable — Services need to be found at both design
time and run time, not only by unique identity but also by
interface identity and by service kind.
© Accenture 2010. All Rights Reserved. 11

12. Key Characteristics for Services in SOA
•Coarse-grained — Operations on services are frequently
implemented to encompass more functionality and operate
on larger data sets, compared with component-interface
design.
•Single instance — Unlike component-based development,
which instantiates components as needed, each service is
a single, always running instance that a number of clients
communicate with.
© Accenture 2010. All Rights Reserved. 12

13. Service Types in SOA
Service provider — The software entity that implements a service specification.
Service requester — The software entity that calls a service provider. Note that a
Service requester can be an end-user application or another service.
Service broker — The software entity responsible for linking a requester to a
service provider. A service broker hosts a registry of service descriptions.
Service providers publish services to a service broker. Service requesters find
required services using a service broker and bind to them.
Service
Broker
h
is
fin
bl
d
pu
Service
Service
Provide
bind Client
r
© Accenture 2010. All Rights Reserved. 13

14. Composition and Orchestration
Service orchestration represents the mechanism for
composing services into larger ones to perform a specific
business process. This includes the business logic and
execution order of the interactions between the services
and end clients.
The same services can be reused via recomposition (e.g.,
use a subset of them, but orchestrate them differently)
© Accenture 2010. All Rights Reserved. 14

15. Composition and Orchestration
Relocation Process
Retrieve employee name Employee Name Company employee
Given employee ID information web
Employee ID service
Confirmation
Book flight on date Airline booking web
service
Book
Book employee in hotel on arrival Confirmation
Hotel booking web
date service
Book
© Accenture 2010. All Rights Reserved. 15

16. Agenda
•Introduction
•SOA architectural principles
•Web enabled technologies for SOA
•SOA and Java
•Case study
•Q & A
© Accenture 2010. All Rights Reserved. 16

17. Technologies used in SOA
Web services: are software systems designed to support
interoperable machine-to-machine interaction over a network. This
interoperability is gained through a set of XML-based open
standards, such as WSDL, SOAP, and UDDI. These standards
provide a common approach for defining, publishing, and using
web services. (1)
XML: is a text-based markup language specification from the
WWW Consortium (W3C). In SOA it is widely used for representing
arbitrary data structures and messaging protocols.
WSDL (Web Services Description Language): is a XML-based
language that provides a simple way for service providers to
describe the format of requests and response messages. In
general, WSDL provides an abstract language for defining the
published operations of a service with their respective parameters
and data types. The language also addresses the definition of the
location and binding details of the service.
© Accenture 2010. All Rights Reserved. 17

18. Technologies used in SOA
UDDI (Universal Description, Discovery, and Integration): This
specification provides a common set of SOAP APIs that enable the
implementation of a service broker. It helps facilitate the creation,
description, discovery, and integration of Web-based services.
SOAP (Simple Object Access Protocol): is a lightweight messaging
XML-based protocol for the exchange of information in a distributed
environment. It is completely vendor neutral. SOAP defines a protocol
between requester and provider objects, such that the requesting
objects can perform a remote method invocation on the providing
objects. SOAP is also basically independent of the transport protocol
(http, smtp, jms, etc.). SOAP’s main criticism is usually on the
overhead of the XML processing it implies.
REST (Representational State Transfer): is a web architectural style,
which bases itself on the full exploitation of the http protocol. It
attempts to reuse the http methods making an equivalence between
your semantic operation and the http methods (get, post, put, delete);
it is not based upon "message" concepts as is SOAP. 18

19. WSDL 1.1 Format
definitions Root element of the WSDL document. Defines the
definitions name of the web service and declares multiple
namespaces used throughout the remainder of the
types document .
message types Describes all the data types used between the client
and server (not required if the service uses only XML
Schema built-in simple types).
portType
operations message Describes a single one-way message, whether a
input messages message request or message response.
output messages portType Abstract set of operations supported by one or more
endpoints (commonly known as an interface);
operations are defined by an exchange of messages.
binding binding Concrete protocol and data format specification for a
particular portType.
service service The service element defines the address for invoking
port the specified service. Most commonly, this includes a
URL for invoking the SOAP service (the “port”).
© Accenture 2010. All Rights Reserved. 19

20. SOAP 1.2 Format
Envelope Mandatory. Top element of the XML document
Envelope representing a SOAP message.
Header (optional)
Header Optional. Contains information that might
influence payload processing and that would be
Body
subject to processing by intermediate SOAP
nodes. For example: Authentication information.
Body Mandatory. Contains the payload of the
message. The Body is a container for mandatory
information intended for the ultimate recipient of
the message.
© Accenture 2010. All Rights Reserved. 20

21. Enterprise Service Bus - ESB
ESB is an open standards, message-based, distributed, integration solution
that provides routing, invocation, and mediation services to facilitate the
interactions of disparate distributed information technology resources
(applications, services, information, platforms) in a reliable manner. (Brenda
Michelson, Elemental Links) (2)
ESB Service
Manageme Orchestrati
nt on
Adapter Adapter Adapter Adapter
.NET J2EE Legacy
Applicat Applicati Applicati
ion on on
Legacy
Databases
© Accenture 2010. All Rights Reserved. 21

22. Enterprise Service Bus - ESB
Characteristics:
• Uses XML as the standard communication language
• Usually does not depend on an OS or a programming language
• Supports web services standards
• Includes support for orchestration
• Includes intelligent content-based routing
• Supports messaging (e.g., web services messaging standards or
JMS)
• Includes standard adapters
ESB can assist in giving a SOA solution (but using ESB does not imply a
SOA solution)
© Accenture 2010. All Rights Reserved. 22

23. Agenda
•Introduction
•SOA architectural principles
•Web enabled technologies for SOA
•SOA and Java
•Case study
•Q & A
© Accenture 2010. All Rights Reserved. 23

24. SOA and Java
Web Services can be implemented with Java. Some Web
Services Frameworks that can be used to facilitate this are:
• XFire/CXF
• Apache Axis
• Spring-WS
First let us view the invocation process to understand how web
services work.
© Accenture 2010. All Rights Reserved. 24

25. Service Invocation Process
Client Server
Create Receive
Request Request
SOAP SOAP
Java
code
starts
proces
Java
s Object
Create
Receive Response
Response SOAP
SOAP
© Accenture 2010. All Rights Reserved. 25

26. Service Invocation Process
Example: Server-side Service Invocation (after client creates SOAP
message with request and sends it to server)
1.SOAP message is received from transport (e.g., http).
2.Invoking handlers preprocess the message. E.g., determine target service
(since service may have more than one)
3.Dispatch – given the WSDL operation, determine which Java
class/method to invoke
4.Deserialization – SOAP message content is deserialized into the Java
classes.
5.Java classes do the data processing.
6.Serialize object into an appropriate XML.
7.Wrap this XML into a SOAP message.
8.Respond - place response SOAP on transport.
© Accenture 2010. All Rights Reserved. 26

27. Web Service Code Generation
Java or WSDL code can be generated automatically depending on the
approach.
Two basic approaches:
1.Bottom-up: Write the code and generate the WSDL from it (e.g., with
Axis2, use the Java2WSDL tool).
2.Top-Down: Create WSDL and generate the code based on it (e.g. with
Axis2, use the WSDL2Java tool).
© Accenture 2010. All Rights Reserved. 27

28. Java examples
Let’s go over some practical examples on:
1.Accessing existing Web Services using a Web
Service Testing Tool (SoapUI)
2.Creating a Web service
© Accenture 2010. All Rights Reserved. 28

29. Agenda
•Introduction
•SOA architectural principles
•Web enabled technologies for SOA
•SOA and Java
•Case study
•Q & A
© Accenture 2010. All Rights Reserved. 29

30. Example SOA Case Study
Case study of a SOA implementation
© Accenture 2010. All Rights Reserved. 30

31. Questions & Comments
Two options to ask a question or add your comments to the discussion:
 Use Raise Hand and then hold down the TALK icon or press the
CTRL key; release when done
 Post your question in the Chat Room
© Accenture 2010. All
Rights Reserved.

32. References
1. Service Oriented Architecture (SOA) and Web Services: The Road to
Enterprise Application Integration(EAI) -
http://java.sun.com/developer/technicalArticles/WebServices/soa/
2. Service Oriented Integration With Apache ServiceMix -
http://servicemix.apache.org/articles.data/SOIWithSMX.pdf
3. SOA Using Java Web Services – Mark D. Hansen – 2007 Prentice Hall
4. Service Oriented Architecture with Java – Binildas CA, Malhar Barai,
Vincenzo Caselli – 2008 Packt Publishing
5. Services-based enterprise integration patterns made easy, Part 4:
Enterprise service bus -
http://www.ibm.com/developerworks/webservices/library/ws-
intpatterns4/
© Accenture 2010. All Rights Reserved. 32

33. Thank you for
participating!