composite user interfaces for service oriented systems without exercises

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 daniel.marbach@bbv.ch

twitter: @danielmarbachblog: www.planetgeek.ch

www.bbv.ch/blogOSS lead: Appccelerate / MSpec

user group: www.dotnet-zentral.ch