Upload
daniel-marbach
View
132
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Slides for my Composite User Interfaces for Service Oriented Systems workshop.
Citation preview
Composite UIfor Service Oriented Systems
Daniel Marbach @danielmarbachbbv Software Services AG
De CompositionW
hy
How
Why
How
SystemApplication
Fancy 1.0
SystemApplication
Fancy 1.0
The network is reliable
Latency isn’t a problem
Bandwidth isn’t a problem
The network is secure
Topology won’t change
The administrator will know what to do
Transport cost isn’t a problem
The network is homogeneous
The system is atomic/monolithic
The system is finished
Business logic can and should be centralized
The network is reliable
var svc = new MyService();var result = svc.Process(data);
Risk analysisInfrastructure and software redundancyReliable messaging
Latency isn’t a problem
Network
In-Memory
Serialization
Don’t cross the networkTake all data you might needMinimize chit-chat
Bandwidth isn’t a problemBigData
Congestion
Balance eager fetch vs. lazy loadingBalance bandwidth vs. latencySeparate networks
The network is secure
100% Safety is not possible
Threat model analysisBalance costs against risksTalk about it
Topology won’t changeServer down
Server moved
Don’t hard-codeResilient protocolsDiscoveryChaos Monkey
The administrator will know what to do Bus factor
Updates
Automate & Test deploymentDesign for multiple versions runningconcurrentlyAllow part of the system to be takendown
Transport cost isn’t a problemSerialization
Hardware
Reduce chit-chatInfrastructure versus development costs
The network is homogeneous.NET/Java
NoSQL, REST
Interop is hardBudget for it
The system is atomic/monolithicNot scalable
Single DB
Ripple effects
Internal loose couplingModularizeDesign for scale out in advance
The system is finishedEffort ($/T) “Finished” Rewrite
Original date “never”finished
Design for maintenanceDesign for upgradesVersioning is hard
Business logic can and should be centralized
Logic is distributed, live with itGroup by feature
Big Ball of MudMonolithic
CouplingX depends on Y
Afferent Efferent
who depends on you on who you depend
Platform Temporal Spatial
Platform
Interoperability
Using platform dependent protocols- Remoting- Enterprise Services- Datasets over Webservices
PlatformXML / XSD, JSON, Protocol BufferHTTPWSDL…
TemporalX depends on Y and processing time of Y directlyinfluences the processing time of X.
Temporalseparate the inter-service communication in time with pub/sub
A
MakeCustomerPreferred()
B
Publish updated customer info
Store data
Save customer as preferred
Publish Customer made preferred
SpatialWhen location not available the system cannotoperate
SpatialIntroduce logical destinationsLoadbalancingRoute to logical destinations
MessagingReduces coupling
Addresses some of the fallaciesNo silver bullet
Use Messaging to transfer packets of data frequently, immediately, reliably, and
asynchronously, using customizable formats.
Asynchronous messaging is fundamentally a pragmatic reaction to the problems of
distributed systems. Sending a message does not require both systems to be up and ready
at the same time. Furthermore, thinking about the communication in an asynchronous
manner forces developers to recognize that working with a remote application is slower,
which encourages design of components with high cohesion (lots of work locally) and low
adhesion (selective work remotely).
MessagingReduces coupling
(platform, temporal, afferent and efferent)Addresses some of the fallacies
Throughput
Load
RPC
Messaging
Receiver
Sends, and keeps on working
Sender
Id
Id
Receiver
Sender
Id
Outgoing
Incoming
DBApp
[HTTP] $$ Order
TxCall 1 of 3
Call 2 of 3
Crash
Rollback
Where’s the order!?
Infra$$ Order
Your code
TX Receive
DBCall 1 of 3
Rollback
Call 2 of 3
Rollback
The order is back in the queue
Invokes
DTC
Enlists
Q
Retry
DTC is a timebomb
Bus$$ Order
Your code
Receive
DBCall 1 of 3
Rollback
Call 2 of 3
Rollback
The order is back in the queue
Invokes
Q
Retry
MessagePayload (Body)
Metadata (Header)%like% HTTP
Receiver
Return Address Some time in the future
Sender
Return Address
Receiver
Some time in the future
Sender
Correlation ID
Message ID
ReceiverSenderReceiver
Receiver
Ordering
Messaging Buy-in
Service
Function, WebService, Class or Database
Set of technologies
Reuse strategy
Of-the-shelve solution
Way to align IT and business
Business capability
Data &Business Rules
Everythingis contained
Nothing leftover
Autonomous
Explicit Boundaries
Contract& Schema
Policy Policy
Data Outside vs. Inside
Outside Inside
Unique ID (UUID or with human readable with version)OK to cache
ImmutableValid rangesStable
Rules for sending messages
Unique ID (UUID or with human readable with version)OK to cache
ImmutableValid rangesStable
Rules for sending messages
Then Now
Command Event
Mashup
Bringing it together
Composite Front End
Client/Server/Service
Portlet
Layout
Inter-portletcommunication
Shell
Single sign-on
UI Logic
Agent
Host
Other legacy systems
UI
Business Logic
Adaptors
Server logic
Agent
Challenges you’ll face
Queries
Responses
Messages to UI
Deployment
Contract sharing
Dependencies
Status bars Dynamic
QueriesDon’t use messagingUse read modelsDatabases scale well when readonlyJust query it
ResponsesNever block the UIEvent AggregatorsForget callbacks, they suck!
Messages to UIDoesn’t need to be 1:1 mappingTask based UI
Status barsThey never tell the truthTrick the user with some educated guessesUse indeterminate progress bars
DeploymentKeep it simpleAutomate itVisualize and monitor itConfiguration can be hard, design for it
Contract sharingFavor loose contracts over interfaces and classesBe pragmatic for compositionIT/OPS defines interfaces, services implement them
DependenciesSemantic VersioningNuget
DynamicDon’t go overboard with fancy techniquesSometimes hard-wiring is just fine
Daniel Marbach [email protected]
twitter: @danielmarbachblog: www.planetgeek.ch
www.bbv.ch/blogOSS lead: Appccelerate / MSpec
user group: www.dotnet-zentral.ch