Download PowerPoint Presentation


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • ZAPThink, a leading researcher of things SOA, likens SOA to the buidling toy: Lego blocks are interoperable. Yes, it's all about the bumps. Because the blocks all have standard bumps, any Lego block will fit into any other Lego block. Standards-based interfaces are the secret to the blocks' interoperability -- or to be more precise, it's the Service contract that matters. After all, we've had decades of standards-based interfaces of various sorts and that hasn't gotten us that close to the Lego vision. Lego blocks are unbreakable. When was the last time you saw half a Lego block? Even the most rambunctious three-year-old can't damage the things. Clearly, the business would appreciate it if IT could deliver capabilities that were as unbreakable as Lego blocks. Now, it's not that Lego blocks are truly unbreakable, but rather, that the Lego Group designed them with significant robustness in mind. And that's what we want from SOA -- a design for robustness. The key is that it's the architecture of the Lego block that makes it strong enough for a three-year-old, just as IT needs to function in a way that's robust enough for business. Lego blocks are composable. One Lego block by itself is no fun at all. The whole point to the toy is taking many of them and assembling them to meet the need of the day, just as the business wishes to compose Services into applications that implement business processes in a flexible way. Lego blocks are reusable. On the one hand, you can build one structure with your blocks, then disassemble it and reuse the blocks to build something else. Another way of looking at reusability is to consider the colors of the blocks. If you consider, say, all red blocks to represent customer information Services, for example, then you can easily use red blocks in many different structures, just as you can compose customer information Services into many business processes.
  • The SOA metamodel describes the service environment. Prior to migrating to Service Oriented Processes, an organization will generally start defining services then turn existing software components into services and ‘hard-wire’ interfaces It consists of Service Models (which MUST BE platform independent), Business Model and Platform dependant models. Service models relate to the Business Model through Business Process Definitions while the relate to the Platform Dependant Models via Requirements Implementation (Use Cases and deployment diagrams) Business Process should evolve to Service Oriented Processes that articulate the Orchestration (flow of a process using individual services. Composition where two or more services combine to create coarse grained functionality,and Transactions – fine grained services. Each process in the Service Oriented Process exposes and Interface that permits other items in the same or higher level process. Choreography defines the ways in which multiple processes interact
  • Download PowerPoint Presentation

    1. 1. Service Oriented Architecture What it is and why you need it.
    2. 2. Agenda <ul><li>Why SOA </li></ul><ul><li>What is SOA? </li></ul><ul><li>Government of Canada SOA </li></ul><ul><li>Oracle SOA Suite </li></ul><ul><li>Some of the Challenges </li></ul><ul><li>Conclusion </li></ul>
    3. 3. Why SOA? <ul><li>“ The business simply wants composable, reusable, interoperable, unbreakable components they can leverage in flexible ways to meet the changing needs of the business.” ZapThink Dec 11, 2006 </li></ul>
    4. 4. Why SOA? “ Departments have a huge investment in their application environment, horizontal government programs and mandates are becoming increasingly common, new development is so expensive – there must be a better, faster, cheaper way to do things.” IT/NET, April 2007
    5. 5. What is SOA? Some definitions <ul><li>Service </li></ul><ul><ul><li>“ useful labour that does not produce a specific commodity ” </li></ul></ul><ul><ul><li>“ a facility supplying some public demand” </li></ul></ul><ul><li>Source: Merriam-Webster Online </li></ul><ul><li>Architecture </li></ul><ul><ul><li>The description, through words and/or pictures of the elements of a system and their interactions with each other and with other systems </li></ul></ul><ul><li>Service Oriented Architecture </li></ul><ul><ul><li>The description of the system elements that enable the supply of something useful which has a public demand </li></ul></ul>
    6. 6. What is SOA? Example
    7. 7. What is SOA? Elements of SOA <ul><li>Defined Service Types </li></ul><ul><ul><li>Tells developers how to approach a task </li></ul></ul><ul><ul><li>Guides analysts in “what’s possible” </li></ul></ul><ul><ul><li>Shows how to do the same thing on multiple platforms </li></ul></ul><ul><li>Process Driven Software </li></ul><ul><ul><li>A transition away from the traditional task- centric Applications </li></ul></ul><ul><ul><li>Designed to mirror the way people work </li></ul></ul><ul><ul><li>Consumes services in support of processes </li></ul></ul><ul><ul><li>Permits transfer of data/functionality across organizational boundaries </li></ul></ul><ul><li>Exposure of existing software components as services </li></ul><ul><li>Build as you go </li></ul>
    8. 8. What is SOA? Defined Service Types <ul><li>Services Types support: </li></ul><ul><ul><li>Estimating </li></ul></ul><ul><ul><li>Consistency of implementation </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Reusable Functionality </li></ul></ul>Service Contract Interface 1 Operation a Operation b . . . Interface 2 Operation a Operation b . . . Implementation Business Logic Data
    9. 9. What is SOA? Process Driven Software SOA Metamodel Service Model Business Model Business Process Definition Requirements Implementation Service Oriented Process Platform-Dependant Models Platform-Dependant Models Platform-Dependant Models Platform-Dependant Models
    10. 10. What is SOA? Summary <ul><li>Service Oriented </li></ul><ul><ul><li>Processes and system working together to provide something of value </li></ul></ul><ul><li>Architecture </li></ul><ul><ul><li>The definition and communication of: </li></ul></ul><ul><ul><ul><li>how it is done and </li></ul></ul></ul><ul><ul><ul><li>how to do it </li></ul></ul></ul><ul><li>The ultimate value provided by Service Orientation is that it permits existing software assets to be used longer, in more ways that mirror the way your organization does things </li></ul>
    11. 11. The GC SOA <ul><li>Treasury Board-CIOB is actively engaged in developing and distributing an SOA for the Government of Canada </li></ul><ul><li>It provides guidance and a foundational reference framework for a common approach to application interoperability </li></ul><ul><li>Identifies 3 layers (tiers) </li></ul><ul><ul><li>Technology Component Layer </li></ul></ul><ul><ul><ul><li>“ Understanding, classifying and purposing all GC IT Architectures” </li></ul></ul></ul><ul><ul><li>Service Exchange Architecture </li></ul></ul><ul><ul><ul><li>“ Standardizing the run-time aspects of the GC IT Enterprise” </li></ul></ul></ul><ul><ul><ul><li>Describes Services of Services (“Automated Business Services”) and “Infrastructure Services” </li></ul></ul></ul><ul><ul><li>Business Application Architecture </li></ul></ul><ul><ul><ul><li>“ Standardizing the design-time aspects of the GC IT Enterprise” </li></ul></ul></ul><ul><ul><ul><li>Layered application architecture that allows Business Owners to leverage pre-built services </li></ul></ul></ul>
    12. 12. The GC SOA Source: Government of Canada Service Oriented Architecture Series – Primer ( Business Application Architecture Enterprise Services Interface (ESI) Interaction Layer Persistence Layer Object Layer Process Layer Application Services Bus (ASB) Presentation Layer
    13. 13. SOA Tools
    14. 14. Some Challenges <ul><li>Resistance to change </li></ul><ul><ul><li>Current monopolies on app development are reduced </li></ul></ul><ul><ul><li>Perception that building something once means current teams could start to run out of things to do – teams must find more specialized things </li></ul></ul><ul><li>There are limits to what you can do </li></ul><ul><ul><li>The building block can only take you so far – at some point you may need a Mechano set to build more complex things </li></ul></ul><ul><ul><li>Components are interoperable with each other but not with other kinds of components </li></ul></ul><ul><li>Creeping Complexity </li></ul><ul><ul><li>An individual SOA component may be simple </li></ul></ul><ul><ul><li>Overtime, the enterprise level SOA will become something substantial - requires thought, planning and skill, i.e. architecture and training </li></ul></ul>
    15. 15. Some Challenges <ul><li>Finding the right ‘granularity’ </li></ul><ul><ul><li>Differences in individual mandates and operations means differences in granularity are needed </li></ul></ul><ul><ul><li>Some Services will do very simple things (e.g. Return a single value) </li></ul></ul><ul><ul><li>Some will do very complex things (e.g. Update Local database, initiate an approval process, send to partner, then notify originator) </li></ul></ul><ul><ul><li>Complex services appear more valuable to the business but flexibility is reduced as complexity increases </li></ul></ul><ul><li>There’s no “best” SOA </li></ul><ul><ul><li>Just like with Lego, you need a certain degree of variety and personal choice </li></ul></ul><ul><ul><li>Organizations will build a mix of Services at different levels of granularity </li></ul></ul><ul><ul><ul><li>GoC SOA defines 2 levels: Business Services and Infrastructure Services </li></ul></ul></ul>
    16. 16. Conclusion: Architecture Principles <ul><li>Renovate, don’t rebuild </li></ul><ul><ul><li>You are not re-engineering, you are extending your existing application environment through planning, design and management </li></ul></ul><ul><li>Always keep the critical objectives in mind </li></ul><ul><ul><li>Alignment of systems and business </li></ul></ul><ul><ul><li>Reuse of existing software </li></ul></ul><ul><ul><li>Quick turn-around </li></ul></ul><ul><li>You MUST decouple the System Architecture from the Software Architecture </li></ul><ul><li>Don’t try to map a traditional Client server tiers to SOA tiers </li></ul><ul><li>SOA MUST extend to the ERP </li></ul><ul><ul><li>The ERP is probably the single most significant software investment made by the department </li></ul></ul><ul><ul><li>SOA values comes from re-use and renovation, what’s the point if you aren’t re-using and renovating your biggest piece of technology. </li></ul></ul>
    17. 17. Conclusion: Going Forward <ul><li>Focus on your needs, engage key participants </li></ul><ul><li>Determine Governance, basic standards </li></ul><ul><li>Make sure you have a very good understanding of your current assets </li></ul><ul><li>Set priorities – look for services that are based on new ways to use current technology </li></ul><ul><li>Start defining Services and your SOA metamodel </li></ul><ul><ul><li>Start with types based on GoC SOA as starting point </li></ul></ul><ul><ul><li>Extend them for what you need to do </li></ul></ul>
    18. 18. Conclusion: Service Oriented Architecture <ul><li>What it is </li></ul><ul><ul><li>An SOA is the description of the system elements that enable the supply of something useful which has a public demand </li></ul></ul><ul><ul><li>An approach to quickly leverage existing software resources for new and more complex purposes </li></ul></ul><ul><li>Why you need it </li></ul><ul><ul><li>Applications need to work more closely with other agencies </li></ul></ul><ul><ul><li>Need to integrate program systems more tightly with Corporate Systems </li></ul></ul><ul><ul><li>Need to improve the way applications are built </li></ul></ul><ul><ul><ul><li>Increase flexibility, reduce cost, reduce time to deliver </li></ul></ul></ul>
    19. 19. More information <ul><li>IT/NET - [email_address] </li></ul><ul><li>Treasury Board - CIOB </li></ul><ul><li> </li></ul><ul><li>Enterprise SOA – Service Oriented Architecture Best Practices; </li></ul><ul><ul><li>Dirk Krafzig, Karl Banke and Dirk Slama; Prentice Hall December, 2005 </li></ul></ul><ul><li>Software Engineering Institute: </li></ul>