Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

5.
Interaction Models Two model dominate distributed computing environments – synchronous and asynchronous communication – a solid knowledge of models is key to understanding benefits and differences between MOM and other forms of distribution Synchronous Interaction – caller must block & wait (suspend processing) until the called completes – participants do not have processing control independence • they rely on the return of control from the called systems Asynchronous Interaction – caller retains processing control, does not need to block – requires an intermediary to handle the exchange of requests – participants retain processing independence (continue processing) regardless of the state of the others Introduction to Message-Oriented Middleware 5

8.
Introducing RPC Traditional Distribution model – Utilized in middleware platforms including • CORBA, Java RMI, Microsoft DCOM & XML-RPC – Based on the synchronous interaction model RPC creates a facade, making both processes believe they are in the same process space – Similar to a local procedure call • control is passed to procedure in sequential synchronous manner Direct conversation between two parties – (similar to a person-to-person telephone conversation) Introduction to Message-Oriented Middleware 8

11.
MOM Based on the asynchronous interaction model – not required to block and wait on a message send Allows delivery of messages when the sender or receiver is – not active or available to respond at the time of execution Supports delivery for messages that may take minutes to deliver – as apposed to RPC that delivers in milliseconds or seconds • ( ! 100% True) Sending application has no guarantee message will be read nor is it given guarantee about the time it will take to deliver – these aspects are mainly determined by the receiving application Similar to the postal service – Messages are delivered to the post office; the postal service then takes responsibility for safe delivery of the message Introduction to Message-Oriented Middleware 11

13.
MOM Coupling – creates loose coupling between participants in a system • independent layer acts as an intermediary to exchange messages • ability to link systems without adapting source and target systems Reliability – guarantee message delivery to each intended recipient exactly once • message loss is prevented by using a store and forward mechanism – high-level of reliability (typically configurable) Scalability – decouples performance characteristics of the subsystems from each other • subsystems can scale independently – messaging models contain natural traits for effective load balancing (…) Availability – high availability capabilities – does not require simultaneous or “same-time” availability of all subsystems Introduction to Message-Oriented Middleware 13

14.
When to use RPC or MOM RPC – suffers from inflexibility and tight coupling – problematic to scale parts of the system and deal with service outages – assumes simultaneously available – require more bandwidth than a similar MOM interaction – designed on the notion of a single client talking to a single server, traditional RPC has no built in support for one-to-many communications – simplicity of the mechanism and straightforward implementation – guarantee of sequential processing - RPC is slow but consistent • work is always carried out in the correct order. • important considerations for systems that requires 100% temporal integrity – temporal inaccuracies RPC is ideal if you want a strongly-typed/OO system with tight coupling, compile-time semantic checking and more straightforward impl. MOM is an ideal solution if the systems will be a geographically dispersed deployment with poor network connectivity and stringent demands in reliability, flexibility and scalability Introduction to Message-Oriented Middleware 14

18.
Messaging Models Two main message models are commonly available – point-to-point – publish/subscribe Both are based on the exchange of messages through a channel (queue) Typical system will utilize a mix of these models to achieve different messaging objectives Introduction to Message-Oriented Middleware 18

19.
Point-to-Point Model Straightforward asynchronous exchange of messages – message routed to consuming clients via a queue – no restriction on number of publishing clients – usually only a single consuming client (not a strict requirement) • each message is delivered only once to only one receiver Messages are always delivered and will be stored in the queue until a consumer is ready to retrieve them Introduction to Message-Oriented Middleware 19

20.
Publish Subscribe Models One-to-many and many-to-many distribution mechanism – allows single producer to send a message to one user or potentially hundreds of thousands of consumers Clients "publish" to a specific topic or channel Channels are “subscribed” to by clients to consume msgs No restriction on the role of a client – may be both a producer and consumer of a channel§ Introduction to Message-Oriented Middleware 20

21.
Hierarchical Channels Hierarchical channels (topics) – Destination grouping mechanism in pub/sub model – Structure allows channels to be defined in a hierarchical fashion – Each sub-channel offers a more granular selection of the messages contained in its parent – Clients subscribe to the most appropriate level of channel  In large-scale systems, grouping of messages into related types (i.e. into channels) helps to manage large volumes of different messagesIntroduction to Message-Oriented Middleware 21

22.
Comparsion of ModelsMost messaging objectives can be achieved using either model or combination of bothFundamental difference – publish/subscribe model • every consumer to a topic/channel will receive a message published to it – point-to-point model • only one consumer will receive itTopics can be used to categorize different types of messagesPub/Sub model is more powerful messaging model for flexibility, but it is more complex Introduction to Message-Oriented Middleware 22

25.
Service Oriented Architecture The problems and obstacles encountered during system integration pose major challenges for IT departments: “70% of the average IT department budget is devoted to data integration projects” –IDC “PowerPoint engineers make integration look easy with lovely cones and colorful boxes” – Sean McGrath, CTO, Propylon“A typical enterprise will devote 35% - 40% of its programmingbudget to programs whose purpose is solely to transferinformation between different databases and legacy systems”-Gartner Group Introduction to Message-Oriented Middleware 25

26.
Service Oriented Architecture MOM used to create highly open and flexible systems that allow the seamless integration of subsystems MOM solves many of the transport issues with integration However, major problems still exist with the representation of data, its format and structure To develop a truly open system, MOM requires the assistance of additional technologies such as XML and Web Services Introduction to Message-Oriented Middleware 26

27.
XML Programming language and platform independent format for representing data – eliminates any networking, operating system or platform binding that a binary proprietary protocol would use Once data is expressed in XML, it is trivial to change the format To use XML as a message exchange medium, standard formats need to be defined to structure the XML messages – i.e. ebXML andOASIS Universal Business Language (UBL) • With UBL, you convert your internal message formats to the standard UBL format and export to the external environment Introduction to Message-Oriented Middleware 27

28.
Web Services Web Services – platform and language independent standards defining protocols for heterogeneous integration Can be seen in a number of ways – Business-to-business/enterprise application integration tool – natural evolution of basic RPC mechanism A key benefit of a web services deployment is that they act as a facade to the underlying language or platform Web services which are often touted as a replacement for traditional RPC – Viewed in this light they still suffer from many of its shortcomings Introduction to Message-Oriented Middleware 28

30.
Developing SOAsThrough a combination of XML, SOAP and WS, we are able to create Service-Oriented Architectures (SOA)A service is a set of input messages sent to a single or composition of objects, with the return of causally related output messages –fundamental design concept is to reduce processing to logic black boxes –standard XML format for input and output formatsAn important aspect of SOAs is message centric structureOnce initial infrastructure created for the architecture, the amount of effort to connect to further systems is minimal Introduction to Message-Oriented Middleware 30

31.
XML Transformation Pipelines Where message formats differ – XML based integration can convert the message to and from the format using XML transformation pipeline – data transformation can be seen as just another assembly line problem – with transformations taking place outside of the applications it a non-invasive method of integration Introduction to Message-Oriented Middleware 31