Notes on Interface


Published on

Published in: Technology, Business
  • 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
  • A musical keyboard provides an interesting example of a standard interface. When I press a particular sequence of keys, I expect an instrument to respond with a particular sequence of notes. Many different instruments provide the same interface: pianos, harpsichords, organs and synthesizers. Some music software has a virtual implementation of the same interface: it provides a visual display of the same pattern of keys, but these keys are pressed with mouse clicks rather than directly with the fingers. But there are also important differences between the various implementations of this interface. Some instruments are powered by electricity. This means that a complete specification of the interface includes the precondition <instrument is switched on>. On a piano, the keys also control the volume and duration of the note. On an organ, the keys control the duration of the note but the volume is controlled elsewhere. On a harpsichord or a toy piano, you get the same short note however long you hold down the key. On some toy pianos, you only get one note at a time however many keys you press. Thus the piano interface satisfies one specification that is common to other keyboard instruments, but it also satisfies another specification that is unique to pianos. This simple example demonstrates that there is an important difference between the interface and the specification of the interface.
  • Notes on Interface

    1. 1. Architecture and Interfaces<br />Richard Veryard<br />September 2011<br />with thanks to Lawrence Wilkes of CBDI<br />
    2. 2. Motivation<br />The architectural properties of a system of systems depends critically on how the systems are wired together.<br />Architects have a critical role in designing robust, flexible and efficient boundaries and interfaces and working space between sociotechnical systems and organizations.<br />Architects should help to eliminate negative and unproductive space between systems.<br />On the other hand, architects should help to realise positive space between automated systems – space in which people and organizations can engage positively with business and social requirements.<br />
    3. 3. What is an interface?<br />Affordance<br />Ability to play same tune using multiple instruments.<br />Extensions<br />Electrical instruments have an additional precondition (switched on)<br />Exceptions<br />Cheap instruments have limited response (one note at a time).<br />Example: Keyboard<br />An abstract structure enabling many different musicians to communicate with many different instruments.<br />The output from the musician’s fingers becomes the input to the instrument.<br />
    4. 4. Decoupling applications and technology through services<br />Lawrence Wilkes & Richard Veryard<br />Microsoft Architecture Journal, April 2004<br />
    5. 5. Decoupling applications and technology with interfaces<br />
    6. 6. SERVICE CONSUMERS<br /><ul><li>Frequent change
    7. 7. Device diversity</li></ul>Multiple Devices<br />Workflow<br />ENTERPRISE SERVICE BUS<br /><ul><li>Transformation
    8. 8. Manage the integration process.
    9. 9. Assembly of consolidated components and aggregated services
    10. 10. Management feedback
    11. 11. Security and accesscontrol</li></ul>Business Service Bus<br />Service Management<br />Process Orchestration<br />Adaptors and Transformation<br />Directory<br />Technical Service Bus – Messaging, J2EE, CORBA, Etc<br />SERVICE IMPLEMENTATIONS<br /><ul><li>Less frequent change
    12. 12. Server diversity
    13. 13. Interface diversity</li></ul>Legacy<br />Apps<br />Packaged Apps<br />New Components<br />3rd Party Services<br />Enterprise Service Bus or Business Service Server<br />Source: CBDI Forum<br />
    14. 14. SOUP<br />SOAPY SOUP<br />SOUPY SOAP<br />SOAP<br />Legacy systems <br />Legacy systems with some service interfaces <br />Service-based architecture with some outstanding legacy areas. <br />Fully compliant service-based architecture. <br />Progressive Decoupling of Legacy Systems<br />Source: CBDI Forum<br />
    15. 15. SOA-based integration<br />8<br />Source: Hewlett Packard<br />
    16. 16. Screen Scraper<br />Intended use of legacy …<br />… but intercepted<br />Customer Details<br />Customer Details<br />API<br />Legacy Software<br />Legacy Software<br />
    17. 17. ETL = Extract, Transform and Load<br />Legacy Conversion<br />Data Warehousing<br />OLD<br />OLTP<br />extract<br />extract<br />Meta<br />Data<br />ETL<br />ETL<br />transform<br />transform<br />NEW<br />DW<br />load<br />load<br />
    18. 18. Technology1<br />OrganizationA<br />Service<br />Technology2<br />Service<br />Organizational Boundary<br />Technology Boundary<br />OrganizationC<br />OrganizationB<br />Service<br />Application Boundary<br />ApplicationI<br />ApplicationII<br />Service = Points of Flexibility<br />Source: CBDI Forum<br />
    19. 19. Articulation Points identify the best places to insert an interface<br />Lawrence Wilkes & Richard Veryard<br />Microsoft Architecture Journal, April 2004<br />
    20. 20. Balancing Service Provider and Consumer Needs<br />
    21. 21. What is a good interface?<br />For Service Consumer<br />Weaker Preconditions<br />Stronger Postconditions<br />More Generalized Model<br />For Service Provider<br />Stronger Preconditions?<br />Weaker Postconditions?<br />For Higher Reuse<br />
    22. 22. Generalization<br />Weaker Data Model<br />Broad inclusive types<br />Broad time horizon<br />Weakly constrained relationships<br />optional<br />many<br />transferable<br />Stronger Data Model<br />Narrow exclusive types<br />Narrow time horizon<br />Strongly constrained relationships<br />mandatory<br />one<br />fixed<br />
    23. 23. Ecological View of Components and Services<br />
    24. 24. Seven Ecological Design Principles<br />17<br />
    25. 25. References<br />Joshua Bloch, How to design a good API and why it matters (December 2005)<br />AsifHussain, Building E-Business Suite Interfaces using BPEL (Innowave Technology)<br />James Taylor, Managing Integration with eBusiness Suite using Oracle BPEL (Hewlett Packard)<br />Richard Veryard, Component-Based Business: Plug and Play (Springer 2001)<br />Richard Veryard, Component-Based Service Engineering (CBDI Journal, November 2003)<br />Lawrence Wilkes, SOA – Save Our Assets (CBDI Journal, November 2003)<br />Lawrence Wilkes & Richard Veryard , Service-Oriented Architecture: Considerations for Agile Systems (Microsoft Architecture Journal 2, April 2004)<br />
    26. 26. If you were intrigued by this presentation …<br />… read my architecture blog<br /><br />… and follow me on Twitter<br /><br />… and follow Lawrence on Twitter for good measure<br /><br />