jakobrojel'dk

1
SOA Tailoring

• jakob_at_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 doesnt 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
• Thats the point! Its 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 OsloNB. 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 isnt 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
Dont 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
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 ?