Radovan Janecek R E S Tor S O A Pv1
0 likes231 views
This document is a presentation from 2008 given by Radovan Janecek on the topics of REST vs SOAP and related considerations for service architecture styles. Some key points made in the presentation include: REST and SOAP will likely coexist for a long time, with practical reasons sometimes existing to use SOAP; however, the direction of architecture styles should steer toward REST due to advantages like wider standards adoption, simpler architecture, and better reusability of services. The presentation also cautions against common mistakes made in SOAP implementations that fail to deliver on loose coupling.
Radovan Janecek R E S Tor S O A Pv1
- 1. This Presentation Courtesy of the International SOA Symposium October 7-8, 2008 Amsterdam Arena www.soasymposium.com info@soasymposium.com Founding Sponsors Platinum Sponsors Gold Sponsors Silver Sponsors REST or SOAP? Radovan Janecek Chief Architect, BTO, HP Software October 2008 © 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice 1 October 2003 Copyright © 2006 HP corporate presentation. All rights reserved.
- 2. Eight Years of SOA Wins and Mistakes • Co-founded Systinet (2000) − Web Services stacks in C++ and Java − Service Registry − SOA Governance • Led SOA Center in Mercury/HP (2006) − SOA Governance, Quality, Management • BTO Architecture (2008) − Service and Data Models − Integration strategy (SOA based) To Remember • SOA is GOOD as it SIMPLIFIES big initiatives − Business Service Management − Business Service Automation − Service Portfolio Management • SOA encompasses both REST and WS-* − http://www.google.com/search is a service! • REST vs WS-* is not black&white decision 4 21 October 2008 2 October 2003 Copyright © 2006 HP corporate presentation. All rights reserved.
- 3. REST vs. SOAP? • REST is architecture style while SOAP is data envelope • REST vs. WSDL or WSA is more accurate view • HTTP vs. WSDL or WSA is more practical view • Uniform interface vs arbitrary interface • Every THING has URI vs operation parameters • So: the title of my presentation is nonsense! 5 21 October 2008 Let’s be Even More Practical! • RSS, Atom, APP, JSON, HTTP, OpenSearch, … • … vs SOAP, WS-Addressing, WS-ReliableMessaging, … • Email clients, browsers, feed readers, syndicators, mashups, commandline tools, Office tools, GUI widgets, SaaS !!!ALL OUT OF BOX!!! 6 21 October 2008 3 October 2003 Copyright © 2006 HP corporate presentation. All rights reserved.
- 4. Key Considerations Requirements Scalability Enterprise readiness # of different integrated systems Integration use cases # of users User-facing use cases # of changes (future evolution, flexibility) Amount of data Organization Legacy Lack of time Existing APIs Lack of budget Openness of existing systems Skills and experience Reusability Governance processes maturity 7 21 October 2008 Let’s look into the details CONSIDERATIONS 8 21 October 2008 4 October 2003 Copyright © 2006 HP corporate presentation. All rights reserved.
- 5. Skillset • EAI mindset and experience is usually strong − CORBA − J2EE (EJBs) • API oriented design is what we master • Reinventing architectures − My architecture is bigger than yours! • WSA leads to faster results (from service POV) • RESTful services are more difficult to build 9 21 October 2008 Use Cases • User facing use cases prevail • M2M use cases usually simple − Data transfer − Simple orchestration − SUPPORT user facing use cases anyway • Pull model, data services, feeds well proven in M2M on the web • REST wins: wider adoption, few difficult use cases 10 21 October 2008 5 October 2003 Copyright © 2006 HP corporate presentation. All rights reserved.
- 6. Enterprise Readiness • Security,Failover, Reliability, Monitoring & Management • Orchestration, ‘business processes’ YOU NEED A MIDDLEWARE TO DO THIS! 11 21 October 2008 NO 12 21 October 2008 6 October 2003 Copyright © 2006 HP corporate presentation. All rights reserved.
- 7. Good Service is Enterprise Ready! • It secures itself • It provides idempotent operations and ways to compensate • It offers management interfaces • Hide middleware behind your façade if you think you can’t live without it • REST wins: it teaches you how to do better without middleware 13 21 October 2008 Four Ways for One Use Case Event Source Incident Manager lookup ? create update submit lookup BPEL ? create update PUT GET ? 14 21 October 2008 7 October 2003 Copyright © 2006 HP corporate presentation. All rights reserved.
- 8. Enterprise Readiness Summary • It is non-consideration • Both WS-* and REST services are enterprise ready • Both can be implemented in very bad way • This is rather relevant to Maturity and skill set assessment 15 21 October 2008 Reusability • Why to use SOAP for list of PurchaseOrders for M2M and Atom/JSON feed for the same on GUI level? • Why to use collect data via SOAP if Atom offers better metadata and is far more adopted? − And instead of BPEL you can use mashup? • REST wins: reusability is about standards and their real adoption in variety of different use cases 16 21 October 2008 8 October 2003 Copyright © 2006 HP corporate presentation. All rights reserved.
- 9. Exposing Legacy • Closed legacy systems might require EAI layer • EAI vendors support SOAP better • Open systems usually expose non-uniform API − Direct path to WSDL − Much easier to use WSA than REST − Beware of the API granularity issue! • WSA can often be better (cheaper) choice here • My suggestion: hide WSA by REST in different tier 17 21 October 2008 Legacy Exposure Visual SOAP REST “Impedance mismatch” API SOAP Objects vs RDBMS Middleware relevant REST 18 21 October 2008 9 October 2003 Copyright © 2006 HP corporate presentation. All rights reserved.
- 10. Scalability: # of Changes and Evolution How many different APIs? How many changes into client code? • http://www.google.com/search?q=20/5 Impact on existing clients? • http://www.google.com/search?q=ba856 • http://www.google.com/search?q=5m+in+inches • http://www.google.com/search?q=weather+San+Francisco 19 21 October 2008 REST wins Scalability: # of Systems • Data syndication − Warehouse vs mashups • GUI mashups − WS-Portlets vs JSON and widgets • Complex orchestration − Process vs pub/sub − Often academic issue • You cannot practically scale with WSA 20 21 October 2008 10 October 2003 Copyright © 2006 HP corporate presentation. All rights reserved.
- 11. WSA vs REST Summary • Service development cost: WSA design is simpler • Development skills: WSA more „traditional‟ • Clarity and learning materials: REST is the best documented • Scalability: Caches, constraints • Simplicity of architecture: Constraints: you can assume • Reusability of services: Learn by example, standards • Standards adoption: No discussion • Exposing legacy: • Middleware: YAGNI 21 21 October 2008 Revised Summary • It’s not RED or GREEN decision • Both REST and WSA will co-exist for a long time • Many practical reasons for WSA might exist − Existing API, Skills, investments • Steer the direction towards to REST 22 21 October 2008 11 October 2003 Copyright © 2006 HP corporate presentation. All rights reserved.
- 12. On WSA: Avoid Mistakes • WSA implementations often do not deliver on loose coupling promise − Direct legacy API exposure to SOA is very risky • Fine grained vs coarse grained − WSDL-based code generation is bad practice • Fragile from evolution perspective • Forward compatibility is a big issue − Strong typing is tightly coupled • XML Schema validation is BAD! • Short-term advantage versus future pain 23 21 October 2008 Q&A THANK YOU 24 21 October 2008 12 October 2003 Copyright © 2006 HP corporate presentation. All rights reserved.