Lightweight SOA Stefan Tilkov / innoQ / [email protected]
1 9 Claims
2 Claim #1/9: Application architecture is irrelevant for your SOA
3 Application Architecture
vs.
Integration Architecture
4 5 6 7 8 9 10 11 12 13 Application Architecture (Example)
Presentation JSP
Interaction Layer Struts
Process Layer Stateful & Stateless Session Beans
Business Logic Layer Wrapper Stateless Session Beans Session Beans
Resource Layer POJOs & Hibernate JCA JDBC
RDBMS Legacy Systems
14 Application Classes
ClassKlasse A A ClassKlasse B B ClassKlasse C C
Presentation Presentation & Interaction Presentation & Interaction JSP Eclipse RCP Eclipse RCP Interaction Layer Struts
Process Layer Process Layer Process Layer Stateful & Stateless Session Beans Stateful & Stateless Session Beans Stateful & Stateless Session Beans
Business Logic Layer Wrapper Business Logic Layer Wrapper Business Logic Layer Stateless Session Beans Session Beans Stateless Session Beans Session Beans Stateless Session Beans
Resource Layer Resource Layer Wrapper POJOs & Hibernate POJOs & Hibernate Session Beans
Legacy Legacy RDBMS RDBMS Systems Systems GIS Backend
15 Focus: Portability
Presentation JSP
Interaction Layer Struts
Process Layer Stateful & Stateless Session Beans
Business Logic Layer Wrapper Stateless Session Beans Session Beans
Resource Layer POJOs & Hibernate JCA JDBC
RDBMS Legacy Systems
16 Focus: Interoperability
Presentation Presentation & Interaction Presentation & Interaction JSP Eclipse RCP Eclipse RCP Interaction Layer Struts
Process Layer Process Layer Process Layer Stateful & Stateless Session Beans Stateful & Stateless Session Beans Stateful & Stateless Session Beans
Business Logic Layer Wrapper Business Logic Layer Wrapper Business Logic Layer Stateless Session Beans Session Beans Stateless Session Beans Session Beans Stateless Session Beans
Resource Layer Resource Layer Wrapper POJOs & Hibernate POJOs & Hibernate Session Beans
Legacy Legacy RDBMS RDBMS Systems Systems GIS Backend
17 Claim #2/9: An ESB should not be at the core of your SOA
18 ESB Spaghetti Monster
19 THE FLYING SPAGHETTI MONSTER
TOUCHED BY HIS NOODLY APPENDAGE
20 ESB Spaghetti
Shamelessly stolen from Jim Webber: http://tinyurl.com/ywm5sj
21 EOA
22 ESB-oriented Architecture Proprietary tooling (“doodleware”) No (or little) team development No unit-testing, test-driven development No (or little) modularization No (or little) versioning Barrier to entry Prolonged existence of proprietary interfaces
23 “Virtual” ESB
24 Claim #3/9: Point-to-point communication is perfectly fine
25 Mainstream + Lightweight
Pick a decent platform or toolkit for SOAP/WS-* support .NET WCF, Spring Web Services, Apache CXF, Apache Axis2, JBossWS, Sun Metro Standardize on standards, not products, not single points of failure
26 If you Use an ESB …
Central Model
Enabling Model
… know what you’re doing
27 Consider Open Source ESBs
Apache Synapse/WSO2 ESB Mule ESB ServiceMix Sopera
28 Claim #4/9: Participants in a given SOA must depend on wire formats only
29 “Virtual” ESB
30 “Virtual” ESB
31 Claim #5/9: Web services (SOAP/ WSDL) are not the only way
32 REST Explained in 5 Easy Steps
33 1. Give Every “Thing” an ID
http://example.com/customers/1234 http://example.com/orders/2007/10/776654 http://example.com/products/4554 http://example.com/processes/sal-increase-234
34 2. Link Things To Each Other
35 3. Use Standard Methods
GET Retrieve information, possibly cached
PUT Update or create with known ID
POST Create or append sub-resource
DELETE (Logically) remove
36 4. Offer Multiple Formats
GET /customers/1234 Host: example.com Accept: application/vnd.mycompany.customer+xml
GET /customers/1234 Host: example.com Accept: text/x-vcard begin:vcard ... end:vcard
37 5. Communicate Statelessly
GET /customers/1234 Host: example.com Accept: application/vnd.mycompany.customer
shutdown update software replace hardware startup GET /customers/1234/orders/46 Host: example.com Accept: application/vnd.mycompany.order+xml
38 What’s cool about REST?
39 generic interface Resource { Resource(URI u) Any HTTP client Response get() (Firefox, IE, curl, wget) Response post(Request r) Response put(Request r) Any HTTP server Response delete() } Caches Proxies Google, Yahoo!, MSN class CustomerCollection : Resource { Anything that knows ... your app Response post(Request r) { id = createCustomer(r) return new Response(201, r) } ... } specific
40 41 Mapping Examples getFreeTimeSlots(Person) →GET /people/{id}/timeslots?state=free rejectApplication(Application) →POST /rejections↵
42 Atom & AtomPub
43 Atom Syndication Format
Standardized in: RFC 4287 MIME Type: application/atom+xml Namespace: http://www.w3.org/2005/Atom
RSS Done Right
44 Atom Model
Feed 0 Entry id * id * Category title title updated updated
Content
Resource OutOfLine InlineText InlineXHTML InlineOther
45
Very fine text.
46 generic Anything that interface Resource { understands HTTP ... }
class AtomFeed : Resource { Any feed reader AtomFeed get() ... } Yahoo! Pipes class CustomerCollection : AtomFeed { Anything that knows ... your app }
specific
47 Atom Publishing Protocol
Standardized in: RFC 5023 Namespace: http://www.w3.org/2007/app
RESTful Collections Handling: - Discovery, Description, - Retrieval, - Creation, Editing, Deletion of Resources
48 Collection 0 Member id * id title title updated updated * *
Category Workspace
* Entry Link
Service Document
Resource
49 generic Anything that interface Resource { understands HTTP ... }
class AtomFeed : Resource { Any feed reader AtomFeed get() post(Entry) Any AtomPub client ... } Yahoo! Pipes class CustomerCollection : AtomFeed { Anything that knows ... your app }
specific
50 Claim #6: RESTful HTTP moves you closer to SOA goals than WS-*
51 SOA and RESTful HTTP
Loose Coupling Low Resistance to Change Unexpected Re-use Interoperability Vendor Independence Available Skills Tooling for any Language & Platform
… all served better by RESTful HTTP than WS-*
52 Claim #7: Advanced WS-* standards are overrated
53 WS-* Theory & Practice
WS-Addressing and WS-ReliableMessaging are not yet widely interoperable Message-bases security is way too expensive UDDI is a solution looking for a problem Even WS-based SOAs often don’t use them
54 REST + WS-*
If you choose SOAP, WSDL, WS-*, go with lightweight/OSS tools Consider adopting RESTful HTTP instead of WS-* Adopt REST for SOA Governance (!) Consider WS-* + HTTP GET
55 Claim #8: Governance can be greatly simplified
56 Inquiry UDDI Publication find_binding save_binding find_business save_business save_service find_relatedBusinesses save_tModel find_service delete_binding find_tModel delete_business get_bindingDetail delete_publisherAssertions get_businessDetail delete_service get_operationalInfo delete_tModel get_serviceDetail add_publisherAssertions get_tModelDetail set_publisherAssertions get_assertionStatusReport get_publisherAssertions get_registeredInfo
420-page specification Finding and maintaining (meta-)model objects
57 UDDI (contd.)
UDDI could be greatly simplified by using plain HTTP It would no longer be protocol- independent - but who cares? Atom (Syndication Format & Protocol) are a great match Approach taken in Mule Galaxy, WSO2 Registry, HP Systinet 2
See: http://www.xml.com/pub/a/ws/2002/02/06/rest.html?page=2
58 Lightweight Governance
Simple solution (Webserver, WebDAV, AtomStore) for Document Storage Atom feeds for update notifications HTTP GET for lookups
59 (Final) Claim #9: The most important architectural guide is your intelligence
60 homogeneity vs. right tool for the job
integrated solutions vs. no dependency on single vendors
central control vs. no single point of failure
mainstream vs. technical optimum
61 CSOA
Common Sense Oriented Architecture
62 Q&A
[email protected] http://www.innoq.com/blog/st/
63 What about BPM?
64 BPM Vendor SOA Marketing
Valid Options: 1. SOA 2. BPM 3. SOA + BPM
65 Orchestration Options
Central Model
BPM as Impl Model
66