Open Standards COTS Open Source

674 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
674
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Thursday, May 6, 2010
  • Various Types – De Facto, De Jure, Community For someone defining such a standard, openness is defined by the transparency of the process used to define it (e.g. open committees, drafts, review processes) For someone implementing such a standard, openness is defined by its serving the market appropriately, not favouring competitors, not precluding new development, not costing money, etc. For someone using an implementation of such a standard, openness is defined by their having a choice of implementations, by it being supported for its expected lifetime, etc.
  • Thursday, May 6, 2010
  • “ Commercial software” is usually made available in a form that will run on your computer, but you are not given the original material from which it was created. You cannot freely incorporate proprietary software in your own products, though you may be able to obtain some sort of fee-based license to let you do this. For example, approximately 70% of all websites use the open source Apache web server. When you browse the web, even if you are using a proprietary operating system and browser, you are still employing open source to carry out your tasks. Open source fundamentally means that you can benefit from the work of others and, in turn, others get to benefit and extend your work. In this way, the software development community can make progress by working and innovating in a collaborative way. Because the program is licensed free of charge, there is no warranty for the program, to the extent permitted by applicable law, except when otherwise stated in writing
  • Thursday, May 6, 2010
  • Thursday, May 6, 2010
  • Thursday, May 6, 2010
  • Thursday, May 6, 2010
  • Open Source has value – flexibility, cost effectiveness, etc. We use it.
  • Note – you’re not buying software here – it’s an architecture. Cost of implementing everything as a Service – Business services imply a certain granularity, unlikely for your legacy or transfer solution to be at that granularity – therefore $ Getting to SOA from Legacy – what are the steps; what comes first (the first SOA Service e.g. master client index)>
  • Thursday, May 6, 2010
  • Open Standards COTS Open Source

    1. 1. Compare & Contrast: Open Standards, COTS, Open Source, and the SOA Connection Eamonn Moriarty September 2006
    2. 2. Overview <ul><li>Working Definitions </li></ul><ul><ul><li>Open Standards </li></ul></ul><ul><ul><li>Open Source </li></ul></ul><ul><ul><li>Commercial Software (COTS) </li></ul></ul><ul><ul><li>Service Oriented Architecture (SOA) </li></ul></ul><ul><li>Interactions </li></ul><ul><li>Considerations </li></ul><ul><ul><li>Open Standards </li></ul></ul><ul><ul><li>Open Source </li></ul></ul><ul><ul><li>Commercial Software (COTS) </li></ul></ul><ul><ul><li>Service Oriented Architecture (SOA) </li></ul></ul><ul><li>Example </li></ul>
    3. 3. Open Standards
    4. 4. Open Standards <ul><li>What’s a Standard? </li></ul><ul><ul><li>An agreed-upon set of guidelines for doing something </li></ul></ul><ul><ul><li>Aims to reduce the number of ways of doing something without hurting competition </li></ul></ul><ul><li>What’s an Open Standard? </li></ul><ul><ul><li>Generally accepted to be a publicly available and implementable standard </li></ul></ul><ul><ul><li>In the software world, Open Standards support common agreements that enable communications between programs </li></ul></ul><ul><ul><li>Good examples: HTML, HTTP, XML, SOAP, SQL </li></ul></ul><ul><ul><li>There’s no formal standard for ‘Open Standards’! </li></ul></ul>
    5. 5. Open Source Software
    6. 6. Open Source Software <ul><li>Any software programs whose source code is made available under a copyright license for use or modification by other users or software developers </li></ul><ul><ul><li>Development of Open Source software is usually developed as a public collaboration and is made freely available </li></ul></ul><ul><ul><li>Examples: Eclipse, Apache Web Server, GNU/Apache library software, Linux, MySQL, etc. </li></ul></ul>
    7. 7. Open Source Software <ul><li>Properties of Open Source Software: </li></ul><ul><ul><li>Free Redistribution – no royalty requirement for aggregating in a bigger solution </li></ul></ul><ul><ul><li>Source code must be distributed (or available to be) </li></ul></ul><ul><ul><li>License allows modifications and derived works </li></ul></ul><ul><ul><li>Integrity of original Source Code (patch model) </li></ul></ul><ul><ul><li>No discrimination against persons or groups </li></ul></ul><ul><ul><li>No discrimination against fields of use </li></ul></ul><ul><ul><li>Licensing rights apply to all to whom the program is distributed </li></ul></ul><ul><ul><li>License cannot be specific to a product </li></ul></ul><ul><ul><li>License cannot restrict other software </li></ul></ul><ul><ul><li>License cannot be technology-specific </li></ul></ul>
    8. 8. COTS Software
    9. 9. COTS Software <ul><li>Commercial off-the-shelf (COTS) describes ready-made, commercially available software products </li></ul><ul><ul><li>Vendor software packages which are provided at established catalog or market prices and sold or leased to the general public </li></ul></ul><ul><li>Typical properties of COTS software: </li></ul><ul><ul><li>Rich business functionality for a particular market or set of markets </li></ul></ul><ul><ul><li>Support Programs </li></ul></ul><ul><ul><li>Education Programs </li></ul></ul><ul><ul><li>Version Protection </li></ul></ul><ul><ul><li>Documentation </li></ul></ul><ul><ul><li>Ongoing R&D </li></ul></ul><ul><ul><li>Scalability </li></ul></ul><ul><ul><li>Supports multiple platforms </li></ul></ul>
    10. 10. Service Oriented Architecture
    11. 11. Service Oriented Architecture <ul><li>Services are stateless software components which have a defined interface but are implementation-independent. </li></ul><ul><ul><li>Service Providers publish interfaces to these Services. </li></ul></ul><ul><ul><li>Service Consumers use these interfaces to invoke the Services. </li></ul></ul><ul><ul><li>Consumers neither know nor need to know about the location or implementation details of a Service. </li></ul></ul><ul><li>A software architecture which models the interactions between providers and consumers of Services . </li></ul><ul><li>Service interfaces encode generic semantics only; they contain no implementation-specific meaning . </li></ul>
    12. 12. Service Oriented Architecture <ul><li>Interesting things to note about SOA </li></ul><ul><ul><li>SOA has not really been an official standard (RM just released by OASIS) </li></ul></ul><ul><ul><li>SOA does not mandate any specific technology, but Web Services were in the right place at the right time </li></ul></ul><ul><ul><li>Web Services is a continually evolving technology </li></ul></ul><ul><ul><ul><li>SOAP and XML are standards </li></ul></ul></ul><ul><ul><ul><li>Lots of other Web Service work ongoing, which aren’t yet </li></ul></ul></ul>
    13. 13. Interrelations
    14. 14. How do they all Interrelate? <ul><li>Open Standards: </li></ul><ul><ul><li>May or may not be used in Open Source Software </li></ul></ul><ul><ul><li>May or may not be used in COTS Software </li></ul></ul><ul><ul><li>Are fundamental to SOA implementations (XML, SOAP) </li></ul></ul><ul><li>Open Source </li></ul><ul><ul><li>May or may not use Open Standards </li></ul></ul><ul><ul><li>May be included or used in COTS implementations </li></ul></ul><ul><ul><li>May or may not be used in SOA implementations </li></ul></ul><ul><li>COTS </li></ul><ul><ul><li>May use Open Standards </li></ul></ul><ul><ul><li>May use Open Source software </li></ul></ul><ul><ul><li>May be based on or support SOA </li></ul></ul><ul><li>SOA </li></ul><ul><ul><li>Implementations generally based on Open Standards </li></ul></ul><ul><ul><li>May or may not use or be implemented by Open Source or COTS </li></ul></ul>
    15. 15. Considerations
    16. 16. Open Standards Considerations <ul><li>When considering Open Standards, need to ask some questions: </li></ul><ul><ul><li>How is that standard created (by committee, by one vendor?) </li></ul></ul><ul><ul><li>How is it maintained after Version 1.0? Who maintains it? </li></ul></ul><ul><ul><li>Is there a cost associated with getting or implementing the standard? </li></ul></ul><ul><ul><li>Are there restrictions on how the standard may be implemented? </li></ul></ul><ul><ul><li>Can just a part of the standard be used or extended and still claim compliance? </li></ul></ul><ul><ul><li>Fundamentally, is it a good standard? Have implementers embraced it? Will it be useful? </li></ul></ul><ul><li>In general Open Standards promote ease of use and reuse, promote simplification of implementation, promote communication and integration, and reduce vendor lock-in for implementers </li></ul>
    17. 17. Open Source Considerations <ul><li>When considering Open Source products, also need to ask some questions: </li></ul><ul><ul><li>What functionality does it provide? </li></ul></ul><ul><ul><li>How much does it cost (free as in speech, not free as in beer)? </li></ul></ul><ul><ul><li>How does Training work? </li></ul></ul><ul><ul><li>How does Support work? </li></ul></ul><ul><ul><ul><li>Developer Community only? </li></ul></ul></ul><ul><ul><ul><ul><li>Response times </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Number in the Community </li></ul></ul></ul></ul><ul><ul><ul><li>Supported via a third party? </li></ul></ul></ul><ul><ul><li>What documentation is available? </li></ul></ul><ul><ul><li>What Open Source License covers it? </li></ul></ul><ul><ul><li>How much buy-in is there? </li></ul></ul><ul><ul><ul><li>Determines the community </li></ul></ul></ul><ul><ul><ul><li>Will affect the possibility of new functionality </li></ul></ul></ul><ul><li>Open Source has value; however, important to be aware of the business model that supports it </li></ul>
    18. 18. COTS Considerations <ul><li>When considering COTS products, there are some further questions: </li></ul><ul><ul><li>Need to evaluate what functionality is needed and being provided (now and in the future) </li></ul></ul><ul><ul><li>Need to consider whether a given COTS product is based on Open Standards </li></ul></ul><ul><ul><li>Need to consider whether a given COTS product is based on or provides support for SOA </li></ul></ul><ul><ul><li>Need to consider whether a given COTS product is ‘closed’ </li></ul></ul><ul><ul><ul><li>Do you get the source code (do you need it)? </li></ul></ul></ul><ul><ul><ul><li>Can you modify core functionality? </li></ul></ul></ul><ul><ul><ul><li>How will new versions work? </li></ul></ul></ul><ul><li>COTS products can provide rich business functionality together with the means to implement, support and maintain them </li></ul>
    19. 19. SOA Considerations <ul><li>Finally, there are also some pertinent questions to ask when considering implementing an SOA : </li></ul><ul><ul><li>What will the Services be? </li></ul></ul><ul><ul><ul><li>How many, and of what granularity? </li></ul></ul></ul><ul><ul><ul><li>What’s the cost of implementing everything as a Service? </li></ul></ul></ul><ul><ul><ul><li>Is there a COTS or Open Source solution that can help? </li></ul></ul></ul><ul><ul><li>What is the transition plan? </li></ul></ul><ul><ul><li>How will the system perform? Will the system perform? </li></ul></ul><ul><ul><li>How will the system deal with advances in Web Services (e.g. Security, Transactions)? </li></ul></ul><ul><li>SOA has momentum in the industry, and offers many potential benefits (Interoperability, Scalability, Reuse, Agility) </li></ul>
    20. 20. One Example Open Standard Open Standard Open Source Open Source Open Source SOA SOA Open Standard COTS
    21. 21. Thank you

    ×