• Like

Ss Wrap Up Session 13 Aug

  • 485 views
Uploaded on

 

More in: Technology , Sports , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
485
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
24
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 44. 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.
  • 45. Message Interceptor Gateway Pattern
  • 46. Authentication Module Authorization Mod- ule [PEP] LDA P Ser- Ser- Ser- vice A vice B vice C
  • 47. Authentication Module Authorization Mod- ule [PEP] LDA P Ser- Ser- Ser- PDP 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 Policy Store
  • 49. Authentication Module Authorization Mod- ule [PEP] LDA P Ser- Ser- Ser- vice A vice B vice C PDP Policy Store
  • 50. Authentication PAP Module Authorization Mod- ule [PEP] LDA P Ser- Ser- Ser- vice A vice B vice C PDP Policy Store
  • 51. 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.
  • 52. USE-Case-3 (Pattern Mapping)  Aggregated Data Pattern  Logical Flows
  • 53. Mashups in SOA
  • 54. 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. 
  • 55. Mashup Characteristics ● Situational application, consuming Web APIs ● Characteristics ● Lightweight ● Customized ● Aggregates data / Composes services ● Often combines personal and public data ● Recursive?
  • 56. 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).
  • 57. Metcalfe's law
  • 58. Metcalfe's law Adjusted...
  • 59. 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
  • 60. BPM in SOA
  • 61. 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
  • 62. 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
  • 63. Business Process Management •Defining, Executing, and Monitoring Business Processes Typically long-running, stateful processes Model Innovate BPM Execute Monitor
  • 64. 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
  • 65. BPM and SOA BPM Long running co­ordination state SOA Stateless service interactions Applications, Databases, Legacy Persistent application state
  • 66. 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
  • 67. 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
  • 68. 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
  • 69. 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) –
  • 70. BPEL4People model
  • 71. 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
  • 72. 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.
  • 73. USE-Case-4 (Pattern Mapping)  Shared repository  Version identification  Compatible change
  • 74. SOA Governance
  • 75. Governance
  • 76. Categorize  Metadata Control Monitor
  • 77. 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
  • 78. 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.
  • 79. USE-Case-5 (Pattern Mapping)  Adapters
  • 80. C++ in SOA
  • 81. 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
  • 82. 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
  • 83. 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
  • 84. 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
  • 85. How to adapt a C++ Application  as Web Services
  • 86. 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
  • 87. 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
  • 88. 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
  • 89. 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
  • 90. Student Lab (Practical Sessions)
  • 91. Student Lab
  • 92. Student Lab
  • 93. Contacts  Corporate web site: http://wso2.com  Developer portal: http://wso2.org  Business development team: bizdev@wso2.com
  • 94. Q&A