This wrap-up session of WSO2's SOA Summer School brings you the best of all sessions conducted over the past 8 weeks. Enterprise architects, developers, consultants and business analysts can now gain an overall understanding of SOA concepts and implementations of end-to-end SOA solutions.

1. Wrap-Up Session
Asanka Abeysinghe,
Prabath Siriwardena,
Ruwan Linton,
Keith Chapman,
Nandika Jayawardena,
Milinda Pathirage.

2. Summer School

3. Summer School

4. Summer School

5. Summer School

6. Agenda
 SOA Enterprise Architecture Patterns
 Use-Case #1 – MDM & EDA
 Scalable SOA
 Use-Case #2 – Service Broker Pattern, Functional
Decomposition, Secured Subsystems, Service
Encapsulation,
 ESB and SOA
 Security in SOA
 Use-Case #3 – Aggregated Data Pattern and Logical
Flows
 Marshups for SOA
 BPM and SOA
 Use-Case #4 – Shared Repository, Version
Identification Pattern, Compatible Change Pattern
 SOA Governance
 Use-Case #5 – Adapters and High Performance
 C++ in SOA
 Summary

7. Patterns
A generic solution for a common recurring
problem.
 Used it before
 Error proof
 Catalog to pick one
 Feel comfortable

8. SOA Patterns
SA Patterns
OO Patterns
EAA Patterns
EAI Patterns Other
OO - Object-Oriented
SA – Software Architecture
EAI – Ent. Application Integration
EAA – Ent. Application Architecture

9. SOA Infrastructure

10. Solution Building Roadmap
Requirements Business PatternsIntegration Patterns
Application Patterns
Runtime Patterns
Product Mappings

11. USE-Case-1 (Business Scenario)
SOA infrastructure going to implement in an environment that
contains legacy systems and legacy databases that running for
a long time. Existing systems are error proof and the data is
valuable to make decisions.
Throw the old sys-
tems away.....
Data ?
NO SOA $$$$

12. USE-Case-1 (Pattern Mapping)
 MDM (Master Data Management)
Pattern
 EDA (Event Driven Architecture)

13. USE-Case-1 (Implementation)
MDM

14. USE-Case-1 (Implementation) cont..
MDM

15. USE-Case-1 (Implementation) cont..
MDM
EDA

16. Scalable SOA

17. Web services clustering
 Different servers
providing the same
service
 Group communication
among the servers
 Shared resources for
the cluster

18. Motivation for Clustering
 Achieving high availability and scalability
 Enterprise Service Buses (ESB)
 De­facto standard for integrating autonomous
entities
 Could become the bottleneck in the system
 High availability and high scalability critical
 Ability to cluster is an essential functionality for an
ESB in a SOA deployment
 Service hosting engines
 Needs to be able to plug into clusters

19. Scalability
 Ability to
 Handle growing amounts of work in a
graceful manner
Or
 Be readily enlarged

20. Availability
 The degree to which a system, subsystem, or
equipment is
 Operable and in a committable state at the
start of a mission
 When the mission is called for at an
unknown

21. A Computer Cluster is...
 A group of coupled computers that works
closely together
 As if they were a single computerh

22. State­full Session Aware Load
Balancing
● Transport and SOAP session
Load Balancer

23. Fail­Over with LB
Load Balancer

24. LB and FO Groups
Load Balancer

25. Dynamic LB
Load Balancer

26. Dynamic LB (Cntd..)
Load Balancer

27. USE-Case-2 (Business Scenario)
A system has connected a service client and a service in P2P.
System is running on production.
Backend Service development team decided to bring bunch of
changes to the backend service(s).
 Secure the backend service.
 Change the service contract.
 Bring multiple services instead of the single service.
Change
Again ?
Service Client/Frontend developers
PMs, Financial dept, HR Dept

28. USE-Case-2 (Pattern Mapping)
 Service Broker Pattern with ESB
 Pipes and Filters
 Transform
 Route
 Trusted Subsystems
 Functional Decomposition
 Service Encapsulation

29. USE-Case-2 (Implementation)
Pipes and filters
Route
Trusted subsystems

30. USE-Case-2 (Implementation) cont..
Pipes and filters Mediation
Route DBLookup
Transform

31. USE-Case-2 (Implementation) cont..
Pipes and filters
Route

32. USE-Case-2 (Implementation) cont..
Pipes and filters
Route
Functional decomposition
Service encapsulation

33. ESB and SOA

34. A common ESB definition
“Any to any data connectivity and
transformation (including Web Services)
built on an advanced, proven, reliable
middleware infrastructure”

35. SOA can end up as spaghetti
• Too many point-to-point links
• Multiple protocols, different qualities of service
• No clear picture of all available services

36. An ESB can simplify SOA deployment
Virtualization
Perf Mgmt
•Load balance
•Throttle
Transport
matching
Access control
Message
transform
Logging and
auditability
Integrated
Registry/
Repository
Web-based console

37. The Concentrator Pattern
Mashup/Web Application
Dashboard
Concentrator ESB
Consistent access, security, logging, audit, monitoring
But no transformation
.NET CRM Apache
C/C++ Data
service service Axis2
service service
service

38. The Federated ESB pattern
Department
ESB
Enterprise ESB
Routing, Audit
Department
ESB
Department
ESB

39. Anti-Patterns
 Anti-Pattern #1
 Implement all your business logic in the ESB
 Why not?
 Mixing Infrastructure logic and Business Logic
 Maintainability
 Tooling and Skills
 Anti-Pattern #2
 Apply waterfall and application deployment
approaches to the ESB
 Long project cycles
 No iterative approach
 Why not?
 Lose all flexibility and agility
 Once the ESB becomes a static, code-driven system
then you would be better off updating your
applications

40. Anti-Pattern #3
 “Big Brother”
 The ESB is hosted, managed and controlled by
a central IT team
 Because of organizational issues using the ESB
is complex:
 e.g.
 It takes months of meetings to get access
 The Central IT team is trying to recoup the investment and
internally charges $000/year to use the ESB
 The central IT deployment model holds up users
 Departments and divisions actually sneak
behind the ESB
 Set up peer-to-peer communications
 Avoid the ESB at all costs

41. The biggest Anti-Pattern of all
 Use an ESB because:
 You heard it was a good idea
 The salesman told you that you need one (over a
nice dinner)
 You need a new TLA on your resume/CV
 Its an excuse to spend several months learning
and going to conferences

42. Security in SOA

43. The Concentrator Pattern
Mashup/Web Application
Dashboard
Concentrator ESB
Consistent access, security, logging, audit, monitoring
But no transformation
.NET CRM Apache
C/C++ Data
service service Axis2
service service
service

45. Provides a single entry point and allows
centralization of security enforcement for
incoming and outgoing messages.
Helps to apply transport-level and message-
level security mechanisms required for securely
communicating with a Web services endpoint.

46. Message Interceptor Gateway
Pattern

47. Authentication
Module
Authorization Mod-
ule [PEP]
LDA
P
Ser- Ser- Ser-
vice A vice B vice C

48. Authentication
Module
Authorization Mod-
ule [PEP]
LDA
P
Ser- Ser- Ser-
PDP
vice A vice B vice C

49. Authentication
Module
Authorization Mod-
ule [PEP]
LDA
P
Ser- Ser- Ser-
PDP
vice A vice B vice C
Policy
Store

50. Authentication
Module
Authorization Mod-
ule [PEP]
LDA
P
Ser- Ser- Ser-
vice A vice B vice C PDP
Policy
Store

51. Authentication PAP
Module
Authorization Mod-
ule [PEP]
LDA
P
Ser- Ser- Ser-
vice A vice B vice C PDP
Policy
Store

52. USE-Case-3 (Business Scenario)
ABC company got several development groups that use various
Time tracking applications developed on SOA to track the effort
putting for the tasks.
Accounts department needs various reports from these different
Systems as a single view.
Some reports go through a validation process through some
sub-systems and the management wants to monitor the process.

53. USE-Case-3 (Pattern Mapping)
 Aggregated Data Pattern
 Logical Flows

54. Mashups in SOA

55. What is a Mashup?
A mashup is a Web site that combines content data
from more than one source to create a new user expe­
rience.

57. Mashup Characteristics
● Situational application, consuming Web APIs
● Characteristics
● Lightweight
● Customized
● Aggregates data / Composes services
● Often combines personal and public data
● Recursive?

58. Metcalfe's law
Metcalfe's law states that the value of a
telecommunications network is proportional to the
square of the number of connected users of the sys­
tem (n2).

59. Metcalfe's law

60. Metcalfe's law Adjusted...

61. Importance of Mashups in a
SOA
● Helps bridge users to your SOA
● Emails
● IM
● Feeds
● Create mock services
● Helps create a prototypes quickly
● Improves Agility

62. BPM in SOA

63. What is a business process?
• A process you need to run your business!
• Any well-defined interaction between
systems and people, triggered by events,
using logical decision points, and with
clearly defined flows

64. Why business process matter?
• Enterprise applications and information
systems have became fundamental assets
• Enterprise information systems can
improve the efficiency of businesses
through automation of business processes
• To stay competitive applications must
quickly and efficiently adept to changing
business needs

65. Business Process Management
•Defining, Executing, and Monitoring
Business Processes Typically long-running,
stateful processes
Model
Innovate BPM Execute
Monitor

66. How does BPM fit with SOA
•Business Process Management needs to
connect to ‘operations’
–When processing an order, connect to the billing
system and raise an invoice
–When handling a problem ticket, connect to the
ticket management system
–Etc
•These operations could be direct
connection in-memory, but much more
likely to be distributed
•A service oriented architecture provides
the best way to connect the BPM to the SOA

67. BPM and SOA
BPM
Long running co­ordination state
SOA
Stateless service interactions
Applications, Databases, Legacy
Persistent application state

68. How does BPM work?
•Model
–Create a visual map of your process
•Refine
–Convert that visual map into an executable
process
•Execute
–Run that process
•Monitor
–Use built-in capabilities of the BPM platform to
monitor the state of processes

69. Executable business processes
•There are many approaches to executable
business processes:
–XPDL
–BPML
–YAWL
–jBPM
–WS-BPEL 1.1
BPEL 2.0
The industry standard

70. WS-BPEL
• Orchestration language used to describe
execution logic of Web services
applications by defining their control flows
and providing a way for partner services
to share a common context
• With WS-BPEL, you build a business
process by integrating a collection of Web
services into a business process flow

71. Understanding the relationship
between BPMN and BPEL
•BPMN is like UML
–Useful, especially as a higher level modeling
approach
–Allows formal modeling of processes by a
business analyst
–BPMN diagrams cannot be executed
•BPMN 2.0 is looking to define a better path to execution
•BPEL is like Java
–Can be directly executed
–Can be visualized using a graphical editor
–Can be created using BPMN as a guide
(refinement)
–

72. BPEL4People model

73. Monitoring Processes
•A key benefit of BPM
•Can range from:
–Simple stats on processes
–Inspect individual instances
–View overall flows across a process map
–Building custom business reports on specific
measures
•E.g. Sales / hour over the last week

74. USE-Case-4 (Business Scenario)
SOA development team needs to keep the metadata in a central
Place, manage them version them and get ready for the changes.
Same time looking to limit access to specific metadata sets.

75. USE-Case-4 (Pattern Mapping)
 Shared repository
 Version identification
 Compatible change

76. SOA Governance

77. Governance

78. Categorize
Metadata Control
Monitor

79. Implementation
 Identify the SOA architecture
 Identify the governance team
 Pick a framework, product
 Iterative process
 Data entry, configuration, (approach)
 Dry run
 Live run
 Govern your SOA infrastructure

80. USE-Case-5 (Business Scenario)
A C/C++ Development team wants to implement SOA application, they
Will be reusing some existing Java and .Net backend services.
They are more keen about the re­usability of services and performance.

81. USE-Case-5 (Pattern Mapping)
 Adapters

82. C++ in SOA

83. Why use C++
● C++ is still widely used in the industry
due to
● Performance advantage of the native
code
● Flexibility available from object
oriented language
● Tight control over memory and CPU

84. Typical applications that use
C++
● Applications which require high
performance and the ability to handle
large volumes of data
● Financial Market Applications
● Large E-Commerce applications
● Banking Applications
● Telecommunication Systems
● Data Base Systems
● Applications which require tight control
over memory and CPU
● Operating Systems (C/C++)
● Embedded Systems

85. A Use­Case
● A legacy C++ system which has been
performing useful work for a long time.
This has remained isolated while all other
systems in the organization evolved and
connected together.
● Need to integrate this system with other
applications to use its functionality in a
broader perspective.
● Options
● Rewrite the system ( Costly )
● Integrate using EAI
● Integrate using a native Web Services Stack

86. A Use­Case
SAP
.N E T
Legacy
System S e c u r e , R e lia b le , B in a r y
J2EE
W e b S e r v ic e s
C IC S
Java

87. How to adapt a C++ Application
as Web Services

88. Native Web Services Stack
● What would you look from a native web
services stack ?
● Support for Basic Web Services Standards
● Tooling for WSDL
● Portability
● Performance / Low memory foot print
● Security
● Ability to handle binary data
● Interoperability
● Asynchronous communication

89. Portability
● My legacy application is running on
platform 'X'. Does your Web Service
stack run on it ?
● It can boil down to multitude of issues
● Differences in operating system versions
● Differences in build tool versions, compiler
versions
● Dependency problems

90. Performance
● Performance is a broad area. Usually
Performance means response time. In
another way, how many requests can
the server handle per second
● However, performance depends on the
system's hardware as well as load on
the system
● Does the performance stay constant or
does it degrade over time
● How does the performance vary with
the size of the messages, load of the
system

91. Low Memory Foot Print
● Some servers take large amount of
memory just to start up
● How much memory does it require to
run efficiently ( Important in embedded
systems)
● Does the memory usage stay constant
while handling large xml messages,
large binary content

92. Student Lab
(Practical Sessions)

93. Student Lab

94. Student Lab

95. Contacts
 Corporate web site: http://wso2.com
 Developer portal: http://wso2.org
 Business development team: bizdev@wso2.com

96. Q&A