Service Oriented Architecture (SOA) is the secret sauce of many software integration and internet technologies. The SOA Series includes five presentations based on IBM SOA Associate Certificate. It gives a very concise, practical overview of SOA concepts. The third presentation discusses the characteristics of a basic SOA architecture, IBM SOA Reference Architecture, enterprise service bus (ESB), role of Web Services and messaging, and the the stages of the SOA lifecycle

1. SOA Architecture
Pouria Ghatrenabi
Based on IBM SOA Certificate Learning Objectives

2. Learning Objectives
• Describe the characteristics of a basic SOA architecture.
• Describe the elements of the IBM SOA Reference Architecture, and
their roles and relationships.
• Describe the enterprise service bus (ESB) and its role in SOA.
• Describe the role of Web Services and messaging in building an SOA.
• Describe orchestration of business processes using services and
human interactions.
• Describe the stages of the SOA lifecycle (model, assemble, deploy,
manage.)

3. IBM SOA Foundation
SOA Life Cycle
• model
• assemble
• deploy
• manage
Reference
Architecture
Programming
Model
SOA Scenarios
Ref: Buecker et al. (2008), p 408

4. Characteristics of SOA
Architecture

5. Characteristics of a Basic SOA Architecture
SOA Architecture Aspects
SOA Architectural
Domains
SOA Architectural
Characteristics

6. The Characteristics of SOA
Platform
• The service implementation platform should not be relevant to consumers, including intermediary layers,
communication protocols, and perhaps even application layers.
Location
• Several instances of the same service may exist in different locations to support service delivery scalability.
Protocols
• Protocol independence is an aspect of SOA.
Programming Language
• SOA should be implemented independent of any programming language
Invocation Patterns
• It is the overall flow of interaction between requester and a provider. There is a growing demand for one-time services
that does not need any synchronization and state management.
Security
• Should be balanced with performance, system management, and complexity

7. The Characteristics of SOA (continued)
Service Versioning
• There are two types of changes in WSDL documents:
• Backward-compatible
• Adding new service operations to an existing service description.
• Adding a new XML Schema within a WSDL document
• Non-Backward-compatible
• Removing an operation
• Renaming an operation
• Changing the parameters of an operation
• Changing the structure of a complex data type
Service Model
• Reusability implies a canonical service model that reflects the enterprise view of its business services.
Information Model
• There is usually a semantic coupling of business data models between the two sides.
Data Format
• Data formats are often transformed during to an exchange into XML formats

8. Elements of the IBM SOA
Reference Architecture

9. SOA Foundation Reference Architecture: Solution view
Ref: Buecker et al. (2008), p 420

10. SOA Foundation Reference Architecture: Middleware Services view
(Logical Architecture)
Ref: Buecker et al. (2008), p 421

11. The Domains of SOA
Reference: Bieberstein, et al.(2006), p36

12. Infrastructure Services
Resource virtualization Services
• The closest to the hardware,
• Enable a platform-independent environment for the execution of services in a network,
• Tightly related to Grid Computing concepts.
Service-Level Automation and Orchestration
• Includes automated services for problem management, system failure recovery, workload balancing,
system security services, and data provisioning.
• Facilitates automated management of required service levels and policies,
• Enables self-managing computing systems,
• Leverages the role of IT staff to focus on higher level of operation management
Utility Business Services
• With the help of an Enterprise Service Bus, more specialized utility services can be built in a manner
similar to application services

13. Enterprise Service Bus (ESB)

14. • ESB is a core intermediary, a means to tie services together into
componentized, logical sets, ensuring minimal heterogeneity in the
business semantics exposed by the service,
• The sets reflect the structure of business and are designed for
distributed use across the enterprise,
• ESB is an architectural construct that parallels the business process
environment
Ref: Bieberstein, et al.(2006), p43

15. Enterprise Service Bus (ESB) Concept
Reference: Bieberstein, et al.(2006), p44

16. The Role of WSDL in ESB
• ESB enables invoking and using business functions in components,
regardless of API or protocol, by using them as services defined by a
standard interface description based on WSDL.
• WSDL separates the abstract description of service interfaces, the
reusable protocol bindings for the service, and the actual deployed
endpoints offering the service.
Ref: Bieberstein, et al.(2006), Ch 3

17. The Role of WSDL in ESB (continued)
• WSDL inherent extensibility allows any unit software to be described
directly regardless of the protocol that is used to expose the service
API such as
• MS .Net
• Enterprise Java Beans (EJB)
• COBRA
• Java Messaging Service (JMS)
• ...
Ref: Bieberstein, et al.(2006), Ch 3

18. The Essential Infrastructure Services by ESB
Transport
Quality-of-
service-based
Routing
Mediation
Gateway
Services
Ref: Bieberstein, et al.(2006), Ch 3

19. Transport
• The essential transports for Web Services are
• SOAP over HTTP
• SOAP over HTTPS
• SOAP over JMS
Ref: Bieberstein, et al.(2006), Ch 3

20. Quality-of-Service-Based Routing
• The Support of Quality of Service (QoS) features in an ESB enables the
support and delivery of services according to defined SLAs.
• In Web Services, QoS can refer to the quality of the availability,
accessibility, integrity, performance, reliability, regulatory, and
security capabilities of the service.
Ref: Bieberstein, et al.(2006), Ch 3

21. Mediation
• Mediation enables intelligent processing of service requests and
responses, events, and messages.
• Mediations can be implemented at application service endpoints
(either requestor or provider) or can be distributed through the
infrastructure of the bus.
Ref: Bieberstein, et al.(2006), Ch 3

22. Mediation (continued)
Transformations
• XML-to-XML translations, DB lookups, and aggregations.
Message Validation
• Verification of any data field with specific rules
Content or Quality Service Selections
• A service selection based on content or on required QoS
Content-based Routing
• Routes the messages based on some parameters in the message content
Ref: Bieberstein, et al.(2006), Ch 3

23. Mediation (continued)
Customized Logging
• A legal requirement for logging and audit tasks
Metering and Monitoring
• All manageability anchor points in a bus to control its own behavior
Automatic Behavior
• Used to react when events are detected- to self-configure, heal, optimize, etc.
Policy Management
• Allows a description of all of the listed behaviors rules through externalized policies
based on XML
Ref: Bieberstein, et al.(2006), Ch 3

24. Mediators (Mediation Continued)
• Intermediary components that operate on logical Web Service SOAP
message representation between the requestor and the provider
• Can be located close to requestor, provider, or halfway
• In best practice implementations, mediators should use Java WS
SOAP-handling standard: JAX-RPC
Ref: Bieberstein, et al.(2006), Ch 3

25. Gateway Services
• An additional component of a bus that provides controlled access to
the bus for external partners. Some of typical functions include
• Hiding details of individual internal services,
• Validation user access,
• Controlling access,
• Auditing requests.
Ref: Bieberstein, et al.(2006), Ch 3

26. The Role of Web Services and
Messaging

27. Web Services Technology
A collection of standards that
can be used to implement an
SOA
That is not to say that Web
services and SOA are
intrinsically linked, because
they can be implemented
separately
Vendor- and platform-neutral,
interoperable, and supported
by many vendors
Ref: Buecker et al. (2008), pp 408 & 412

28. Web Services Technology (continued)
• Self-contained, modular applications, that can be described,
published, located, and invoked over networks;
• The services can be new or wrapped around existing applications.
• Many significant SOAs are proprietary or customized implementations
that are based on reliable messaging and Enterprise Application
Integration middleware.
Ref: Buecker et al. (2008), pp 408 & 412

29. Logical Links of SOA and Web Services
• Web services provide an open-standard model for creating explicit,
implementation-independent descriptions of service interfaces.
• Web services provide communication mechanisms that are location-
transparent and interoperable.
• Web services are evolving through Business Process Execution
Language for Web Services (WS-BPEL), document-style SOAP, and
WSDL to support the implementation of well-designed.
Ref: Buecker et al. (2008), p 408 & 412

30. Stack View of Web Services Technology
Ref: Buecker et al. (2008), p 411

31. Approaches to Generating a Web Service
Bottom-up Approach
• An existing application is used to generate the Web service, which includes a service
wrapper used to expose application functionality.
Top-down Approach
• An existing service definition WSDL is used to generate a new application for a
specific programming language and model.
Composition
• An existing group of already generated Web services provides a new combination of
functionality (multiple services). Composing a new Web service in this way might
include the use of workflow technologies.
Ref: Buecker et al. (2008), p 412

32. Orchestration of Business
Processes
Using Services and Human Interactions

33. • Taking people as a core entry point, SOA improves people
productivity by aggregating views that deliver information and
interaction in the context of a business process,
• This enables human and process interaction with consistent levels of
service,
• Start by building a view of a key business process by aggregating
information to help people make better decisions,
• The next steps are tighter management of performance with alert-
driven dashboards that link to more processes.
Ref: Buecker et al. (2008), p 406

34. • Participating tasks are initiated by the system (process), which
requires a human response to continue execution.
• The system initiates the task and an individual from the candidate
executers claims the task and executes it.
• The human agent then provides the output back to the system,
notifying it of its completion.
Ref: Mabrouk, (2008)

35. • Originating tasks are initiated by a person through a user interface.
• They target a system; a person creates an originating task and starts
it; and a request is sent to the system to run the services that are
needed.
• As soon as the system finishes executing, a notification is sent to the
initiator.
Ref: Mabrouk, (2008)

36. • Purely human tasks are, like originating human tasks, created and started
by a person.
• And, like participating human tasks, they target another person who then
claims and completes the task.
• Purely human tasks don't interact with business processes or other web
services.
• They're not automated tasks, yet they pass through the same cycle of
assignment and notifications.
Ref: Mabrouk, (2008)

37. Stages of the SOA Lifecycle

38. Picture Reference: (McBride, 2007)

39. Stages of the SOA Lifecycle
Model
• Gathering business requirements, designing, simulating, and
optimizing customer desired business processes.
Assemble
• Implement optimized the business processes by combining newly
created and existing services to form composite applications
Reference: Carter, S. (2007)

40. Deploy
• The assets are then deployed into a secure and integrated environment, taking
advantage of specialized services that provide support for integrating people,
processes, and information.
• This level of integration helps ensure that all the key elements of your
company are connected and working together.
Manage
• Once composite applications are deployed, customers manage and monitor
applications and underlying resources from both an IT and a business
perspective.
• Information gathered during the Manage phase is used to gain real-time
insight into business processes, enabling better business decisions and feeding
information back into the lifecycle for continuous process improvement.
Reference: Carter, S. (2007)

41. References
• Bieberstein, N., Bose, S., Fiammante, M., Jones, K., & Shah, R. (2006). Service-Oriented
Architecture (SOA) Compass-Business Value. Planning, and Enterprise Roadmap, IBM
developerWorks.
• Buecker, A., Ashley, P., Borrett, M., Lu, M., Muppidi, S., Readshaw, N., & others. (2008).
Understanding SOA Security Design and Implementation. IBM Redbooks.
• Carter, S. (2007). The new language of business: SOA & Web 2.0. Pearson Education.
• IBM. (2015, December 5). SOA Governance and Service Lifecycle Management. Retrieved from
https://www-01.ibm.com/software/solutions/soa/gov/lifecycle/
• Mabrouk, M. I. (2008, September 5). SOA fundamentals in a nutshell. Retrieved December 12,
2015, from http://www.ibm.com/developerworks/webservices/tutorials/ws-soa-ibmcertified/ws-
soa-ibmcertified.html
• McBride, G. (2007, March 15). The Role of SOA Quality Management in SOA Service Lifecycle
Management. Retrieved from
http://www.ibm.com/developerworks/rational/library/mar07/mcbride/
• Portier, B., & Budinsky, F. (2004, September 28). Introduction to Service Data Objects. Retrieved
from http://www.ibm.com/developerworks/library/j-sdo/