O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

View Slides

342 visualizações

Publicada em

  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

View Slides

  1. 1. Claus von Riegen Director, Web Services Standards, SAP AG OASIS Symposium May 10 2006, San Francisco How Standards Address Interoperability Needs: An Industry View
  2. 2. Challenges Towards Standardization Guidelines Interoperability Imperative Role of Standards
  3. 3. Challenges Towards Standardization Guidelines Interoperability Imperative Role of Standards
  4. 4. Interoperability Imperative Internet Technology Digital broadcasting (audio/video) (Mobile) communi- cations e.g.. IPTV, VoD, MP3 download e.g. VoIP e.g. Mobile TV Convergence of networks and services require interoperable solutions across domains Technology industries have their individual interoperability requirements
  5. 5. Interoperability Layers <ul><li>Technical Interoperability </li></ul><ul><ul><li>Messages are exchanged securely and reliably from sending to receiving infrastructure </li></ul></ul><ul><ul><li>Receiving infrastructure is responsible for delivering the message payload to application </li></ul></ul><ul><li>Semantic Interoperability </li></ul><ul><ul><li>Application knows the business context to which the payload belongs </li></ul></ul><ul><ul><li>Payload is valid from an application perspective </li></ul></ul><ul><ul><li>Application successfully processes payload </li></ul></ul><ul><li>Organizational Interoperability </li></ul><ul><ul><li>Application notifies appropriate users that are responsible for verification and approval steps and tracks deadlines </li></ul></ul>Application Infrastructure Approve POs Verify invoices Application Infrastructure 1 2 3 1 2 3
  6. 6. Some Definitions 1 <ul><li>Interoperability </li></ul><ul><ul><li>The ability of two or more networks, systems, devices, applications or components to exchange information between them and to use the information so exchanged . </li></ul></ul><ul><li>Standard Interface </li></ul><ul><ul><li>A technical description of certain generic requirements that a technical implementation of that interface must conform to – in order to produce the desired functionality. In the case of information interoperability, today’s generic requirements broadly speaking refer to two categories of information, namely (i) data formats and (ii) protocols . </li></ul></ul><ul><li>Open Standard </li></ul><ul><ul><li>Control : the evolution of the specification should be set in a transparent process open to all interested contributors; </li></ul></ul><ul><ul><li>Completeness : the technical requirements of the solution should be specified completely enough to guarantee full interoperability; </li></ul></ul><ul><ul><li>Compliance : there is a substantial standard-compliant offering promoted by proponents of the standard; </li></ul></ul><ul><ul><li>Cost : fair reasonable and non-discriminatory access is provided to intellectual property unavoidably used in implementation of the standard. </li></ul></ul>1 Taken from the EICTA Interoperability Whitepaper
  7. 7. Challenges Towards Standardization Guidelines Interoperability Imperative Role of Standards
  8. 8. Standardization vs. Technology Development Collaboration Competition Proliferation of Standards Communities De jure standards De facto standards Communication / Coordination Proprietary standards Standards Development Ex-ante Technology Development Ex-post
  9. 9. Actors in Standardization Developers Implementers Users Standards Body Technical contributions (may contain IPR) IPR declaration Specifications Test cases IPR declarations Requirements Product/Services Sales Conformance / Interoperability issues IP licensing Prototypes Products Conformance Claims Implementation feedback Agree on common denominator
  10. 10. Phases in Standardization Requirements Identification Partnering Specification Development Initial Implement./ Testing Incremental Enhancemnt Final / Maint. Preparation Phase Development Phase Implementation Phase Agreed / common design principles for reaching interoperability Need Initiator Core Group Standards Body Need Initiator Core Group Standards Body
  11. 11. Challenges in Standardization Towards Standardization Guidelines Interoperability Imperative Role of Standards
  12. 12. Challenges in Standardization Competition to create standards Large, complex, “all or nothing” standards Misuse of standards as a means to erect barriers to competition and trade Lack of rigor in standards development Lack of test specifications Domain specific terms, concepts, etc. Creating standards which don’t work together Late declaration of IPR Lack of standards clarity or awareness Implementation cost Unclear level of conformance Proprietary extensions that do not observe interoperability requirements Closed policies, processes, development groups Intellectual property encumbrances Challenges obtaining standards credentials Cooperation between communities – Lack of common design rules and content reuse CROSS-TOPICS PREPARATORY DEVELOPMENT IMPLEMENTATION
  13. 13. Challenges in Standardization Towards Standardization Guidelines Interoperability Imperative Role of Standards
  14. 14. Aspects of Standards Development Standards Development Requirements Collection and Scoping Openness Prototyping & Interop Testing Maintenance and Errata Management Awareness IPR Management Common Design Principles Development Efficiency Conformance Extensibility
  15. 15. Openness Competition to create standards Misuse of standards as a means to erect barriers to competition and trade Closed policies, processes, development groups CROSS-TOPICS PREPARATORY DEVELOPMENT IMPLEMENTATION Developers Rec. 1 : Early and clear commitment to openness Standards Body Rec. 2 : Standards bodies should provide fair and reasonable membership terms and conditions
  16. 16. IPR Management Late declaration of IPR Implementation cost Intellectual property encumbrances CROSS-TOPICS PREPARATORY DEVELOPMENT IMPLEMENTATION <ul><li>Standards Body Rec. 3 : Standards bodies should provide clear IPR policies . Regarding IPR essential for the implementation of a (proposed) standard, standards developers need to be obligated in terms of </li></ul><ul><li>Disclosure </li></ul><ul><li>Licensing (either RAND or Royalty Free) </li></ul>
  17. 17. Requirements Collection and Scoping Large, complex, “all or nothing” standards Creating standards which don’t work together CROSS-TOPICS PREPARATORY DEVELOPMENT IMPLEMENTATION Users / Developers / Standards Body Rec. 4 : Standards development efforts should be scoped in a clear and narrow manner. Dependencies and relationships to other standards should clearly be indicated.
  18. 18. Common Design Principles Domain specific terms, concepts, etc. Cooperation between communities – Lack of common design rules and content reuse CROSS-TOPICS PREPARATORY DEVELOPMENT IMPLEMENTATION <ul><li>Developers / Standards Body Rec. 5 : Related standards efforts should adopt common design principles. </li></ul><ul><li>Protocols : (e.g. Web services protocols) need to be modular and extensible so that they can easily be composed with each other </li></ul><ul><li>Data Formats : industry-specific XML vocabularies need to adopt common naming and design rules (such as the concepts described in UN/CEFACT CCTS) in order to more easily identify semantic commonalities and differences </li></ul><ul><li>Rec. 6 : Avoid over-specification. Specifications should observe the scope of the standards development effort and implementation details that don’t support interoperability should be kept out of the standard. </li></ul>
  19. 19. Efficiency Lack of rigor in standards development PREPARATORY DEVELOPMENT IMPLEMENTATION <ul><li>Standards Body Rec. 7 : Standards bodies should provide an efficient development process that ensures a high level of quality for its deliverables. </li></ul><ul><li>Efficiency : Clear rules for issue resolution and decision-making by retaining the ability for minorities to voice their opinion. </li></ul><ul><li>Quality : M echanisms that promote early prototype implementations, interoperability testing, and feedback collection provide a higher probability that a standard becomes mature earlier. </li></ul><ul><li>Evolution : Standards bodies should provide a means to enhance their development processes. </li></ul>CROSS-TOPICS
  20. 20. Prototype Development and Interoperability Testing Lack of test specifications PREPARATORY DEVELOPMENT IMPLEMENTATION Standards Body Rec. 8 : Specify clear conformance requirements and test cases . Rec. 9 : Make prototype implementations and interoperability testing part of the standards development . Without such a commitment, standards may evolve with only limited industry adoption and implementations with lacking interoperability. CROSS-TOPICS
  21. 21. Conformance Unclear level of conformance PREPARATORY DEVELOPMENT IMPLEMENTATION Standards Body Rec. 10 : Choose the One Standard - One Test, Supplier’s Declaration of Conformity ( 1-1SDoC ) approach as the common denominator for conformance statements Standards Implementer Rec. 11 : Provide standards conformance statements by means of supplier self-declarations . CROSS-TOPICS
  22. 22. Maintenance and Feedback/Errata Management Lack of rigor in standards development PREPARATORY DEVELOPMENT IMPLEMENTATION Standards Body Rec. 12 : Provide channels for implementation feedback and processes for issue resolution and errata development , particularly after ratification of a standard CROSS-TOPICS
  23. 23. Extensibility Proprietary extensions that do not observe interoperability requirements PREPARATORY DEVELOPMENT IMPLEMENTATION <ul><li>Standards Body Rec. 13 : Standards should provide extensibility mechanisms . </li></ul><ul><li>A standard needs to clearly differentiate between mandatory and optional features . It is the mandatory features that define the minimal set every implementation needs to implement interoperably. </li></ul><ul><li>A standard should also provide appropriate extensibility mechanisms that implementations can use in order to employ the standard in specific contexts. </li></ul>Implementers Rec. 14 : Extensions need to observe interoperability requirements . Interoperability can suffer if, for example, mandatory features are added. CROSS-TOPICS
  24. 24. Awareness Lack of standards clarity or awareness Challenges obtaining standards credentials PREPARATORY DEVELOPMENT IMPLEMENTATION Standards Body Rec. 15 : A standards body should establish liaisons to other organizations that develop standards upon the standards body relies. Rec. 16 : A standards body should ensure that their deliverables are made easily available and well marketed . CROSS-TOPICS
  25. 25. EICTA Activities regarding Interoperability <ul><li>EICTA </li></ul><ul><ul><li>is the European Industry Association for Information, Communications and Consumer Electronics Technology </li></ul></ul><ul><ul><li>promotes the collective interests of the information and communications technology and consumers electronics sector </li></ul></ul><ul><ul><li>has long advocated interoperability in various contexts </li></ul></ul><ul><li>EICTA Interoperability Task Force set up in September 2003 </li></ul><ul><ul><li>Produced generic “ Interoperability White Paper ” in 2004 </li></ul></ul><ul><ul><ul><li>Need for interoperability </li></ul></ul></ul><ul><ul><ul><li>Open standards as the preferred means to meet this need </li></ul></ul></ul><ul><ul><li>Activities to develop a complementary white paper on standardization started in 2005 </li></ul></ul><ul><ul><ul><li>Goal is to develop a set of guidelines that address challenges identified in standardization </li></ul></ul></ul><ul><ul><ul><li>Focus on experience with standardization activities </li></ul></ul></ul><ul><ul><li>This presentation outlines the scope of the new whitepaper </li></ul></ul><ul><ul><ul><li>Thanks to Jochen Friedrich (IBM) for co-authoring the initial draft guidelines </li></ul></ul></ul>
  26. 26. Q&A
  27. 27. Copyright 2006 SAP AG. All Rights Reserved <ul><li>No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. </li></ul><ul><li>Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. </li></ul><ul><li>Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. </li></ul><ul><li>IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation. </li></ul><ul><li>Oracle is a registered trademark of Oracle Corporation. </li></ul><ul><li>UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. </li></ul><ul><li>Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. </li></ul><ul><li>HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C ® , World Wide Web Consortium, Massachusetts Institute of Technology. </li></ul><ul><li>Java is a registered trademark of Sun Microsystems, Inc. </li></ul><ul><li>JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. </li></ul><ul><li>MaxDB is a trademark of MySQL AB, Sweden. </li></ul><ul><li>SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. </li></ul><ul><li>The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior written permission of SAP AG. </li></ul><ul><li>This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be changed by SAP at any time without notice. </li></ul><ul><li>SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. </li></ul><ul><li>SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence. </li></ul><ul><li>The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages. </li></ul>

×