SOA Tailoring

1. SOA Tailoring jakob@rojel.dk

2. What gives you the right to talk

3. Agenda • The SOA scene • ESB / MS Platform • Agile SOA • Product SOA

4. Agenda • The SOA scene • ESB / MS Platform • Agile SOA • Product SOA

5. The SOA Scene • Most people are doing SOA • Some people knows what it really is about • Few people really knows why they are doing SOA • The scope and definition of SOA keeps expanding • SOA actually now delivers in some areas

6. The EA Mafia • Focus on Enterprise Architecture • No real SOA without an Enterprise Service Bus • Extra cost justified by reuse • Business agility comes later • Sounds a little like mainframe and waterfall development method Read this

7. Remeber the SOA promise • Business agility • Reusable services in the cloud • The good news is that this is delivered outside the Enterprise • Mashup • Google, Facebook, Flickr, Amazon, eBay, Microsoft

8. Agenda • The SOA scene • ESB / MS Platform • Agile SOA • Product SOA

9. ESB and the Microsoft stack • There has been a lot of arguing whether Microsoft has an Enterprise Service Bus • It is possible to develop SOA solutions without an ESB ? • Will a shrink-wrapped ESB product help your organization ? • Is ESB just old hat ?

10. ESB overview

11. Defining ESB • Defining ‘ESB’ • Many variations, products and technologies • Commonality and convergence • Distributed, ubiquitous ‘fabric’ for message exchange and integration • Central administration and deployment • Standards-based and secure messaging • Centralized logging • Lightweight containers • Message exchange patterns & routing • Adaptation and mediation • Persistence and recoverability • Orchestration and choreography

12. The Microsoft SOA platform today • BizTalk Server 2006 R2 • Message brokerage (pub/sub, message stream processing) • Integration toolset (adapters, transformation, EDI support, etc.) • Orchestration • Business activity monitoring • Business rules, Single Sign-on, B2B support, development tooling etc. • Windows Communication Foundation (WCF) • Service model – loosely-coupled composition • Asynchronous messaging primitives • MEP (message exchange patterns) and extensible behavioural support • Channel architecture - transports and encodings • Windows Workflow Foundation (WF) • Activity model – tightly-coupled composition • Workflow models – sequential, state transition • Base activity library • Extensible architecture • Rules

13. Who are you kidding? • “Service Buses? Microsoft doesn’t get it!” • …but Microsoft says: • “The Service Bus is a set of design patterns” • “The Service Bus is about the platform, not the product” • “ESB is a subset of the service bus approach. Other subsets exist” • “BizTalk Server is a mere hub & spoke message broker” • BizTalk Server is pre-ESB, but firmly rooted in the same concepts • “WCF is interesting, but not ESB” • That’s the point! It’s a foundation for building service buses. • ‘Oslo’ will build on WCF • extending the service bus concept across applications, enterprises and ‘cloud’ computing

14. BizTalk Server  Service Bus  • Robust, recoverable message exchange . • Message Exchange Patterns (MEPs) • 1-way, 2 way, reliable, ordered, etc • No first-class support for duplex, but possible through custom adapters • Powerful pub/sub mechanism • Process Automation • Orchestration engine • Distribution and Scalability • Hosting model across multiple servers (Enterprise edition only) • Load-sharing • Single-point administration (Enterprise edition only) • Central ‘resource’ repository to aid deployment • Adapter framework • OOB adapters, third-party adapters and custom adapters

15. BizTalk Server  Service Bus  • Centralised model • ‘Heavyweight’ model • All messages persisted to Message Box • No lightweight, non-persisted, non-recoverable model • Low latency and real-time challenges • Supports built-in service types only • Orchestrations, Receive and Send ports • Must use adaptation for other services • Leads to over-use of orchestration • No built-in support for common ESB design patterns • Addressed via the ESB Guidance Toolkit

16. WCF  Service Bus  • Part of .NET Framework • Freely distributable – no licensing costs • Provides lightweight container model • Service and channel model • Hosting model • Wide range of MEPs, including duplex • Extensive support for SOAP and WS-* • New support for Web 2.0 and REST • WCF LoB Adapter Framework • Platform-level adapters • Exposed as WCF bindings

17. WCF  Service Bus  • Foundational only • Administration, management and deployment • Does not provide OOB enterprise-level tooling • No pre-built support for pub/sub • May be addressed in ‘Oslo’NB. early previews of ISB contain pub/sub model • Can be implemented today using custom code • No pre-built persistence features • May be addressed in ‘Oslo’ • No pre-built support for many common ESB design patterns • May be addressed in ‘Oslo’ • Some support today via ESB Guidance Toolkit • Limited support for orchestration and choreography • Can use WF with WCF

18. ESB Guidance Toolkit • Patterns and Practices • Guidance & best practice • Documented design patterns • Production-ready code (open source) • Targets BizTalk Server R2 and WCF • Not ‘Oslo’! • Use as a ‘starter’ pack • Extend or create components • Adapt code • Add to functionality

19. ESB patterns examples Point to point Request response resolution

20. General ESB proswikipedia • Faster and cheaper accommodation of existing systems. • Increased flexibility; easier to change as requirements change. • Standards-based. • Scales from point solutions to enterprise-wide deployment (distributed bus). • Predefined ready-for-use service types. • More configuration rather than integration coding. • No central rules engine, no central broker. • Incremental changes can be applied with zero down-time; enterprise becomes "refactorable

21. General ESB conswikipedia • Enterprise Message Model is usually required, resulting in additional management overhead. May not be a simple task to achieve many disparate systems collaborating on message standards. • Requires ongoing management of message versions to ensure the intended benefit of loose coupling. Incorrect, insufficient, or incomplete management of message versions can result in tight coupling instead of the intended loose coupling. • It normally requires more hardware than simple point to point messaging. • New skills needed to configure, manage, and operate an ESB. • Extra overhead and increased latency caused by messages traversing the extra ESB layer, especially as compared to point to point communications. • Some critics remark that ESB require a significant effort to implement, but produces no value unless SOA services are subsequently created for the ESB.[

22. ESB Recommendations • Very few will benefit from implementing a ESB product • Understand the ESB concepts and patterns • Use a pragmatic mix of WCF, WF and Biztalk in that priority • Keep it simple • If it is Endpoint resolution, transformation and logging your are looking for ESB is way over engineered • Prepare for Internet Service Bus / Federated Service Bus

23. Agenda • The SOA scene • ESB / MS Platform • Agile SOA • Product SOA

24. ”Net generation” trends • Services outside the enterprise • Lot faster time to marked … always in beta • Spoiled employees does not follow corporate policy or long term benefits • Provide them with the tools they need or they will go elsewhere • Architecture decisions needs to accommodate soft values

25. Employees go elsewhere

26. But this stuff is just for fun isn’t it? • What relevance does this have outside of staff morale, corporate communications, professional networking, knowledge sharing, reducing time wasted in meetings and retention of intellectual property?

27. Gatwick Cabin Crew Swaps

28. Agile development is king • Scrum has been adopted as a very successful development method • Empowered teams • 2-4 weeks iterations • Feature and test driven development • Agile does not believe in reuse economic • Dynamic languages looks like the next big wave • Ruby (on Rails) • Phyton • Groovy

29. Agile meets SOA • Traditional contract first web services are expensive • To build • To update • It helps if using a framework like WS SW Factory • Applications and services are easily intertwined but need to be kept aside

30. Not all services are alike • Be careful with service categorization • External WS • Cast in stone WS (e.g. Host integration server to Mainframe) • Application private WS • Lookup WS (e.g. REST type) • Core Web Services • Different internal architecture, development approach and governance for the various service types

31. Keep focus on the Service Model • Even agile needs to respect adding to the Service Model • Using the right framework for the Service Model it is a doable task

32. Don’t let WS slow you down • Late introduction of WS • Modern tools and layered architecture makes it trivial to add WS layer later • Get to WCF

33. Web Architectures requires WS • The Web 2.0 web applications heavily relies on WS • AJAX • Silverlight • Adobe XYZ • REST and JSON and similar technologies are predominant • Mashup and REST is a nice fit

34. Productivity is still king • Lot of productivity coming out of Redmond • ADO.Net data services • Dynamic Data • WCF • Software Factories

35. Staying in control • When working agile in iteration remember to have somebody responsible for the longer perspective • Could even be an Enterprise Architect  • In the end of the iteration feed information back into the Enterprise • Update service models • Domain categorizations • Promote services

36. Agile wrapup • Agile might not be the best longterm strategy but it is vary hard to avoid • The SOA architecture needs to be prepared for changes • The technology catch-up for developers and architects is huge so start small

37. Agenda • The SOA scene • ESB / MS Platform • Agile SOA • Product SOA

38. SOA Economy • In-house invented SOA components are expensive and of questionable value. • Reuse as funding to SOA overhead is questionable • Think twice before developing SOA components for non core business, focus on key differentiators • If at all possible by SOA enabled products for non core business

39. SOA Enabled Product • A Product designed for the SOA world • A product build og loosly coupled components • A product where components can be externalized • A product where business logic and user interface is separated by a service layer

40. Example SOA enabled productOBA Blueprint Org Workers Citizens / Customers Internet Portal (MOSS) InfoPath 2007 Browser Forms MOSS Intranet Portal Outlook with 360 plugin Presentation InfoPath Forms Libraries 360 Web parts Productivity WCF WF BDC LOB Integration 360 BL Web Service Application Services 360 Process Manager Forms Services Import mail service 360 Security and logging Data External Services Active Directory 360 Backend Server LOB

41. ExampleExternalize the contact model In this show case the contact model of a Enterprise Content Management system was replace with the customer model of Microsoft CRM MS CRM SI 360

42. SOA Products • Still in its infancy • Might be delivered as installable products • Might be cloud services • Requires a new mindset which provides space for smaller vendors

43. Summary • Use ESB with care, only for very stable stuff • Consider buying services • Use your Enterprise Architect to maintain a flexible Service Model • Technology and business models are changing rapidly to travel light

44. Comparing ESB and Cameras

45. Comparing ESB and Cameras • But in the end it all comes down to the photographer and the motif

46. Questions ?