Composite Message Pattern

Slide 1: YoungSu, Son indigoguru@gmail.com Microsoft MVP EvaCast Leader Devpia Architecture Sysop EvaCast (http://www.EvaCast.net)

Slide 2: Mo t i v a t i o n  Composite Message Pattern  Focus on organizing the communication infrastructure used by components.  Communication overhead is minimized.  Be Easy added or removed with minimal change.  When use marshaling / un-marshaling between components

Slide 3: Mo t i v a t i o n ( c o n t ’ d ) Dispatching Data Layer Decomposite Message UnMarshaling Layer Composite Message Marshaling Messages

Slide 4: Mo t i v a t i o n ( c o n t ’ d )

Slide 5: S e e d Pa p e r  Composite Messages : A Structural Pattern for Communication between Components, Aamod Sane, Roy Campbell, In OOPSLA’ 95 Workshop on Design Patterns for Concurrent, Distributed, and Parallel Object-Oriented Systems, 1995.”

Slide 6: Ag e n d a  Background Information  Problems  Solution  Applicability  Diagram (Static / Dynamic)  Benefits and Drawbacks  Implementation  Sample Code and Usage  Known Use  Variations  Related Patterns

Slide 8: Co mp o s i t e P a t t e r n

Slide 9: F a c t o r y Me t h o d P a t t e r n

Slide 10: Re f a c t o r i n g  Introduce Parameter Object  You have a group of parameters that naturally go together.

Slide 11: Re f a c t o r i n g  Preserve Whole Object  You are getting several values from an object and passing these values as parameters in a method call. int low = daysTempRange().getLow(); int high = daysTempRange().getHigh(); withinPlan = plan,withinRange(low,high); withinPlan = plan,withinRange(daysTempRange());

Slide 13: Ne t wo r k e d S y s t e m  Forces  Reflexibility  Packet Layout must be immune to addition and removal of layers.  Message Composition/Decomposition  Packet Layout has to simplify marshalling, fragmentation, reassembly, and unmarshalling of packets.  Efficient Memory Management  Memory Management should be Efficient.

Slide 14: Vi r t u a l F i l e S y s t e m Address Space Read Fault (Page Table) te Co mmunic ate ica mun Com Page-Frame Physical Page File Disk Block Contents

Slide 15: Vi r t u a l F i l e S y s t e m ( c ont ’ d)  If this interaction is implemented using simple method call,  the methods end up with too many parameters and complex control flow.  Resulting in programs that are brittle and hard to change.  Thus, Simplify the interaction, We have to package all the information.  Introduce Parameter Object  Preserve Whole Object

Slide 16: Vi r t u a l F i l e S y s t e m ( c ont ’ d)  Forces  Efficient Memory Management.  Memory Management for communicate data should be simple and efficient  Reflexibility  If new components are added or exiting one removed. Any changes to the set of components should be localized

Slide 17: Di s t r i b u t e d Vi r t u a l Sys t em

Slide 19: Lo o s e l y Co u p l e d Co mp o n e n t  Problem  Reflexibility  Message Composition/Decomposition  Efficient Memory Management

Slide 20: Lo o s e l y Co u p l e d Co mp o n e n t  Solution  Create a standard interaction protocol.  Example  Packet object defines method for adding and removing headers and payload, query packet size, and so on.

Slide 21: Lo o s e l y Co u p l e d Co mp o n e n t

Slide 22: Lo o s e l y Co u p l e d Co mp o n e n t Dispatching Data Layer popPacket() calls headerSize() / unmarshal UnMarshaling Layer pushPacket() calls makeHeader() / marshal() Messages Marshaling

Slide 23: Lo o s e l y Co u p l e d S y s t e m  CM helps with Efficient Memory Management  CM is possible to query each networking layer for the size of header.  CM will add, and allocate the memory all at once.  Reduces allocation overhead as well as allocator heap fragmentation.

Slide 24: Lo o s e l y Co u p l e d S y s t e m  Message Composition/Decompositon  Message Object can easy organize DataSets  DataSets = header + packet(payload)  It is easier to fragment the message for transmission and to later reassemble it.

Slide 25: Ti g h t l y Co u p l e d S y s t e m  Problem  Avoid many parameters passing  Complex Control Flow

Slide 26: Ti g h t l y Co u p l e d S y s t e m  Solution  Reify the parameters passed into a single parameter object  Object is a “Message” specific to the interaction.  Object provide simple methods that support some parameter manipulation (e.g. RangeCheck).  Simplifies Memory Management  Just passing a single pointer to the object instead of the raw parameters  Localizing the parameter passing into a single object  Makes it easy to assess the effect of adding or removing components.

Slide 28:  Static Participants  Loosely Coupled System  Tightly Coupled System  Dynamic Participants

Slide 29: S t a t i c Pa r t i c i p a n t s #1 - l o o s e l y Co u p l e d S y s t e m

Slide 30: Co mp o n e n t  Generate a Message  Add or Remove other DataSets.  Marshal and fragment a message  Unmarshal and reassemble message

Slide 31: Me s s a g e  Message is Composite that can contain other DataSets.  Defines standard method  add and remove DataSets.  Determine the sizes.  Marshalling, unmarshalling, fragmentation, reassembly

Slide 32: Da t a S e t a n d Da t a S e t I n t e r f a c e  DataSet  Each Layer generate DataSet.  Real Data DataSet may be added or removed from a Message.  DataSetInterface  A Common Interface for DataSet and Message

Slide 33: S t a t i c Pa r t i c i p a n t s #2 - Ti g h t l y Co u p l e d S y s t e m

Slide 34: Co mp o n e n t  Generate Parameter Object  Get and Set Parameter Info through Get()/Set()

Slide 35: Pa r a me t e r Ob j e c t  Encapsulates Parameters  Provide high lever access to parameters  get() and set() functions.  Know how to marshal() and unmarshal()

Slide 36: Dy n a mi c Pa r t i c i p a n t s

Slide 38: Be n e f i t s  Loosely Coupled System  Decouples Components by abstraction the communication structure  Overcome Heterogeneous Environment.  Define a meta-object protocol between the basic code of a system and the communication meta-system.  Tightly Coupled System  ParameterObject localizes components interactions.

Slide 39: Dr a wb a c k s  The complete standard protocol for Message may be overly general for some application  ParameterObject entails considerable bookkeeping overhead

Slide 40:  CM pattern has several distinct implementation  depending on Nature of System and Expected System Performance

Slide 41: Ti g h t l y Co u p l e d Co mp o n e n t s  Nature  Usually interact by parameter passing.  To avoid long parameter lists, We encapsulate the parameters into a ParameterObject.  Parameter Object may support methods that provide a higher level access to parameters.  Instead of Timestamp value, Parameter object support operation such as isMessageOlder();

Slide 42: Ti g h t l y Co u p l e d Co mp o n e n t s  Main Issue

Slide 43: Lo o s e l y Co u p l e d Co mp o n e n t s  Nature  Loosely Coupled Components communicate by constructing message that are composite of DataSets.  To Implement Composite Message Pattern  Link all DataSet together  Create a layout suitable for network transmission  Network Transmission Involves  Marshaling, Fragmentation, Unmarshaling and Reassembly.

Slide 44: Lo o s e l y Co u p l e d Co mp o n e n t s  The following Steps  Show how to construct a composite message suitable for network transmission and reception.

Slide 45: Lo o s e l y Co u p l e d Co mp o n e n t s  Step #1 - Composition using Linked List.  The simple way to implement CM pattern  links all the data set into a lined list  If system supports Distributed Object,  It would be possible to directly send and receive the linked list object.

Slide 46: Lo o s e l y Co u p l e d  Co mp–oMarshaling with minimal memory usage. Step #2 ne nt s  To Allocate sufficient storage.  Queries each recipient for the size of header and payload.  Extend header  Each header points to the header of the next DataSet  DataSet = Header + Payload.

Slide 47: Lo o s e l y Co u p l e d  Co mp–oFragmentssand Headers Step #3 ne nt  Simple allocation based on total size may not be sufficient.  In real world, Message is too big!  So We need Fragmentation, Reassembly  For message fragmentation, Use Header and Payload.

Slide 48: Lo o s e l y Co u p l e d Co mp o n e n t s  Step #3 – Fragment and Headers  Purpose of Header.  Payload may vary in size.  Don’t want to encode size limit in our code.

Slide 49: Lo o s e l y Co u p l e d  Co mp–oFragment s Headers Step #3 n e n t and  To use header, need following preconditions.  Header that describes format are also required for packet send across the network .  Header have to be situated at the beginning of the packet .  The location of the header in the marshaled message may be mandated by networking protocol requirements.  Header format must be known to the receiver  Receiver can determine the format of the payload simply by looking ah the header.

Slide 50: Lo o s e l y Co u p l e d Co mp o n–eFragment and Headers  Step #3 n t s  Fragment Decomposed into Fragment. H/W

Slide 51: Lo o s e l y Co u p l e d Co mp o n–eFragment and Headers  Step #3 n t s  Fragment ( Decide Message Sequence ) Decomposed into Fragment.  Fragment Header have ID (identify location info).  Replicate Message (Protocol) Header for each Frag Header.  Message Header is filled in by actual protocol.  TCP, IP, raw ethernet, fddi and so on.

Slide 52: Lo o s e l y Co u p l e d Co mp o n–eFragment and Headers  Step #3 n t s  Fragment ( Padding - Avoid splitting header info ) Decomposed into Fragment. Splitting  Header define payload format (especially payload size).  It is prudent to avoid splitting any headers of DataSets.  We need decriptors for header.  We pad the payload so that fragmentation boundaries occur on payload rather than headers.

Slide 53: Lo o s e l y Co u p l e d  Co mp – Reassembly Step # 4 one nt s  Receive Message sent by sender  Just Extract Payload (ignoring headers and padding)  Because the size of padding , Untill all fragments arrive  Reassembly Message  We Indicate the format of a fragment using auxiliary headers.  Auxiliary Header just have information about Splitting Information (Padding ..)

Slide 54:  Choices (Distributed Virtual Memory) Operating System  To Implement DVM,  we have to take contents of pages and ship them across the network.  For efficiency, DVM system use its own network protocol stack that supports fragmentations, reassembly, and reliable packet transfer.  The Stack can operate top of raw network like TCP/IP stack.  Since, Protocol Stack is customized for DVM  Tightly Couple the stack layer.  Communicate using Parameter Object.

Slide 55: DVMMe s s a g e Co d e Class DVMMessage // List of pages to marshal from and unmarshal to. { Page * _pageList; /* Network Protocol Header */ Page * _pageBeingProcessed //Leave space for Underlying Protocol Header /* Getter and Setter Functions */ // such as the Ethernet Header; unsigned _underlyingHeaderSize; //Expose using friend interfaces. unsigned _packetSize; …. //DVM Protocol using local identifiers public: DVMMessageType _type; unsigned _source; //add pages to the list similar to add() unsigned _destination; //for the abstract message unsigned _timestamp; void addPages (Page * morePages); unsigned _checksum; //marshal to buffer from page /* Header and Auxiliary Header */ void marshal (unsigned *buffer, unsigned bufferSize); //Page List Header //unmarshal from buffer into page unsigned _totalNumberOfPages; void unmarshal (unsigned* buffer, unsigned unsigned _thisPageNumber; bufferSize); unsigned _offsetInPages; unsigned _pageFramentSize; } };

Slide 56: F r a g me n t a t i o n Me s s a g e Co d e class Fragmenation { public : //calculate proper framents and ask message // to marshal parts of itself into the buffer. void makeFrags ( DVMMessage *m , unsigned * buffer, unsigned * bufferSize);

Slide 57:  Chocies Distributed Virtual System  Aamod Sane, Ken MacGregor, and Roy Campbell,  “Distributed virtual memory consistency protocols: Design and performance” ,  In Proceeding of the Second Workshop on Workstation Operating System, September 1989.  X-Kernel networking System  Norman C. Hutchinson and Larry L. Peterson.  “The x-kernel: An architecture for implementing network protocols.”  IEEE Transactions on Software Engineering, 17(1): 64-76, January 1001.  Parameter Object  Kent Beck.  Parameter Object.  patterns@cs.uiuc.edu, 1995

Slide 58:  Active Message  Is a message that knows how to process itself.  When a message is received by the receiver  The message contains the identify to the function that will process the message.  The receiver may directly dispatch the message as –is to the Processor rather than spending time on the protocol stack.  is applicable to homogeneous environment.  Include pointers to functions within the message object.  Use COM+, Enterprise Service

Slide 59:  Composite Message Pattern  Factory Method Pattern