SOA in the Real World

Udi Dahan The Software Simplist .Net Development Expert & SOA Specialist
Email: Udi@TheSoftwareSimplist.com Web: www.TheSoftwareSimplist.com

December 26, 2004

About Udi Dahan

Head of .Net Development Korentec
Leads C4I projects Consults on .NET architecture and design

Speaker at user groups throughout the country Author www.TheSoftwareSimplist.com

Specializes in Services Oriented Architecture (SOA)

Recognized .NET expert by Microsoft Israel

Agenda
SOA Basics

SOA In The Real World

Connected Systems Architectures SOA Clients

SOA Basics
Why SOA What SOA Means 4 Tenets of SOA What the tenets mean

SOA Basics Why SOA ?

Problems:
Systems today are bigger than ever before
Complexity increases exponentially with size - Juval Lowey Systems need to be interconnected OO solved the problems of small-medium sized systems CO (Component Orientation) solved problems OO couldnt on medium-large systems Neither OO nor CO could cope with the problems of very large systems, systems of systems, or integration between systems

SOA Basics Why SOA ?

SOA Basics What SOA Means

SOA attempts to solve problems OO and CO could not solve by raising the level of abstraction Architecture composed of services Efficient for:
large systems
distributed systems systems of systems

Inefficient for:
Small medium sized systems Non-distributed systems
7

SOA Basics What SOA Means

SOA Basics What SOA Means

SOA attempts to solve problems OO and CO could not solve by raising the level of abstraction Architecture composed of services Efficient for:
large systems
distributed systems systems of systems So whats a service ?

Inefficient for:
Small medium sized systems Non-distributed systems
9

SOA Basics 4 Tenets of SOA

A service is autonomous

A service has explicit boundaries

A service exposes schema & contract, not class or type

A service allows or denies use based on policy

10

SOA Basics What the tenets mean

A service is autonomous

11

SOA Basics What the tenets mean

A service is autonomous
You dont new a service its just there.

12

SOA Basics What the tenets mean

private void btnSave_OnClick(object sender, System.EventArgs e) {

BL.User u = new BL.User(); u.FirstName = txtFirstName.Text; u.LastName = txtLastName.Text;

u.Address = txtAddress.Text;

u.Save(); }

13

SOA Basics What the tenets mean

A service is autonomous
You dont new a service its just there.

A service has explicit boundaries

14

SOA Basics What the tenets mean

A service is autonomous
You dont new a service its just there.

A service has explicit boundaries

Services run in a separate process from their clients A boundary must be crossed to get from the client to the service network, security,

15

SOA Basics What the tenets mean

A service is autonomous
You dont new a service its just there.

A service has explicit boundaries

Services run in a separate process from their clients A boundary must be crossed to get from the client to the service network, security,

A service exposes schema & contract, not class or type

16

SOA Basics What the tenets mean

A service is autonomous
You dont new a service its just there.

A service has explicit boundaries

Services run in a separate process from their clients A boundary must be crossed to get from the client to the service network, security,

A service exposes schema & contract, not class or type

Clients send messages to a service that conform to a contract

17

SOA Basics What the tenets mean

private void btnSave_OnClick(object sender, System.EventArgs e) { UserRequest ur = new UserRequest( UserActions.Save, txtFirstName.Text, txtLastName.Text, txtAddress.Text);

UserResponse response = BL.UserService.DoRequest(ur); }

18

SOA Basics What the tenets mean

A service is autonomous
You dont new a service its just there.

A service has explicit boundaries

Services run in a separate process from their clients A boundary must be crossed to get from the client to the service network, security,

A service exposes schema & contract, not class or type

Clients send messages to a service that conform to a contract

A service allows or denies use based on policy

19

SOA Basics What the tenets mean

A service is autonomous
You dont new a service its just there.

A service has explicit boundaries

Services run in a separate process from their clients A boundary must be crossed to get from the client to the service network, security,

A service exposes schema & contract, not class or type

Clients send messages to a service that conform to a contract

A service allows or denies use based on policy

The service decides what messages it processes

20

SOA Basics What the tenets mean

private void btnSave_OnClick(object sender, System.EventArgs e) { UserRequest ur = new UserRequest( UserActions.Save, txtFirstName.Text, txtLastName.Text, txtAddress.Text); SignedRequest sr = myCertificate.Sign(ur);

BL.UserService.EnqueueRequest(sr); }

21

SOA In The Real World

Messaging Trust Time

22

SOA In The Real World - Messaging

Clients communicate with a service with messages
How does the client get the message contract?
Usually is given a DLL for non-web services scenarios

How does the client know where the service is?

Usually hard coded dynamic discovery hasnt delivered yet, versioning is often a problem

23

SOA In The Real World - Messaging

Normal Client Server (Remoting)

Client

Service

Get an Object

Work with Object

24

Normal Client Server (Remoting)

Client

Service

Get an Object

Work with Object

25

SOA In The Real World - Messaging

Messaging between client & service

All info encapsulated in the message

Client Perform this action on entities with these IDs

Service

26

Messaging between client & service

Client Perform this action on entities with these IDs

Service

27

Messaging between client & service

Client Perform this action on entities with these IDs

Service

28

29

SOA In The Real World - Messaging

Clients NEVER get references to objects inside the service
How can client code still be OO (or CO) ?
Messages need to be wrapped appropriately.

Often, client code will need to temporarily store several changes in order to send a single message -> Service agents do this.

30

SOA In The Real World - Messaging

Clients need to work with several services
How does client code aggregate data using messaging?
There is no INNER JOIN between services. Client copies data from the services into its own DB.

-> How is stale data handled?

31

SOA In The Real World - Trust

How does the service know which clients to trust?
Each message from the client needs to contain information about who the client is, and what its credentials are.
Authentication data is passed out of band usually in the header.

If encryption is used, messages can get bloated and negatively impact performance. Secure conversation mechanisms can help.

32

SOA In The Real World - Time

Asynchronous messaging introduces the possibility that certain assumptions that were true when a message was sent, may no longer be true when it arrives.
Logic needs to be added to client code that indicates under what circumstances the message should be processed.
Example: A new order for 500 widgets is sent based on the price, $1/widget and the order should be processed only if the price doesnt increase more than %5.

33

SOA In The Real World - Time

If you think that making everything synchronous will solve time issues think again.
Request Response is SLOW !! Are you really going to make the user wait until the service sends a response, before letting them do the next action ? Even then, it wont solve the example problem of price changes without a way for the client to lock the data in the service while it decides if the price is right.

34

SOA In The Real World - Time

Forget about transactions between services.

ACID is dead.
Client code needs to add logic to handle what ACID did.
It is NOT easy.

35

Connected Systems Architectures

What is a CSA

Scenarios
Problems

36

Connected Systems Architectures What is it?

CSA describe a class of applications that are connected

CSA is a subset of SOA

Often called system of systems Very large systems are built this way to reduce complexity Each part isnt meant to be used on its own.

37

Connected Systems Architectures Scenarios

Military applications: Headquarters application is connected to several field level applications.
Commands go from the HQ to the field Updated mission status go from the field to the HQ Updated global state is published from the HQ to the field

The client is also the service

38

Connected Systems Architectures Scenarios

Business applications: Marketing app publishes new products, Sales updates price lists, Web brings orders in
Each system was developed separately. Now need to work together. Every app that can be updated by other systems needs a separate module to handle messages coming in.

In order to minimize app rewrite, the new module listens for messages and updates the apps database.
Messages can NOT be lost, even if a service is down. Each order is money in the bank.

39

Connected Systems Architectures

40

Connected Systems Architectures Problems

How are failures handled?

What if were expecting a response and it doesnt arrive?

What if we get duplicate messages? What if we get an old message? If were using asynchronous messaging, how can we implement Request-Response semantics?

41

SOA Clients
Requirements

Compared to Services
Deadlocks Architecture Message Flow Solution Structure

42

SOA Clients Requirements

Client can be updated from various sources (including the user) No one action should prevent the handling of another action
Just because the user clicked the menu doesnt mean that the price drop message handling should be delayed.

Everything must be logged

When things go wrong, we need to know how it happened Some industries require a trail of all actions performed for auditing purposes

43

SOA Clients Compared to Services

Services can/should be stateless

Clients MUST be statefull

Services dont have to be multi-threaded, can handle one message at a time. Clients MUST be multi-threaded need to handle user input at the same time as handling a message How do we prevent the client from dead-locking?
44

SOA Clients Deadlocks

There are 3 levels for handling deadlocks:
Architecture
Design Code

You can guess which is best

45

SOA Clients Deadlocks

Handling deadlocks with code:
Mutex
Monitor ReaderWriterLock ManualResetEvent / AutoResetEvent Interlocked WaitHandle

If you see these in your code, youre in trouble.

46

SOA Clients Deadlocks

Handling deadlocks by design:
Use synchronization domains (SD) to divide up the runtime behavior of the system Make all classes which will be run in more than one thread inherit from ContextBoundObject Place the [Synchronization] attribute on all those classes

Pros: This will make sure that only one thread can access a group of objects at a time without dead locking.

Cons: Wrong division of SDs will lead to poor performance negates requirements.

47

SOA Clients Deadlocks

Handling deadlocks by architecture Micro SOA:
Requires only minimal use of multi-threading specific code
Uses queues to keep threads separate and for communication All objects (except queues) are accessible by only one thread
Exception: Interactive thread and thread that updates the UI share objects

Corollaries:
All threads need their own copy of the data Writing to the database (and log) should happen on its own thread. Sending messages at high speeds burdens the system separate thread

48

SOA Clients Architecture

Use synchronization domains here Interactive Thread

Presentation Thread

Logic Thread

Communications Thread

Data Access Thread

Presentation Services

Logic Services

Communications Services

Data Access Services

Presentation Queue

Logic Queue

Communications Queue

Data Access Queue

DB

Yellow lines are for DeQueue operations, Red are for EnQueue operations, White are for direct calls. Small circles represent in memory objects.
49

SOA Clients Message Flow

Data Access Messages Communications

Logic

Presentation

50

SOA Clients Solution Structure

51

52

Thank you

Udi Dahan The Software Simplist .Net Development Expert & SOA Specialist
Email: Udi@TheSoftwareSimplist.com Web: www.TheSoftwareSimplist.com

December 26, 2004