Middleware interoperability performance using interoperable reinforcement learning technique for enterprise business applications

Abstract

Business level service can be implemented by middleware in enterprise systems to improve interoperability and also provides the transparent implementation of client and server process. To improve the performance of Business to Business (B2B) and Business to Consumer (B2C) in terms of enterprise-wide Service Oriented Architecture (SOA), we need to have middleware interoperability especially with representative engineering namely Common Object Request Broker Architecture (CORBA) proposed by Object Management Group, Object Request Broker (ORB) software named ORBeline is available as CORBA complaint. Distinctive models for client-server communications have already been developed and executed in particular Handle Driven ORB (H-ORB), Forwarding ORB (F-ORB), Process Planner ORB (P-ORB), and the Adaptive ORB (A-ORB). This paper focuses how to improve the performance of the interoperability in Process Planner ORB (P-ORB) with respect to client-server interaction in N-tier architecture along with multithreading environment.

Keywords

Interoperability multithreading remote procedure call CORBA object request broker

1 Introduction

Various dispersed frameworks utilize client server standard and two types of entities, Clients and Servers are available. Clients requesting information from the server and the servers providing service requested. The fast arrangement of distributed computing object is the most imperative necessity of information exchange across the world today in enterprises level business [12, 26]. Since service is a major software component it’s been well defined, structured and it does not always depend on the other context or services [15]. These days, service-oriented architecture (SOA) is utilized as a successful and effective answer for coordinate the dispersed applications in enterprise business application frameworks [4]. It promises to generate the interoperability, reusability, loose coupling, and convention independency of administrations as center standards of SOA [28]. The two important approaches used to deploy client server interaction in disseminated processing are Remote Procedure Call (RPC) and system codification for Application Programming Interface (API) [1]. Middleware, a product tier connecting program and the working framework, was presented to make it easier to design and implement client-server frameworks in a heterogeneity condition [8]. The System makes interoperability possible with different items utilizing either or both of the accompanying two methodologies:

Utilization of published interface standards.

Administrations that could change over single item’s node to a further item’s node utilizing broker architecture.

Here the principal approach is the arrangement of models that have been produced for the Internet. These gauges will incorporate the TCP/IP, Hypertext Transfer Protocol, and HTML Standards [13]. The subsequent methodology for interoperability is implemented by the Common Object Request Broker Architecture (CORBA) and its Object Request Broker (ORB) [9].

This paper fixates on the interoperable system CORBA-based middleware performance systems. The following are the contributions to this research. We are proposing another design for Process Planner (P-ORB), which gives the better interoperability performance. The exploration introduces an execution of prototype based correlation of three diverse client-agent-server structures particularly P-ORB that can be sent by an ORB with multitasking environment [9]. This paper examines the system performance in different parameters of workload. Some of the key observations are summarized and analyzed briefly. The overall execution of the other designs based on framework loading at lower system and higher system are discussed [2]. The Process Planner Architecture performs superior to anything the Handle-Driven and Forwarding Architecture, which shows a predominant and effective execution at high load (maximum number of client and server) [16]. We have introduced a method called interoperable reinforcement learning technique and how it tends to be utilized for enhancing the performance of interoperability is discussed [19]. The result provides the system behavior particularly the effect of message measure, inter-node delays, dormancy and adaptability of request/response service times for the P-ORB architecture are analyzed [11].

2 Test condition

The distributed applications framework utilized present exploration is pleasing to CORBA ORB. CORBA is a conventional object-oriented application framework specification it offers interoperability in heterogeneity domain in enterprise level [27, 28]. This client-server collaborations in a CORBA framework are intermediated (Broker) by an extraordinary kind of substance named the Object Request Broker (ORB) based on recommendations given in [2]. CORBA provides a range of services for client and server side software developers and users [3]. The client and server generated an object called stub (object created by the client machine) each of which is an interface to the authentic object on the server, are generated from IDL. The server stub is constantly alluded as a skeleton (object created by the server machine). The skeleton code is utilized on the server, while the stub code is utilized on the client [4]. we have examined the three distinct structures named Handle Driven ORB, Forwarding ORB, and Process Planner ORB in view of ORBeline item created by Postmodern Technologies [23, 24]. Experiments were performed on P-ORB architecture using multithreading environment by running the heterogeneous system network of 8 systems (workstations), and each connected together with a CPU.

2.1 Limitations of H-ORB

Whenever there is a need for service, client executes an imperative operation among agent returning grasp to the requested server (server one or server two or server N). The client sends the demand utilizing the handle and server restores the outcomes to client. Here client is holding up till the point that the reaction is gotten by the server. The client always binds to the current agent, although in the previous execution it called the same server. Each server moves into a loop waiting for client demands, runs on the CPU (on demand) for certain period of time and sends back to the response [11]. This in turn increases the time limits to complete the process. Execution time of the server is replicated as a continuous process, because to find the time span of the workload to test the particularization. Information’s are usually a series of a certain count of bytes. To interact with any server, the H-ORB requires four messages: The initial two gives correspondence among H-ORB agent, client and other dual results against the client- server correspondence [5].

2.2 Drawbacks of F-ORB

Here, add up to number of messages per server is not as much as H-ORB. The client sends the entire administration asks for clearly to the F-ORB agent (f-agent), and afterward enrolls with the default operator without anyone else. The f- agent process separates the name of the current administration asked for from the message list, gets the handle of the coveted server (in this case, further server one or server two or server N) and direct to the suitable server. The server plays out the service requested and restores the outcomes to the client straightforwardly [11]. F-ORB requires 3 messages per execution of the server. A message for solicitations among the client, F- ORB agent, and a message among the agent, server and the relating server reaction.

2.3 Execution of P-ORB

The P-ORB simultaneously invokes two or more servers. The client directs a complex demand all administration calls and individual limitations. The process planner (p-agent) combines every single demand from the compound request and always decides its individual relationship of precedence. If the servers are executed simultaneously, the p-agent gets the handle of every server from the default agent and sends a demand to every server [11]. In this paper we expect that the object precedence hold one or more self-supporting (client) demands and one or more servers [26]. All server requests can therefore be executed simultaneously with a multi- threaded agent. Every server has its very own individual dispatcher (FIFO queuing process) at a similar node to keep away from deadlocks and the message is entered in the dispatcher of each server. After the execution of the server side, every server sends its response to the multi- threaded agent. The multithreaded-agent joins the outcomes and returns a solitary answer (response) to the client machine. To achieve this, we have proposed reinforcement learning technique to improve the performance of interoperability in Process Planner ORB (P-ORB) with respect to the client-server interaction in N-tier architecture along with multithreading environment.

3 Proposed method

Reinforcement Learning Technique:

The output of the system determined by the collection (sequence) of actions.

If the action is good, it is because of good policy.

Since policy is important rather than single action.

Here, Learner is a decision-making agent in multithreading environment.

The accompanying engineering outline (Fig. 1) shows how the client server interaction considered in multithreading environment alongside various threaded pools for coordinate the various frameworks.

Fig. 1

Architecture Diagram.

3.1 Proposed algorithm

Interoperable Reinforcement Learning Algorithm:

Initialize m_i i = 1 ... k, for example, to k random x^t Repeat

For all x^t ∈ N $b_{i}^{t} \leftarrow {\begin{matrix} 1 if | | x^{t} - m_{i} | | = \min_{j} | | x^{t} - m_{j} | | \\ 0 otherwise \end{matrix}$ $b_{i}^{t}$ depends on m_i since the best reference vectors are those that minimize the total reconstruction error.

For all m_i i = 1,..., k $m_{i} \leftarrow \sum_{t} b_{i}^{t} x^{t} / \sum_{t} b_{i}^{t}$

The mean of all data can be calculated and small random vectors added to the mean to get the k initial m_i and divide its range into k equal intervals for partitioning the data into k groups.

Q(a) ← value of action a

Initialize For all Q(a) = 0

For all episodes m_i

Initialize Q(a) =r_a

Choose a^* if Q (a^*) = maxQ(a). m_i

Q_t (a)← Take action a t time t

Q_t+1 (a)← Q_t (a) + η [r_t+1 (a) - Q_t (a)]/delta rule [21]

The amount of reward is defined by the probability distribution p (r|a).

Until t + 1 converges to the mean of p(r|a)

Until m_i converge.

Substitute here,

η→ Learning factor (gradually decreased in time for convergence)

r_t+1 → Desired Output

Q_t (a)→ Current Prediction

Q_t+1 (a)→ Expected value of action a at time t + 1

K → Reference vector

x^t → Individual instance (object) of client and server

N → Total number of client and server machine

m_i → Request and Responses of individual machine(client and server)

$b_{i}^{t}$ → Best reference outcome (vector)

$r_{a}^{mj}$ → Successful Iteration (reward)

3.2 Implementation method

In multithreading environment, we assume that instances of a class are linearly separable from instances of other classes. Based on the outcome of the interoperable reinforcement learning algorithm [19], Let us now generalize to k > 2 classes.

We can take any one of the classes.

For example, c_k as the reference class [22] and assume that,

log $\frac{P (x | C_{i})}{P (x | C_{k})} = w_{i}^{T} x$ $w_{io}^{o}$

Then we have, $\frac{P (C_{i} | x)}{P (C_{k} | x)} = \exp [w_{i}^{T} x + w_{io}]$

With $w_{io} = w_{io}^{o} + log P (c_{i}) / P (c_{k})$

To calculate all the instances, $\begin{matrix} \sum_{i = 1}^{k - 1} \frac{P (C_{i} | x)}{P (C_{k} | x)} \frac{1 - P (C_{k} | x)}{P (C_{k} | x)} & = \sum_{i = 1}^{k - 1} exp [w_{i}^{T} x + w_{io}] = P (c_{k} | x) \\ = \frac{1}{1 + \sum_{i = 1}^{k - 1} \exp [w_{i}^{T} x + w_{io}]} \end{matrix}$ and also that, $\begin{matrix} \frac{P (C_{i} | x)}{P (C_{k} | x)} & = exp [w_{i}^{T} x + w_{io}] = P (c_{i} + x) \\ = \frac{\exp [w_{i}^{T} x + w_{io}]}{\sum_{j = 1}^{k} \exp [w_{j}^{T} x + w_{jo}]} \end{matrix}$ where i = 1, ... k

which is called the SoftMax function [20]. Here, sum for one instance larger than others, after boosted through exponentiation and normalization. Its corresponding y_i will be close to 1 and the others will be close to 0.

SoftMax also guarantees that ∑_iy_i = 1

This information we have due to the output’s estimating class posterior probabilities.

Let us see how we can learn the parameters,

In this case of k > 2 classes, each instance from multithreaded code, that is, $r^{t} (x^{t} \sim {Mult}_{k} (1, y^{t})), {wherey}_{i}^{t} \equiv P (c_{i} | x^{t})$

So, the sample likelihood is, $l ({w_{i}, w_{io}}_{i} | x) = \prod_{t} \prod_{i} (y_{i}^{t})^{r_{i}^{t}}$ and the Exception (Error Function) is again cross-entropy: $E ({w_{i}, w_{io}}_{i} | x) = - \sum_{t} \sum_{i} r_{i}^{t} log y_{i}^{t}$

Now, use the gradient -descent again,

If y_i = exp(a_i)/∑_jexp(a_j)

We have $\frac{\partial y_{i}}{\partial a_{j}} = y_{i (δ_{ij} - y_{j})}$

Where δ_ij is the kronecker delta

If i = j ; then 1

i ≠ j ; then 0

Given that $\sum_{i} r_{i}^{t} = 1$ we have the following update equations for all the instances (both client and server), for j = 1, ... k $\begin{matrix} Δ_{w_{j}} & = η \sum_{t} \sum_{i} \frac{r_{i}^{t}}{y_{i}^{t}} y_{i}^{t} (δ_{ij} - y_{j}^{t}) x^{t} \\ = η \sum_{t} [\sum_{i} r_{i}^{t} δ_{ij} - y_{j}^{t} \sum_{i} r_{i}^{t}] x^{t} \\ = η \sum_{t} (r_{j}^{t} - y_{j}^{t}) x^{t} \\ Δ_{w_{jo}} & = η \sum_{t} (r_{j}^{t} - y_{j}^{t}) \end{matrix}$

Normalization in SoftMax determined by $x^{t} \in c_{j} and x^{t} \in c_{i}, i \neq j$

The discriminants are updated so that the correct class has the highest weighted sum after softmax and the other classes have their weighted sums as low as possible. So the Performance of the instances will be improved with respect to interoperability.

4 Benefits of CORBA

CORBA (Common Object Request Broker Architecture) is default architecture for executing the enterprise level applications in distributed system objects. It allows a heterogeneous and distributed collection of objects to interoperate and communicate with one another. Object Request Broker (ORB), which allows objects to adopt perfectly and make them to receive the requests and responses in a different environment [29, 30]. The importance of middleware based on CORBA for network management is taken into account in [10]. The combination of load offsetting with naming service is discussed in [12]. The execution of the CORBA- based aggregate participation protocol is examined in [13]. Execution issues of CORBA fault tolerant systems are considered in [14]. The Internet Inter- ORB Protocol (IIOP) communicates with the server and client ORBs [6]. The IIOP ensures that CORBA-based applications can interoperate across computer architectures, operating systems, programming languages and ORB vendors [4]. It simplifies the execution of distributed applications through automating and encapsulating of dynamic scheduling, object location, (de)marshaling, connection & memory management, and exception handling [17].

4.1 Multi threaded ORB’s

In a multi threaded ORB, execution are performed concurrently. Multithreading ORBs to handle multiple clients and servers effectively and efficiently are discussed in [9]. This is an added advantage for programmer to allow the multiple ORBs that supports the threads in a portable manner across those ORBs. It is achieved by, object can ensure the serialization when needed by fixing the right thread policies mechanisms by itself [7]. The thread pool objects encapsulates to managing the group of all threads concurrently. Each thread pool is responsible for exactly one object execution. It provides the responsibility of thread creation, activation and termination [25].

5 Experimental results

In our proposed technique we have implemented multithreaded agents instead of process cloning (Fig. 1). It is suitable for comparative abnormal state examination of the association designs between client and multithreading agent and server that this paper focuses on. In the previous section, the P- ORB architecture for client- multithreading agent- server cooperation’s along with H- ORB and F- ORB was described. We have directed various tests to think about the P-ORB execution with different workloads. Based on our research, this paper presents collective experimental outcomes and you can find more data in [5]. The workload in these environments is controlled by four aspects: total number of clients (N), inter node communication delay (D), request service times (S1, S2) and message size (L). Preliminary results on H- ORB, F- ORB and P- ORB’s relative execution can be found in [16].

Performance Measurement:

Performance measurement calculated in seconds on the basis of a mean client response time (R): This variable measures the latency of the system.

The comprehensive system throughput (X) per second in client requests: This variable measures the capacity of the system together with the throughput and response time by little law (N = XR).

System and CPU uses (U): This variable used to improve the system execution and the identification of hardware and software difficulties (bottlenecks).

As long as we can increase TP (Throughput) without increasing RT (Response Time), there is no bottleneck. At the same time both TP and RT will start to increase while we continue to increase the load. This indication shows that we have hit a bottleneck. This situation can be avoided by make use of the multithreading agent.

5.1 Experiment 1: Utilization of message size

The quantity of message (in terms of bytes) increments the marshaling/unmarshalling beyond the message additionally increments relatively. Table 1 and Fig. 2, 3 shows the relative execution of the three structures.

Table 1
Impact of latency and scalability (delay = 200 ms, S1, S2 = 10, 20 ms, with multithreading)

L S₁, S₂ Existing System Proposed P-ORB

(Bytes) (ms) H-ORB F-ORB P-ORB

Response Time (sec) Throughput Response Time (sec) Throughput Response Time (sec) Throughput Response Time (sec) Throughput

when when when when when when when when

N = 1 N = 24 N = 1 N = 24 N = 1 N = 24 N = 1 N = 24

4800 10, 20 1.72 7.73 1.31 2.86 0.90 1.85 0.83 1.81

9600 55, 75 1.74 7.45 1.34 2.59 0.90 1.79 0.85 1.75

19200 275, 400 1.79 6.86 1.41 2.43 0.91 1.75 0.88 1.71

L	S₁, S₂	Existing System	Proposed P-ORB
4800	10, 20	1.72	7.73	1.31	2.86	0.90	1.85	0.83	1.81
9600	55, 75	1.74	7.45	1.34	2.59	0.90	1.79	0.85	1.75
19200	275, 400	1.79	6.86	1.41	2.43	0.91	1.75	0.88	1.71

Fig. 2

D = 250 ms, L = 4800 bytes, S1 = 10 ms, S2 = 20 ms Level of Multithreading = 4.

Fig. 3

D = 250 ms, L = 4800 bytes, S1 = 10 ms, S2 = 20 ms Level of Multithreading = 8.

Low Load Level:

Based on Table 1, P- ORB shows the perfect latency for all L values pursued by the F- ORB and H- ORB. But P- ORB shows a littler latency since simultaneousness execution together in servers and clients because of multithreading agent in the P-ORB architecture. They’re being invoked sequentially for the two other architectures namely H-ORB and F-ORB.

Comparisons of Medium and High Load:

The performance of different N values for the three different structures is shown in Fig. 2 for the value of L = 4800. An execution bottleneck is a hardware tool or programming processes that ceiling system throughput development. In an environment client- server systems have bottlenecks [15, 18] because of contemporary attributes of the send-wait-reply method used in the client-server communication.

As demonstrated in the Fig. 3 server side operations are used vigorously with hidden CPU usage of less than 10percent. The process of the P-ORB agent (multithreading) demonstrates a 40 percent usage in examination. Both the agent of P-ORB procedure (multithreading) and the server action stay for a message to be sent.

For the three different architectures, the impact of the message size on the most extreme throughput observed in N = 24 is also shown in the Table 1. There was a significant improvement in the PORB’s throughput when multithreading increased from 1 to 4, 8 and 24.

5.2 Experiment 2: Effect of server requests

This experimental set is structured to calculate the P- ORB architecture relative execution as the estimation call for each request per server increases below the number of variable (Maximum N) of p-agents.

Low level of load:

The latency observed at N = 1 to N = 24 for the various server calculation time value is shown in Table 2. For each (S1, S2) combination value of P-ORB generates the littlest reaction time along with D and L. The difference between the performances is increases with (S1, S2) increase. Because small sizes of messages and inter node communication delay in the response time of a solitary client are decided fundamentally by server calculation time and dual servers (multithreading agent) simultaneously. Because of concurrent response the P-ORB framework illustrates greatest execution.

Table 2
Impact of latency and scalability (delay = 10 ms, L = 150 bytes, with multithreading)

S₁, S₂ D Existing System Proposed P-ORB

(ms) (ms) H-ORB F-ORB P-ORB

Response Time (sec) Throughput (Client Request/sec) Response Time (sec) Throughput (Client Request/sec) Response Time (sec) Throughput (Client Request/sec) Response Time (sec) Throughput (Client Request/sec)

when when when when when when when when

N = 1 N = 24 N = 1 N = 24 N = 1 N = 24 N = 1 N = 24

10, 20 350 0.17 46.14 0.18 15.15 0.17 12.92 0.16 12.85

55, 75 500 0.28 16.11 0.25 11.87 0.19 11.42 0.18 11.30

275, 400 1000 0.82 4.02 0.95 2.70 0.52 4.10 0.43 4.01

S₁, S₂	D	Existing System	Proposed P-ORB
10, 20	350	0.17	46.14	0.18	15.15	0.17	12.92	0.16	12.85
55, 75	500	0.28	16.11	0.25	11.87	0.19	11.42	0.18	11.30
275, 400	1000	0.82	4.02	0.95	2.70	0.52	4.10	0.43	4.01

Average to Peak load level:

When S1 and S2 increase, the effect of server demand begins to dominate along with the client response time for P- ORB framework and it reduces the bottleneck because of multithreading agent generated by thread pool.

Consequently, the difference in performance of N = 24 begins to decrease (shown in Table 2). P- ORB’s performance is improved by the integration of multithreading agent. The effect of multithreading agent appears to have just a backhanded impact on the execution of P-ORB. It should be noted that with multiple multithreading agent activity, the stand by time for the client and the servers returning outcomes is reduced.

When (S1, S2) = (275,400) both servers are very much used, which improves the performance of the P- ORB architectures. Subsequently, the performance is improved on account of P-ORB (Fig. 4). Since the P-ORB that utilizes parallelism in execution of server concurrently and deliver an unrivaled execution compared with other architecture.

Fig. 4

D = 15 ms, L = 250 bytes, S1 = 10 ms, s2 = 20 ms Level of Multithreading = 2.

The P- ORB architecture system throughput decreases with higher demand for servers. With server calculation times increasing, servers begin to dominate system performance.

5.3 Experiment 3: Performance of delay between nodes

Low level of load:

Delay between nodes is the main factor in this analyzes and is shown in a Fig. 5 close to direct connection among D and response time for N = 1(shown in Table 3). The H-ORB executes the majority messages per client series and the most exceedingly awful latency produces N = 1. Even if the P- ORB utilizes the identical amount of messages and the performance is still superior to F- ORB and H- ORB due to the overlap between the two servers it produces.

Fig. 5

D = 15 ms, L = 250 bytes, S1 = 10 ms, s2 = 20 ms Level of Multithreading = 4.

Table 3

Impact of latency and scalability (L = 250 bytes, S₁, S₂ = 10, 20 ms, with multithreading)

D	L	Existing System						Proposed P-ORB
(ms)	(Bytes)	H-ORB		F-ORB		P-ORB
		Response Time (sec)	Throughput (Client Request/sec)	Response Time (sec)	Throughput (Client Request/sec)	Response Time (sec)	Throughput (Client Request/sec)	Response Time (sec)	Throughput (Client Request/sec)
		when	when	when	when	when	when	when	when
		N = 1	N = 24	N = 1	N = 24	N = 1	N = 24	N = 1	N = 24
350	4800	2.09	6.35	1.59	2.17	1.09	1.46	1.02	1.41
500	9600	4.09	3.31	3.09	1.12	2.09	0.82	2.04	0.76
1000	19200	8.09	1.74	6.09	0.57	4.09	0.39	4.01	0.35

Average to Peak load level:

The comparative achievements of the P- ORB architecture in accordance with N are shown in the Fig. 6 with a different architecture. As demonstrated in the Fig. 6, the P- ORB executes greatest pursued by F- ORB and H- ORB at lower values and higher values of N and when multithreading agent is used. Performance of the P-ORB improved with multithreading agent process (see Fig. 7). The quantity of multithreading agent process increases, the bottlenecking result of the software is decreased and the P- ORB performs superior to the F- ORB and H- ORB.

Fig. 6

D = 350 ms, L = 250 bytes, S1 = 10 ms, s2 = 20 ms Level of Multithreading = 2.

Fig. 7

D = 350 ms, L = 250 bytes, S1 = 10 ms, s2 = 20 ms Level of Multithreading = 4.

6 Conclusion

On the basis of ORBeline, we have executed the interoperable reinforcement learning technique for P-ORB with client-server interaction. Our research demonstrates that, without changing an actual source code, it is conceivable to adopt more creative models for client-server execution. It will improve the interoperability performance under various workload conditions in a multithreading environment. In view of our experiment with multithreading agent, P- ORB seems to deliver the effective performance in N- tier architecture. When compare with H-ORB and F-ORB, the P-ORB appears to be the finest decision for all dimensions.

References

Abdul-Fatah

and Majumdar

, The Effect of Object-Agent Interactions on the Performance of CORBA Systems, Proc IEEE International Conference on Performance, Computing, and Communication (Cat. No.98CH36191), (1998), 67–74, DOI: 10.1109/PCCC.1998.659903

Adler

, Distributed Coordination Models for Client/ Server Computing, IEEE Computer (1995), 14–22, DOI: 10.1109/2.375173.

Object Management Group, The Common Object Request Broker: Architecture and Specification, 2.3 ed., (2000).

Sathis Kumar

, Middleware Interoperability using SOA for Enterprise Business Application, International Journal of Computer Science Trends and Technology (2015), 140–144.

Abdul-Fatah

, Performance of CORBA-Based Client-Server Architectures, MEng. thesis, Carleton Univ, Ottawa, Canada, (1997).

Buecker

, et al. Understanding SOA Security:Design and implementation, IBM Publication, USA (2007).

Schultz

, Multi threading in a CORBA ORB, Otto-von-Guericke University Magdeburg, (2001).

Schmidt

D.C.

and Vinoski

, Modeling Distributed Object Applications, C++ Report, (1995).

Schmidt

D.C.

, Evaluating Architectures for Multithreaded CORBA Object Request Brokers, Comm ACM (1998), 54–60, DOI: 10.1145/286238.286248.

10.

Haggerty

and Seetharaman

, The Benefits of CORBA in Network Management, Comm, ACM (1998), 73–79.

11.

Abdul-Fatah

and Majumdar

, Performance of CORBA-Based Client-Server Architectures, Parallel and DistributedSystems (2002), 111–127, DOI: 10.1109/71.983940.

12.

Barth

, Flender

, Freisleben

and Thilo

, Load Distribution in a CORBA Environment, Proc Int’l Symp. Distributed Objects and Applications (DOA ’99), (1999).

13.

Mishra

and Liu

, Design, Implementation and Performance Evaluation of a High Performance CORBA Group Membership Protocol, Proc Seventh Int’l Conf High Performance Computing (2000), 121–130.

14.

Natarajan

, Gokhale

, Yajnik

and Schmidt

D.C.

, Applying Patterns to Improve the Performance of Fault-Tolerant CORBA, Proc Seventh Int’l Conf High Performance Computing, ACM/IEEE (2000), 107–120.

15.

Neilson

J.E.

, Woodside

C.M.

, Petriu

D.C.

and Majumdar

, Software Bottlenecking in Client-Server Systems and Rendezvous Networks, IEEE Trans Software Eng (1995), 776–782, DOI: 10.1109/32.464543.

16.

Schmidt

D.C.

, Levine

D.L.

and Cleeland

, Architectures and Patterns for High-Performance, Real-Time CORBA Object Request Brokers, Advances in Computers, M. Zelkowitz, ed., Academic Press, (1998).

17.

Henning

and Vinoski

, Advanced CORBA Programming with C++ Reading, Mass Addison Wesley Longman, (1999).

18.

Fontenot

M.J.

, Software Congestion, Mobile Servers, and the Hyperbolic Model, IEEE Transactions on Software Engineering (1989), 947–962, DOI: 10.1109/32.31352.

19.

Kaelbling

L.P.

, Littman

M.L.

and Moore

A.W.

, Reinforcement Learning: A Survey, Journal of Artificial Intelligence Research 4 (1996), 237–285, DOI: 10.1613/jair.301.

20.

Bridle

J.S.

, Probabilistic Interpretation of Feed forward Classification Network Outputs, with Relationships to Statistical Pattern Recognition, Neurocomputing—Algorithms, Architectures and Applications, F. Fogelman-Soulie and J. Herault, eds., NATO ASI Series F68, Berlin: Springer-Verlag, (1989), 227–236.

21.

Alpaydin

, Soft Vector Quantization and the EM Algorithm, Neural Networks, Elsevier (1998), 467–477, DOI: 10.1016/S0893-6080(97)00147-0.

22.

Bellman

, Dynamic Programming, Princeton University Press, N. J. (1957).

23.

Post Modern Computing Technologies Inc., ORBeline Reference-Guide, Mountain View, C.A., (1994).

24.

Post Modern Computing Technologies Inc., ORBeline User’s Guide, Mountain View, Calif., (1994).

25.

Schmidt

D.C.

and Vinoski

, Comparing Alternative Programming Techniques for Multi-Threaded Servers, SIGS C++ Report, (1996).

26.

Majumdar

, Performance comparison of architectures for client-server interactions in CORBA, Proceedings 18th International Conference on Distributed Computing Systems (Cat No 98CB36183) ICDCS-98, (1998), DOI: 10.1109/ICDCS.1998.679464

27.

Cabral

and Grilo

, Impact of Business Interoperability on the Performance of Complex Cooperative Supply Chain Networks: A Case Study, Complexity, John Wiley and Sons, (2018), DOI:10.1155/2018/9213237

28.

Mazayev

, Martins

Jaime A.

and Correia

, Interoperability in IoT Through the Semantic Profiling of Objects, IEEE Access (2018), DOI: 10.1109/ACCESS.2017.2763425

29.

https://carleton.ca/sce

30.

https://searchmicroservices.techtarget.com