• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Composite Message Pattern
 

Composite Message Pattern

on

  • 4,232 views

This pattern uses when marshal and unmarshal message.

This pattern uses when marshal and unmarshal message.
if you will get the internal of marshaling/unmarshaling.
you see this paper.

Statistics

Views

Total Views
4,232
Views on SlideShare
4,095
Embed Views
137

Actions

Likes
0
Downloads
28
Comments
1

2 Embeds 137

http://arload.wordpress.com 131
http://www.slideshare.net 6

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • this presentation is made by powerpoint 2007.

    so this file is broken.



    if you want to see the perfact page. you must download this file.



    thaks a lot ^^
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Composite Message Pattern Composite Message Pattern Presentation Transcript

    • YoungSu, Son [email_address] Microsoft MVP EvaCast Leader Devpia Architecture Sysop EvaCast ( http://www.EvaCast.net )
    • Motivation
      • 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
    • Motivation (cont’d) Data Layer Composite Message Messages UnMarshaling Marshaling Layer Decomposite Message Dispatching
    • Motivation (cont’d)
    • Seed Paper
      • 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.”
    • Agenda
      • Background Information
      • Problems
      • Solution
      • Applicability
      • Diagram (Static / Dynamic)
      • Benefits and Drawbacks
      • Implementation
      • Sample Code and Usage
      • Known Use
      • Variations
      • Related Patterns
    •  
    • Composite Pattern
    • Factory Method Pattern
    • Refactoring
      • Introduce Parameter Object
        • You have a group of parameters
        • that naturally go together .
    • Refactoring
      • Preserve Whole Object
        • You are getting several values from an objec t 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() );
    •  
    • Networked System
      • 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 .
    • Virtual File System Fault Address Space (Page Table) Read Communicate Communicate Page-Frame Physical Page Disk Block File Contents
    • Virtual File System (cont’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
    • Virtual File System (cont’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
    • Distributed Virtual System
    •  
    • Loosely Coupled Component
      • Problem
        • Reflexibility
        • Message Composition/Decomposition
        • Efficient Memory Management
    • Loosely Coupled Component
      • Solution
        • Create a standard interaction protocol .
      • Example
        • Packet object defines method
        • for adding and removing headers and payload,
        • query packet size , and so on.
    • Loosely Coupled Component
    • Loosely Coupled Component Data Layer pushPacket() calls makeHeader() / marshal() Messages UnMarshaling Marshaling Layer popPacket() calls headerSize() / unmarshal Dispatching
    • Loosely Coupled System
      • 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.
    • Loosely Coupled System
      • 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.
    • Tightly Coupled System
      • Problem
        • Avoid many parameters passing
        • Complex Control Flow
    • Tightly Coupled System
      • 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.
    •  
      • Static Participants
        • Loosely Coupled System
        • Tightly Coupled System
      • Dynamic Participants
    • Static Participants #1 - loosely Coupled System
    • Component
      • Generate a Message
      • Add or Remove other DataSets.
      • Marshal and fragment a message
      • Unmarshal and reassemble message
    • Message
      • Message is Composite that can contain other DataSets.
      • Defines standard method
        • add and remove DataSets.
        • Determine the sizes.
        • Marshalling, unmarshalling, fragmentation, reassembly
    • DataSet and DataSetInterface
      • DataSet
        • Each Layer generate DataSet.
        • Real Data DataSet may be added or removed from a Message.
      • DataSetInterface
        • A Common Interface for DataSet and Message
    • Static Participants #2 - Tightly Coupled System
    • Component
      • Generate Parameter Object
      • Get and Set Parameter Info through Get()/Set()
    • Parameter Object
      • Encapsulates Parameters
        • Provide high lever access to parameters
        • get() and set() functions.
      • Know how to marshal() and unmarshal()
    • Dynamic Participants
    •  
    • Benefits
      • 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 .
    • Drawbacks
      • The complete standard protocol for Message may be overly general for some application
      • ParameterObject entails
      • considerable bookkeeping overhead
      • CM pattern has several distinct implementation
        • depending on Nature of System and
        • Expected System Performance
    • Tightly Coupled Components
      • 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();
    • Tightly Coupled Components
      • Main Issue
    • Loosely Coupled Components
      • 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.
    • Loosely Coupled Components
      • The following Steps
        • Show how to construct a composite message
        • suitable for network transmission and reception.
    • Loosely Coupled Components
      • 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.
    • Loosely Coupled Components
      • Step #2 – Marshaling with minimal memory usage.
        • 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.
    • Loosely Coupled Components
      • Step #3 – Fragments and Headers
        • 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.
    • Loosely Coupled Components
      • Step #3 – Fragment and Headers
        • Purpose of Header.
          • Payload may vary in size.
          • Don’t want to encode size limit in our code.
    • Loosely Coupled Components
      • Step #3 – Fragment and Headers
        • 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.
    • Loosely Coupled Components
      • Step #3 – Fragment and Headers
        • Fragment
      H/W Decomposed into Fragment.
    • Loosely Coupled Components
      • Step #3 – Fragment and Headers
        • 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.
    • Loosely Coupled Components
      • Step #3 – Fragment and Headers
        • Fragment ( Padding - Avoid splitting header info )
      Decomposed into Fragment.
        • 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.
      Splitting
    • Loosely Coupled Components
      • Step # 4 – Reassembly
        • 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 ..)
      • 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 .
    • DVMMessage Code Class DVMMessage { /* Network Protocol Header */ //Leave space for Underlying Protocol Header // such as the Ethernet Header; unsigned _underlyingHeaderSize; unsigned _packetSize; //DVM Protocol using local identifiers DVMMessageType _type; unsigned _source; unsigned _destination; unsigned _timestamp; unsigned _checksum; /* Header and Auxiliary Header */ //Page List Header unsigned _totalNumberOfPages; unsigned _thisPageNumber; unsigned _offsetInPages; unsigned _pageFramentSize; } // List of pages to marshal from and unmarshal to. Page * _pageList; Page * _pageBeingProcessed /* Getter and Setter Functions */ //Expose using friend interfaces. … . public: //add pages to the list similar to add() //for the abstract message void addPages (Page * morePages); //marshal to buffer from page void marshal (unsigned *buffer, unsigned bufferSize); //unmarshal from buffer into page void unmarshal (unsigned* buffer, unsigned bufferSize); };
    • Fragmentation Message Code 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);
      • 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.
        • [email_address] , 1995
      • 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
      • Composite Message Pattern
      • Factory Method Pattern
    •