c





   c c



 c
c


      
      


Ô
 

  Ô

þ 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


 ! 

þ SOA Basics
þ SOA In The Real World
þ Connected Systems Architectures
þ SOA Clients

·
 "#


þ Why SOA

þ What SOA Means

þ 4 Tenets of SOA

þ What the tenets mean

 "#
$ %"&

þ roblems:
‡ 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 couldn¶t 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 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


 "#
$ "'  

´
 "#
$ "'  

þ 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 what¶s a service ?
þ Inefficient for:
‡ Small ± medium sized systems
‡ Non-distributed systems

Ë
 "#
$
 "

þ 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

â
 "#
$    
þ A service is autonomous

ââ
 "#
$    
þ A service is autonomous
‡ You don¶t ³new´ a service ± it¶s just there.

â
 "#
$    

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();
}

â·
 "#
$    
þ A service is autonomous
‡ You don¶t ³new´ a service ± it¶s just there.

þ A service has explicit boundaries

 "#
$    

þ A service is autonomous
‡ You don¶t ³new´ a service ± it¶s 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 is autonomous
‡ You don¶t ³new´ a service ± it¶s 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

â
 "#
$    
þ A service is autonomous
‡ You don¶t ³new´ a service ± it¶s 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

â
 "#
$    

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);

}

â´
 "#
$    
þ A service is autonomous
‡ You don¶t ³new´ a service ± it¶s 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

âË
 "#
$    
þ A service is autonomous
‡ You don¶t ³new´ a service ± it¶s 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


 "#
$    

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);
}

â
 "(  ) 

þ  essaging

þ Trust

þ Time


 "(  ) * ' ! !

þ 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 hasn¶t delivered yet,

versioning is often a problem

·
 "(  ) * ' ! !

0+ $  , 1)  !2

+   ,

-  ".


/ ".


 0+ $  , 1)  !2

+   ,

-  ".


/ ".


å
 "(  ) * ' ! !

' ! !  
 4 ,

 
    !

+   ,

3  

      
   (Ô


 ' ! !  
 4 ,

+   ,

3  

      
   (Ô


 ' ! !  
 4 ,

+   ,

3  

      
   (Ô

´
Ë
 "(  ) * ' ! !

þ 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.

·
 "(  ) * ' ! !

þ 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 it¶s own DB.

-> How is stale data handled?

·â
 "(  ) * 

þ 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 it¶s 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.

·
 "(  ) *  

þ 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 doesn¶t increase
more than %5.

··
 "(  ) *  

þ 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 won¶t 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.

 "(  ) *  

þ Forget about transactions between services.

þ ACID is dead.

þ Client code needs to add logic to handle what ACID did.

‡ It is NOT easy.

·å
 +
 % 
 
 

þ What is a CSA
þ Scenarios
þ roblems

·
 +
 % 
 
 $   &

þ 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´ isn¶t meant to be used on it¶s own.

·
 +
 % 
 
 $ 
 

þ 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

·´
 +
 % 
 
 $ 
 

þ 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 app¶s database.
‡ Messages can NOT be lost, even if a service is down. Each order is
money in the bank.

·Ë
 +
 % 
 
 

 +
 % 
 
 $ 3 

þ How are failures handled?

þ What if we¶re expecting a response and it doesn¶t arrive?
þ What if we get duplicate messages?
þ What if we get an ³old´ message?
þ If we¶re using asynchronous messaging, how can we
implement Request-Response semantics?

â
 "+ 

þ Requirements
þ Compared to Services
þ Deadlocks
þ Architecture
þ Message Flow
þ Solution Structure


 "+ $ ) 5   

þ 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 doesn¶t 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

·
 "+ $ +  ,


þ Services can/should be stateless

þ Clients MUST be statefull

þ Services don¶t 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?

 "+ $ Ô 
/

þ There are 3 levels for handling deadlocks:

‡ Architecture
‡ Design
‡ Code

þ You can guess which is best

å
 "+ $ Ô 
/

þ Handling deadlocks with code:

‡ Mutex
‡ Monitor
‡ ReaderWriterLock
‡ ManualResetEvent / AutoResetEvent
‡ Interlocked
‡ WaitHandle

þ If you see these in your code, you¶re in trouble.


 "+ $ Ô 
/

þ 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
‡ lace the [Synchronization] attribute on all those classes

þ ros: 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.


 "+ $ Ô 
/

þ 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 it¶s own thread.
Sending messages at high speeds burdens the system ± separate thread

´
 "+ $ 
 

 %
 9  
  

(  
 ,  

3     7!
  +
   Ô



     

3     7!
 +
   Ô



 ,
  ,
  ,
  ,


3     7!
6  +
   Ô



6  6  6 

8   Ô 6     )   6      Ô#

    



      %.


Ë
 "+ $ ' ! :

Ô



' ! 

+
  

7!

3   

å
 "+ $   


åâ
å
   !

   c c



 c
c


      
      


Ô