message broker programming of distributed applications

8/16/2019 Message Broker Programming of distributed applications

http://slidepdf.com/reader/full/message-broker-programming-of-distributed-applications 1/19

Report on

Programming of Distributed Applications

Laboratory no.1 - Message Broker

Student: Victor Ţurcanu

Teacher: Dumitru Ciorbă

October 23, 2015

1



Table of Contents

1 Description of the problem 31.1 Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Broking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Decoupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Developing directions . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.1 Message Translator (Messaging Systems) . . . . . . . . 61.4.2 Publish-Subscribe Channel (Messaging Channels). Durable

Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . 71.4.3 Content-Based Router (Message Routing) . . . . . . . 8

2 Description of personal solution 9

2.1 Steps of elaboration of the application . . . . . . . . . . . . . 92.2 Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Design and application architecture . . . . . . . . . . . . . . . 13

2.4.1 Class Diagram . . . . . . . . . . . . . . . . . . . . . . 132.4.2 Component Diagram . . . . . . . . . . . . . . . . . . . 14

3 Code 14

4 Conslusion 18

2



1 Description of the problem

Task : Message broker integration which will allow an asynchronous com-munication between the distributed components of the system.

1.1 Messaging

Messaging is a technology that enables high-speed, asynchronous, program-to-program communication with reliable delivery. Programs communicate bysending packets of data called messages to each other. Channels, also knownas queues, are logical pathways that connect the programs and convey mes-sages. A channel behaves like a collection or array of messages, but one thatis magically shared across multiple computers and can be used concurrently

by multiple applications. A sender or producer is a program that sends amessage by writing the message to a channel. A receiver or consumer is aprogram that receives a message by reading (and deleting) it from a channel.

The message itself is simply some sort of data structure—such as a string,a byte array, a record, or an object. It can be interpreted simply as data,as the description of a command to be invoked on the receiver, or as thedescription of an event that occurred in the sender. A message actually con-tains two parts, a header and a body. The header contains meta-informationabout the message—who sent it, where it’s going, etc.; this information isused by the messaging system and is mostly (but not always) ignored by theapplications using the messages. The body contains the data being trans-

mitted and is ignored by the messaging system. In conversation, when anapplication developer who is using messaging talks about a message, he’susually referring to the data in the body of the message.[1, p. 13]

Messaging capabilities are typically provided by a separate software sys-tem called a messaging system or message-oriented middleware (MOM). Amessaging system manages messaging the way a database system managesdata persistence. Just as an administrator must populate the database withthe schema for an application’s data, an administrator must configure themessaging system with the channels that define the paths of communica-tion between the applications. The messaging system then coordinates andmanages the sending and receiving of messages. The primary purpose of adatabase is to make sure each data record is safely persisted, and likewisethe main task of a messaging system is to move messages from the sender’scomputer to the receiver’s computer in a reliable fashion.

The reason a messaging system is needed to move messages from onecomputer to another is that computers and the networks that connect them

3



are inherently unreliable. Just because one application is ready to send a

communication does not mean that the other application is ready to receiveit. Even if both applications are ready, the network may not be working, ormay fail to transmit the data properly. A messaging system overcomes theselimitations by repeatedly trying to transmit the message until it succeeds.Under ideal circumstances, the message is transmitted successfully on thefirst try, but circumstances are often not ideal. [1, p. 14]

In essence, a message is transmitted in five steps:

1. Create - The sender creates the message and populates it with data.

2. Send - The sender adds the message to a channel.

3. Deliver - The messaging system moves the message from the sender’scomputer to the receiver’s computer, making it available to the re-ceiver.

4. Receive - The receiver reads the message from the channel.

5. Process - The receiver extracts the data from the message.

1.2 Broking

A Message Broker takes care of all connections between the applica-tions in an organisation. One connection is created between each systemand Message Broker, and messages transported via this bi-directional con-nection can be translated, filtered, archived, modified and routed to theirfinal destination(s).

The transport of messages can be based on one of many transport proto-cols supported by the broker (e.g. TCP/IP, files). The Message Broker takescare of translations between the data formats used by the various systems.All commonly used message formats are supported in the base product (e.g.HL7, EDIFACT, XML, delimited formats, SAP/HCM, flat records).

The use of a Message Broker offers a scalable platform that has access todata sent by many applications in the organisation, it improves the reliabilityand accessibility of data and it concentrates all available message flows in onepoint. Because of the fact that the message broker processes all messages,

a copy of the data contained in the messages can easily be forwarded toanalytical, management database or other applications. Creating a focalpoint for data thus adds to the quality of care, the integration of data, andthe central management of the connections.

4



By using Message Broker as a strategic solution for all integration re-

quirements the maintenance costs of point-to-point connections are signifi-cantly lowered and new connections can be created at little costs using theorganisation’s own resources. [3]

1.3 Decoupling

Loose Coupling There is considerable interest in loose coupling in dis-tributed systems, particularly in the web services community. The terminol-ogy is often ill-defined and imprecise, though. In the context of web services,loose coupling refers to minimizing the dependencies between services in or-der to have a flexible underlying architecture (reducing the risk that a changein one service will have a knock-on effect on other services). This is partially

supported by the intended independence of web services with the subsequentintention to produce combinations of web services as discussed above. Loosecoupling is, however, further enhanced by a number of additional features:[4,p. 385]

• Programming with interfaces provides one level of loose coupling byseparating the interface from its implementation (and also supports im-portant areas of heterogeneity, – for example in the choice of program-ming language and platform used). Programming with interfaces isadopted by most distributed systems paradigms including distributedobjects and components as well as web services.

• There is a trend towards simple, generic interfaces in distributed sys-tems and this is exemplified by the minimal interface offered by theWorld Wide Web and the REST approach in web services. This ap-proach contributes to loose coupling by reducing dependency on spe-cific operation names. One consequence of this is that data becomesmore important than operation, with the semantics of interoperationoften held in the data (for example, the associated XML documentdefinition in web services); this data-oriented view is discussed furtherin the context of mobile systems.

• As mentioned above, web services can be used with a variety of com-

munication paradigms, including request-reply communication, asyn-chronous messaging or indeed indirect communication paradigms. Thelevel of coupling is directly affected by this choice. For example, inrequest-reply communication, the two parties are intrinsically coupled;

5



asynchronous messaging offers a degree of decoupling, whereas indirect

communication also offers time and space uncoupling. [4, p. 386]

1.4 Developing directions

1.4.1 Message Translator (Messaging Systems)

In many cases, enterprise integration solutions route messages between exist-ing applications such as legacy systems, packaged applications, homegrowncustom applications, or applications operated by external partners. Each of these applications is usually built around a proprietary data model. Eachapplication may have a slightly different notion of the Customer entity , theattributes that define a Customer and which other entities a Customer is re-

lated to. For example, the accounting system may be more interested in thecustomer’s tax payer ID numbers while the customer-relationship manage-ment (CRM) system stores phone numbers and addresses. The application’sunderlying data model usually drives the design of the physical databaseschema, an interface file format or a programming interface (API) – thoseentities that an integration solution has to interface with. As a result, theapplications expect to receive messages that mimic the application’s internaldata format (see Figure 1).

Figure 1: Message Translator.

In addition to the proprietary data models and data formats incorpo-rated in the various applications, integration solutions often times interactwith standardized data formats that seek to be independent from specificapplications. There are a number of consortia and standards bodies that de-fine these protocols, such as RosettaNet, ebXML, OAGIS and many other,industry specific consortia. In many cases, the integration solution needs to

be able to communicate with external parties using the ‘official’ data formatswhile the internal systems are based on proprietary formats. [1, p. 96]

6



1.4.2 Publish-Subscribe Channel (Messaging Channels). Durable

Subscriber

A durable subscription saves messages for an inactive subscriber and deliveresthese saved messages when the subscriber reconnects. In this way, a sub-scriber will not loose any messages even though it disconnected. A durablesubscription has no effect on the behavior of the subscriber or the messagingsystem while the subscriber is active (e.g., connected). A connected sub-scriber acts the same whether its subscription is durable or non-durable.The difference is in how the messaging system behaves when the subscriberis disconnected.

A Durable Subscriber is simply a subscriber on a Publish-SubscribeChannel. However, when the subscriber disconnects from the messaging sys-

tem, it becomes inactive and the messaging system will save any messagespublished on its channel until it becomes active again. Meanwhile, othersubscribers to the same channel may not be durable; they’re non-durablesubscribers.

Figure 2: Publish-Subscribe Channel.

To be a subscriber, the Durable Subscriber must establish its subscrip-tion to the channel. Once it has, when it closes its connection, it becomesinactive. While the subscriber is inactive, the publisher publishes a mes-

sage. If the subscriber were non-durable, it would miss this message; butbecause it is durable, the messaging system saves this message for this sub-scriber. When the subscriber resubscribes, becoming active once more, themessaging system delivers the queued message (and any others saved for thissubscriber). The subscriber receives the message and process it (perhaps

7



delegating the message to the application). Once the subscriber is through

processing messages, if it does not wish to receive any more messages, itcloses its connection, becoming inactive again. Since it does not want themessaging system to save messages for it anymore, it also unsubscribes.[1,p. 467]

1.4.3 Content-Based Router (Message Routing)

The Content-Based Router examines the message content and routes themessage onto a different channel based on data contained in the message.The routing can be based on a number of criteria such as existence of fields,specific field values etc. When implementing a Content-Based Router, specialcaution should be taken to make the routing function easy to maintain as the

router can become a point of frequent maintenance. In more sophisticatedintegration scenarios, the Content-Based Router can take on the form of aconfigurable rules engine that computes the destination channel based on aset of configurable rules (see Figure 3).

Figure 3: Content Based Routing.

8



2 Description of personal solution

2.1 Steps of elaboration of the application

In order to decouple the application, there must be created a common in-terface for the reading/writing files and for sending and receiving messagesthrough the communication network. This interface is IAsyncIO. This in-terface must be implemented by the FileIO and NetworkIO classes. Theseclasses will implement all the logic behind reading, writing from files or forsending, receiving through the network. Thus, the calling classes must notbe aware of the implementation.

For the implementation I have chosen the Java 1.8 programming lan-guage and Java Development Kit 8 (link for JDK 8).

One of the ways to realize the decoupling in Java is to move the specificcomponent into a separate jar library and to include it at the compilationof the sourse code. Therefore, our FileIO and NetworkIO, altogether withIAsyncIO is moved to a separate jar library.

For realizing the Object Oriented Programming approach, the Message,Parameter and other helping entities were also moved toa diferent packageand compiled in a separate library. The purpose of the enumerated entitieswill be specified later on.

Other components of our system are the App and Broker classes. Theseare the core classes of our application which perform the logic and providethe system’s main functionalites. Each of these classes is a standalone entity.

2.2 Functionalities

The main purpose of the application is to realize the sending of messagesthrough a network using UDP or TCP protocol. For this implementation waschosen the UDP protocol, athough the message delivery is not quaranteed.The message delivery confirmation is performed by sending a confirmationmessage back to the sender entity from the receiving entity.

Another functionality is to read a file from the local storage, load itscontent into the body of the message process it accordingly inside the system.It was chosen to read and interpret the XML file format.

XML is a file extension for an Extensible Markup Language (XML)

file format used to create common information formats and share both theformat and the data on the World Wide Web, intranets, and elsewhere usingstandard ASCII text. XML describes the content in terms of what data isbeing described. For example, the word "phonenum" placed within markuptags could indicate that the data that followed was a phone number. An XML

9

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html



file can be processed purely as data by a program or it can be stored with

similar data on another computer or it can be displayed, like an HTML file.For example, depending on how the application in the receiving computerwanted to handle the phone number, it could be stored, displayed, or dialed.The full format specifications can be read in the IEEE publication from 2007,at ARFTG Conference, 69th (link to the file)

Inside the broker application, the data from the XML format is convertedto JSON format and stored inside a JSON file for later utilization.

JSON (JavaScript Object Notation) is a lightweight data-interchangeformat. It is easy for humans to read and write. It is easy for machines toparse and generate. It is based on a subset of the JavaScript ProgrammingLanguage, Standard ECMA-262 3rd Edition - December 1999. JSON is a

text format that is completely language independent but uses conventionsthat are familiar to programmers of the C-family of languages, including C,C++, C#, Java, JavaScript, Perl, Python, and many others. These proper-ties make JSON an ideal data-interchange language. [5]

JSON is built on two structures:

• A collection of name/value pairs. In various languages, this is real-ized as an object , record, struct, dictionary, hash table, keyed list, orassociative array.

• An ordered list of values. In most languages, this is realized as anarray , vector, list, or sequence.

Another important functionality is to perform all the IO operation asyn-chronously. These means that reading from file (for example) must be per-formed in the same time with the writing into the file or in the same timewith receiving a message one the network side. Thus, one IO operation mustnot block the flow of the rest of the logic of the program. The reason why thismust be done is because of the speedup of the performance. IO operationsare usually the slowest operations in a computational system. The imple-mentation of the asynchronism is performed using Java Threads altogetherwith custom anonymous classes implementing Callable Java Interface.

In the case of Threads , they will run continuosly until the end of theprocess. It was created a thread for each of the application entities: lis-

tener(network), sender(network), writer(file), reader(file). This is valid forApp class. Regarding Broker class, there were used threads for running twotypes of entities: Producer and Consumer.

As we have a shared resourse (in our case these are messages which mustbe received and sent later on), there appears the Producer-Consmer problem

10

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5456319&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5456319

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5456319&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5456319



while implementing it asynchronously. In order to solutionate this problem,

there must be used a lock on the requested resource, or to use the thread-safedatatypes which the programming language offers.

Regarding the current implementation, for communication between threadswas used the BlockingQueue Java class. This is a thread-safe class, whosemethods are atomic (cannot be intrerupted until the operation is completedand resourse unlocked). Moreover, in order to avoid the exceptions of theblocked resourse, this class has two specific methods for putting and retriev-ing from queue - they will wait until the resourse becomes again available.

In order to implement the XML to JSON convertion, it was used a thirtdparty library which can be integrating with Java 1.8. JSON-java libraryhttps://github.com/douglascrockford/JSON-java .

One more utility of the system is the subscribtion of the App

entitiesfor communication with Broker entity. Each entity, before sending a mes-sage, must send a subscribtion message to the public IP and port of theBroker entity. The Broker cannot send a message to an App which was notsubscribed.

In the case that the Broker is not responding and doesn’t process themessage, it must be provided a backup. For this purpose was implementetthe clone of the Broker which is ready to take its place. The new entityis named Replica . Replica sends periodically “ping” messages to Master .If the response is not received after a specific amount of time, this meansthat Master is down and Replica is changing its state to Master and startlistening to the messages comming from App entities. The problem which

occures is that the new Master cannot resend the messages until the Appentities don’t subscribe again. Moreover, the new Master cannot send asubscribtion request because it doesn’t know the addresses of the App.

For future implementation: App entity must resend subscribe messageperiodically or in the case that it doesn’t receive a MessageDelivered confir-mation from Broker .

2.3 Use cases

2.3.1 Scenarios

Using the system, the user is able to send a read the content of an XML

file, send it to a differents user through the network, receive a confirmationthat the message arrived, receive a message from a different user, store thecontent of the message in an XML file.

First scenario - read from file.

11

https://github.com/douglascrockford/JSON-java

https://github.com/douglascrockford/JSON-java



1. User selects the file which he wants to read.

2. User tries to open the file.

3. User tries to read the content of the file.

4. User closes the file.

Second scenario - send through the network.

1. User set the id of the receiver of the message.

2. User creates the message object.

3. User tries to send the message through the network connection.4. User receives a confirmation from the broker that the message was

delivered.

Third scenario - write into the file.

1. User save the body of the message he wants to save.

2. System tries to search the directory path specified by user.

3. System writes the content of the message into the file.

Alternate scenario 3, starting with step 2) through step 3).

3. If the path was not found, system creates the necessary directories forfulfilling the path specification.

12



2.4 Design and application architecture

2.4.1 Class Diagram

Figure 4: Class Diagram.

13



2.4.2 Component Diagram

Figure 5: Component Diagram.

3 Code

The code for realizing the Producer on the broker side:

1 p u bl i c c l a ss P r o d u c e r i m p l e m e n t s R u n n a b l e {2

3 p r i v a t e B l o c k i n g Q u e u e < M e s s a g e > q u e u e ;

4 p r i v at e i n t p o r t ;

5 p r i v at e b o o l ea n r e p l i c a ;

6 / / p r iv a te B l oc k in g Qu e ue < S u bs c ri b er > s u b sc r ib e rs = n ew

L i n k e d B l o c k i n g Q u e u e < S u b s c r i b e r > ( ) ;

7 // p ri va te E x ec ut or Se rv ic e e xe cu to r =

E x e c u t o r s . n e w C a c h e d T h r e a d P o o l ( ) ;

8

9 P r o d u ce r ( B l o c k i n g Q u e ue q , in t p o r t , b o o l e a n r e p l i c a ) {

10 q ue ue = q ;

11 this . p or t = p or t ;

12 this . r e pl i ca = r e pl i ca ;

13 }14

15 @ O v e r r i d e

16 p u b l ic v o i d r un ( ) {

17 / / l i st e n t o t he m e ss a ge s

18 N e tw o rk I O n e tR e ad = ne w N e t w o r k I O ( ) ;

14



19 n e t R e a d . s e t P o r t ( this . p o r t ) ;

20 I A sy n cI O f i le R ea d = ne w F i l e I O ( ) ;21

22 M e s s a ge m e s s ;

23

24 tr y {

25 w h i l e ( true ) {

26 m e ss = n e tR e ad . r e ad ( " l o c a l h o s t ") ;

27 if ( ! m e s s . g e t T y p e ( ) . e q u a l s (" c h a n g e _ p o r t ") ) {

28 q u e u e . p u t ( m e s s ) ;

29 } else {

30 this . p or t = 3 00 0;

31 n e t R e a d . s e t P o r t ( p o r t ) ;

32 }

33 }

34 } c a t c h ( I n t er r u pt e d Ex c e pt i o n e x ) {35 L o g g e r . g e t L o g g e r ( B r o k e r . c l a s s . g e t N a m e ( ) ) .

36 l o g ( L e v e l . S E V E R E , null , e x );

37 }

38 }

39 }

When the broker is created, it must be sent an optional parameter of boolean type which will define if the given broker is the main one or replica .The Producer class must implement the Runnable interface because it willbe put inside a new thread inside broker. A broker has mainly one Producer

and some Consumers. The purpose of the Producer is to listen for newmessages and to put them inside the shared BlockingQueue . The Consumer

will retrieve messages from the queue and will process them later on.Regarding the Consumer , one of the important steps is the registration

of the subscribtions. And here it is performed:

1 void s u b s c r ib e A p p ( S u b s c r i b t i o nP a r a m e t e r p a r a ms ) {

2

3 S t r i ng a p p N am e = p a r a ms . g e t A p p I D ( ) ;

4 S t ri n g i p = p a ra m s . g et I p () ;

5 in t p or t = p a r a ms . g e t P o r t ( ) ;

6

7 S u bs c ri b er r c vr = ne w S u b s c ri b e r ( a p p Na m e , p o rt , i p ) ;

8 tr y {

9 this . s u b s c r i b e r s . p u t ( r c v r ) ;

10 } c a t c h ( I n t er r u pt e d Ex c e pt i o n e x ) {

11 L o g g e r . g e t L o g g e r ( C o n s u m e r . c l a s s . g e t N a m e ( ) ) .12 l o g ( L e v e l . S E V E R E , null , e x );

13 }

14 }

15



For storing the subscribers it was used again a BlockingQueue<Subscriber>

- subscribers. This was done because of the concurent programming andthe problem of the shared resource between the Consumer threads. For cum-munication between the Producer and Consumer threads, it was used anotherBlockingQueue<Message> - queMessage.

The main utility of the Broker is to resend the message, and so it doesusing the following method:

1 s y n c hr o n i z e d v o i d s e nd M e s s a ge ( M e s s a g e m e ss , N e t w o rk I O n e t W r it e r ) {

2 S t ri n g t o = ( ( M e ss a g eP a r am e t er )

m e s s . g e t P a r a m s ( ) ) . g e t R e c e i v e r I D ( ) ;

3 I t e r a t o r < S u b s c r i b e r > i t = this . s u b s c r i b e r s . i t e r a t o r ( ) ;

4

5 if ( this . s u b s c r i b er s . i s E m p t y ( ) ) {

6 S y s t e m . o u t . p r i n t l n ( " T he s ub s q i s e mp ty " ) ;7 }

8

9 w h i l e ( i t . h a s Ne x t ( ) ) {

10 S u bs c r ib e r s ub = i t . ne xt ( ) ;

11 S y s t e m . o u t . p r i n t l n ( s u b . n a m e ) ;

12 if ( t o . e q u al s ( s u b . n a m e ) ) {

13 n e t W r i t e r . s e t P o r t ( s u b . p o r t ) ;

14 n e t W r it e r . w r i t e ( to , m e s s ) ;

15 S y s t e m . o u t . p r i n t l n ( " R e s en d in g t he m e ss a ge t o " +

t o ) ;

16 r e t u r n ;

17 }

18 }

1920 / / s av e t he m es sa ge i nt o a f il e

21 S y s t e m . o u t . p r i n t l n ( " T h e r e ce i ve r w a snt f o un d . ") ;

22 }

Another problem which may be encountered is the undelivered messages.In order to track those messages, the messages are stored inside some files,apriori transforming the XML content to JSON format. We will store all theinformation inside the MessageFile class. And so, there will be created acollection of these objects. Another thread on the Broker side will periodi-cally check the status of the objects from this collection and will delete thedelivered files, thus remaining only the undelivered ones.

1 Me s s a g eF i l e m e s s F il e = ne w M e s s a g e F i l e ( ) ;

2 M e s s F il e . s e t P a r a m s ( m e s s P ar a m ) ;

3 m e s s F il e . s e t D e l i v e r ed ( f a l s e ) ;

4

5 f i n a l S t r in g f i le P at h = " s r c / b r o k e r / " + m e s s P ar a m . g e t S e n d e r ID ( )

6 + " _ " + m e ss P ar a m . g et M es s ID ( ) + " . j s o n " ;

16



7

8 M e ss a ge c o py M es s a ge = m e ss a ge ;9 S t ri n g b o dy = m e ss a ge . g e t Bo d y () ;

10

11 tr y {

12 J S O N O bj e c t x m l J S ON O b j = XM L . t o J S O N O b je c t ( b o d y ) ;

13 b o d y = x m l J SO N O b j . t o S t r in g ( 4 ) ;

14 / / S y s t em . o u t . p r i n t l n ( b o dy ) ;

15 } c a t c h ( J S O N Ex c e pt i o n j e ) {

16 S y s t e m . o u t . p r i n t l n ( j e . t o S t r i n g ( ) ) ;

17 }

18

19 c o p y M es s a g e . s e t B o dy ( b o d y ) ;

20 f i n a l M e ss a g e f i n a l M es s a g e = c o p y M e ss a g e ;

21

22 C a l l a b l e < V o i d > c a l l a b l e ;23 c a ll a bl e = ne w C a l l a b l e < V o i d > ( ) {

24

25 @ O v e r r i d e

26 p u b l i c V o id c a l l ( ) t h r o w s E x c e p ti o n {

27

28 f i l e W ri t e . w r i t e ( f i l eP a t h , f i n a l Me s s a g e ) ;

29 r e t u rn n u l l;

30

31 }

32 };

33

34 F u t ur e < V o id > f u t u r eF i l e = f i l e W r it e r . s u b m i t ( c a l l ab l e ) ;

35

36 m e s s F il e . s e t F i l e P a th ( f i l e P a t h ) ;37 m e s s F il e . s e t F i l e W r i te ( f u t u r e F i l e ) ;

The rest of the code can be accessed by the repository link on github:https://github.com/ViSilver/Message-Broker .

17

https://github.com/ViSilver/Message-Broker





4 Conslusion

Performing the given laboratory work I was able to implement a simpleMessage Broker. I got acustomed with UDP Protocol and the basics of the messaging communication systems. Following the task description, Iwas able to build a system which consists of different components that maybe changed in future by their new implementations. The system is lowcoupled, which means that the interdependecies between the component wasreduced. The system in the end is scalable, which means that the number of senders and receivers may grow. The system is fault tolerant because thereis a backup Broker in the case that the first one fails. This feature has abig advantage because in this manner we can grow the performance of ourapplication. Another feature of scalability is by increasing the number of consumers. Thus, if the messages will become hard to process, or it willtake too much time, the number of consumers can be grown to increase theperformance. This application may be used for sending data between two ormore entities.

18



References

[1] Gregor Hohpe, Bobby Woolf, Enterprise Integration Patterns. Design-

ing, Building and Deploying Messaging Sollutions , 2012.

[2] Andrew S. Tanenbaum, Prentice Hall, Computer Networks , 1999.

[3] René Spronk - Sr.Consultant, Ringholm bv, The role of Message Bro-

kers: a management overview , October 2003.

[4] George Coulouris, Jean Dollimore, im Kindberg, Gordon Blair, DIS-

TRIBUTED SYSTEMS. Concepts and Design , Fifth Edition, 2012.

[5] http://www.json.org/

19

message broker programming of distributed applications

Documents