NMany object-based distributed syst

N
Many object-based distributed systems follow a traditional approach toward
replicated objects, effectively treating them as containers of data with their own
special operations. As a result, when we consider how replication is handled in
systems supporting Java beans, or CORBA-compliant distributed systems, there is
not really that much new to report other than what we have discussed in Chap. 7.
For this reason, we focus on a few particular topics regarding consistency and
replication that are more profound in object-based distributed systems than others.
We will first consider consistency and move to replicated invocations.
10.6.1 Entry Consistency
As we mentioned in Chap. 7, data-centric consistency for distributed objects
comes naturally in the form of entry consistency. Recall that in this case, the goal
is to group operations on shared data using synchronization variables (e.g., in the
form of locks). As objects naturally combine data and the operations on that data,
locking objects during an invocation serializes access and keeps them consistent.
Although conceptually associating a lock with an object is simple, it does not
necessarily 'provide a proper solution when an object is replicated. There are two
issues that need to be solved for implementing entry consistency. The first one is
that we need a means to prevent concurrent execution of'multiple invocations on
the same object. In other words, when any method of an object is being executed,
no other methods may be executed. This requirement ensures that access to the
internal data of an object is indeed serialized. Simply using local locking mechan-
isms will ensure this serialization.
The second issue is that in the case of a replicated object, we need to ensure
that all changes to the replicated state of the object are the same. In other words,
we need to make sure that no two independent method invocations take place on
different replicas at the same time. This requirement implies that we need to order
invocations such that each replica sees all invocations in the same order. This
SEC. 10.6 CONSISTENCY AND REPLICATION 473
requirement can generally be met in one of two ways: (1) using a primary-based
approach or (2) using totally-ordered multicast to the replicas.
In many cases, designing replicated objects is done by first designing a single
object, possibly protecting it against concurrent access through local locking, and
subsequently replicating it. If we were to use a primary-based scheme, then addi-
tional effort from the application developer is needed to serialize object invoca-
tions. Therefore, it is often convenient to assume that the underlying middleware
supports totally-ordered multicasting, as this would not require any changes at the
clients, nor would it require additional programming effort from application
developers. Of course, how the totally ordered multicasting is realized by the
middleware should be transparent. For all the application may know its imple-
mentation may use a primary-based scheme, but it could equally well be based on
Lamport clocks.
However, even if the underlying middleware provides totally-ordered multi-
casting, more may be needed to guarantee orderly object invocation. The problem
is one of granularity: although all replicas of an object server may receive invoca-
tion requests in the same order, we need to ensure that all threads in those servers
process those requests in the correct order as well. The problem is sketched in
Fig. 10-15.
Figure to-IS. Deterministic thread scheduling for replicated object servers.
Multithreaded (object) servers simply pick up an incoming request, pass it on
to an available thread, and wait for the next request to come in. The server's
thread scheduler subsequently allocates the CPU to runnable threads. Of course, if
the middleware has done its best to provide a total ordering for request delivery,
the thread schedulers should operate in a deterministic fashion in order not to mix
the ordering of method invocations on the same object. In other words, If threads
474 DISTRIBUTED OBJECT-BASED SYSTEMS CHAP. 10
rl and rT from Fig. 10-15 handle the same incoming (replicated) invocation re-
quest, they should both be scheduled before r~and r~,respectively.
Of course, simply scheduling all threads deterministically is not necessary. In
principle, if we already have totally-ordered request delivery, we need only to
ensure that all requests for the same replicated object are handled in the order they
were delivered. Such an approach would allow invocations for different objects to
be processed concurrently, and without further restrictions from the thread sched-
uler. Unfortunately, only few systems exist that support such concurrency.
One approach, described in Basile et aI. (2002), ensures that threads sharing
the same (local) lock are scheduled in the same order on every replica. At the
basics lies a primary-based scheme in which one of the replica servers takes the
lead in determining, for a specific lock, which thread goes first. An improvement
that avoids frequent communication between servers is described in Basile et al.
(2003). Note that threads that do not share a lock can thus operate concurrently on
each server.
One drawback of this scheme is that it operates at the level of the underlying
operating system, meaning that every lock needs to be managed. By providing ap-
plication-level information, a huge improvement in performance can be made by
identifying only those locks that are needed for serializing access to replicated ob-
jects (Taiani et aI., 2005). We return to these issues when we discuss fault toler-
ance for Java.
Replication Frameworks
An interesting aspect of most distributed object-based systems is that by
nature of the object technology it is often possible to make a clean separation be-
tween devising functionality and handling extra-functional issues such as replica-
tion. As we explained in Chap. 2, a powerful mechanism to accomplish this
separation is formed by interceptors.
Babaoglu et al. (2004) describe a framework in which they use interceptors to
replicate Java beans for J2EE servers. The idea is relatively simple: invocations to
objects are intercepted at three different points, as also shown in Fig. 10-16:
1. At the client side just before the invocation is passed to the stub.
2. Inside the client's stub, where the interception forms part of the
replication algorithm.
3. At the server side, just before the object is about to be invoked.
The first interception is needed when it turns out that the caller is replicated.
In that case, synchronization with the other callers may be needed as we may be
dealing with a replicated invocation as discussed before.
SEC. 10.6 CONSISTENCY AND REPLICATION 475
Figure 10-16. A general framework for separating replication algorithms from
objects in an EJB environment.
Once it has been decided that the invocation can be carried out, the intercep-
tor in the client-side stub can take decisions on where to be forward the request to,
or possibly implement a fail-over mechanism when a replica cannot be reached.
Finally, the server-side interceptor handles the invocation. In fact, this inter-
ceptor is split into two. At the first point, just after the request has come in and be-
fore it is handed over to an adapter, the replication algorithm gets control. It can
then analyze for whom the request is intended allowing it to activate, if necessary,
any replication objects that it needs to carry out the replication. The second point
is just before the invocation, allowing the replication algorithm to, for example,
get and set attribute values of the replicated object.
The interesting aspect is that the framework can be set up independent of any
replication algorithm, thus leading to a complete separation of object functionality
and replication of objects.
10.6.2 Replicated Invocations
Another problem that needs to be solved is that of replicated invocations.
Consider an object A calling another object B as shown in Fig. 10-17. Object B is
assumed to call yet another object C. If B is replicated, each replica of B will, in
principle, call C independently. The problem is that C is now called multiple
times instead of only once. If the called method on C results in the transfer of
$100,000, then clearly, someone is going to complain sooner or later.
There are not many general-purpose solutions to solve the problem of repli-
cated invocations. One solution is to simply forbid it (Maassen et aI., 2001),
which makes sense when performance is at stake. However, when replicating for
fault tolerance, the following solution proposed by Mazouni et ale (1995) may be
deployed. Their solution is independent of the replication policy, that is, the exact
details of how replicas are kept consistent. The essence is to provide a replica-
tion-aware communication layer on top of which (replicated) objects execute.
When a replicated object B invokes another replicated object C, the invocation
476 DISTRIBUTED OBJECT-BASED SYSTEMS CHAP. 10
Figure 10-17. The problem of replicated method invocations.
request is first assigned the same, unique identifier by each replica of B. At that
point, a coordinator of the replicas of B forwards its request to all the replicas of
object C, while the other replicas of B hold back their copy of the invocation re-
quest, as shown in Fig. lO-18(a). The result is that only a single request is for-
warded to each replica of C.
Figure 10-18. (a) Forwarding an invocation request from a replicated object to
another replicated object. (b) Returning a reply from one replicated object to an-
other.
The same mechanism is used to ensure that only a single reply message is re-
turned to the replicas of B. This situation is shown in Fig. lO-18(b). A coordinator
SEC. 10.6 CONSISTENCY AND REPLICATION 477
of the replicas of C notices it is dealing with a replicated reply message that has
been generated by each replica of C.

Kết quả (Việt) 1:

NNhiều đối tượng dựa trên hệ thống phân phối thực hiện theo một cách tiếp cận truyền thống về hướngsao chép các đối tượng, có hiệu quả điều trị cho họ như thùng chứa dữ liệu với mìnhhoạt động đặc biệt. Kết quả là, khi chúng tôi xem xét như thế nào sao chép được xử lý trongHệ thống hỗ trợ Java đậu, hoặc CORBA tương thích hệ thống phân phối, cókhông thực sự mà nhiều mới để báo cáo khác hơn so với những gì chúng tôi đã thảo luận trong chap 7.Vì lý do này, chúng tôi tập trung vào một số các chủ đề cụ thể liên quan đến tính nhất quán vànhân rộng hơn sâu sắc trong đối tượng dựa trên phân phối các hệ thống hơn những người khác.Đầu tiên, chúng tôi sẽ xem xét tính nhất quán và di chuyển để sao chép invocations.10.6.1 mục nhất quánNhư chúng tôi đã đề cập trong chap 7, thống nhất Trung tâm dữ liệu cho các đối tượng phân phốiđến tự nhiên ở dạng mục nhập nhất quán. Nhớ lại rằng trong trường hợp này, mục tiêulà để nhóm hoạt động trên dữ liệu được chia sẻ bằng cách sử dụng đồng bộ hóa biến (ví dụ, trong cáchình thức của ổ khóa). Như các đối tượng tự nhiên kết hợp dữ liệu và các hoạt động trên dữ liệu đó,khóa các đối tượng trong một invocation công truy cập và giữ cho họ phù hợp.Mặc dù khái niệm kết hợp một khóa với một đối tượng là đơn giản, nó khôngnhất thiết phải ' cung cấp một giải pháp thích hợp khi một đối tượng được nhân rộng. Có haivấn đề cần được giải quyết cho việc thực hiện mục nhập nhất quán. Người đầu tiên làrằng chúng ta cần một phương tiện để ngăn chặn đồng thời thực hiện of'multiple invocations trêncác đối tượng tương tự. Nói cách khác, khi bất kỳ phương pháp của một đối tượng đang được thực thi,no other methods may be executed. This requirement ensures that access to theinternal data of an object is indeed serialized. Simply using local locking mechan-isms will ensure this serialization.The second issue is that in the case of a replicated object, we need to ensurethat all changes to the replicated state of the object are the same. In other words,we need to make sure that no two independent method invocations take place ondifferent replicas at the same time. This requirement implies that we need to orderinvocations such that each replica sees all invocations in the same order. ThisSEC. 10.6 CONSISTENCY AND REPLICATION 473requirement can generally be met in one of two ways: (1) using a primary-basedapproach or (2) using totally-ordered multicast to the replicas.In many cases, designing replicated objects is done by first designing a singleobject, possibly protecting it against concurrent access through local locking, andsubsequently replicating it. If we were to use a primary-based scheme, then addi-tional effort from the application developer is needed to serialize object invoca-tions. Therefore, it is often convenient to assume that the underlying middlewaresupports totally-ordered multicasting, as this would not require any changes at theclients, nor would it require additional programming effort from applicationdevelopers. Of course, how the totally ordered multicasting is realized by themiddleware should be transparent. For all the application may know its imple-mentation may use a primary-based scheme, but it could equally well be based onLamport clocks.However, even if the underlying middleware provides totally-ordered multi-casting, more may be needed to guarantee orderly object invocation. The problemis one of granularity: although all replicas of an object server may receive invoca-tion requests in the same order, we need to ensure that all threads in those serversprocess those requests in the correct order as well. The problem is sketched inFig. 10-15.Figure to-IS. Deterministic thread scheduling for replicated object servers.Multithreaded (object) servers simply pick up an incoming request, pass it onto an available thread, and wait for the next request to come in. The server'sthread scheduler subsequently allocates the CPU to runnable threads. Of course, ifthe middleware has done its best to provide a total ordering for request delivery,the thread schedulers should operate in a deterministic fashion in order not to mixthe ordering of method invocations on the same object. In other words, If threads474 DISTRIBUTED OBJECT-BASED SYSTEMS CHAP. 10rl and rT from Fig. 10-15 handle the same incoming (replicated) invocation re-quest, they should both be scheduled before r~and r~,respectively.Of course, simply scheduling all threads deterministically is not necessary. Inprinciple, if we already have totally-ordered request delivery, we need only toensure that all requests for the same replicated object are handled in the order theywere delivered. Such an approach would allow invocations for different objects tobe processed concurrently, and without further restrictions from the thread sched-uler. Unfortunately, only few systems exist that support such concurrency.One approach, described in Basile et aI. (2002), ensures that threads sharingthe same (local) lock are scheduled in the same order on every replica. At thebasics lies a primary-based scheme in which one of the replica servers takes thelead in determining, for a specific lock, which thread goes first. An improvementthat avoids frequent communication between servers is described in Basile et al.(2003). Note that threads that do not share a lock can thus operate concurrently oneach server.One drawback of this scheme is that it operates at the level of the underlyingoperating system, meaning that every lock needs to be managed. By providing ap-plication-level information, a huge improvement in performance can be made byidentifying only those locks that are needed for serializing access to replicated ob-jects (Taiani et aI., 2005). We return to these issues when we discuss fault toler-ance for Java.Replication FrameworksAn interesting aspect of most distributed object-based systems is that bynature of the object technology it is often possible to make a clean separation be-tween devising functionality and handling extra-functional issues such as replica-tion. As we explained in Chap. 2, a powerful mechanism to accomplish thisseparation is formed by interceptors.Babaoglu et al. (2004) describe a framework in which they use interceptors toreplicate Java beans for J2EE servers. The idea is relatively simple: invocations toobjects are intercepted at three different points, as also shown in Fig. 10-16:1. At the client side just before the invocation is passed to the stub.2. Inside the client's stub, where the interception forms part of thereplication algorithm.3. At the server side, just before the object is about to be invoked.The first interception is needed when it turns out that the caller is replicated.In that case, synchronization with the other callers may be needed as we may bedealing with a replicated invocation as discussed before.SEC. 10.6 CONSISTENCY AND REPLICATION 475Figure 10-16. A general framework for separating replication algorithms fromobjects in an EJB environment.Once it has been decided that the invocation can be carried out, the intercep-tor in the client-side stub can take decisions on where to be forward the request to,or possibly implement a fail-over mechanism when a replica cannot be reached.Finally, the server-side interceptor handles the invocation. In fact, this inter-ceptor is split into two. At the first point, just after the request has come in and be-
fore it is handed over to an adapter, the replication algorithm gets control. It can
then analyze for whom the request is intended allowing it to activate, if necessary,
any replication objects that it needs to carry out the replication. The second point
is just before the invocation, allowing the replication algorithm to, for example,
get and set attribute values of the replicated object.
The interesting aspect is that the framework can be set up independent of any
replication algorithm, thus leading to a complete separation of object functionality
and replication of objects.
10.6.2 Replicated Invocations
Another problem that needs to be solved is that of replicated invocations.
Consider an object A calling another object B as shown in Fig. 10-17. Object B is
assumed to call yet another object C. If B is replicated, each replica of B will, in
principle, call C independently. The problem is that C is now called multiple
times instead of only once. If the called method on C results in the transfer of
$100,000, then clearly, someone is going to complain sooner or later.
There are not many general-purpose solutions to solve the problem of repli-
cated invocations. One solution is to simply forbid it (Maassen et aI., 2001),
which makes sense when performance is at stake. However, when replicating for
fault tolerance, the following solution proposed by Mazouni et ale (1995) may be
deployed. Their solution is independent of the replication policy, that is, the exact
details of how replicas are kept consistent. The essence is to provide a replica-
tion-aware communication layer on top of which (replicated) objects execute.
When a replicated object B invokes another replicated object C, the invocation
476 DISTRIBUTED OBJECT-BASED SYSTEMS CHAP. 10
Figure 10-17. The problem of replicated method invocations.
request is first assigned the same, unique identifier by each replica of B. At that
point, a coordinator of the replicas of B forwards its request to all the replicas of
object C, while the other replicas of B hold back their copy of the invocation re-
quest, as shown in Fig. lO-18(a). The result is that only a single request is for-
warded to each replica of C.
Figure 10-18. (a) Forwarding an invocation request from a replicated object to
another replicated object. (b) Returning a reply from one replicated object to an-
other.
The same mechanism is used to ensure that only a single reply message is re-
turned to the replicas of B. This situation is shown in Fig. lO-18(b). A coordinator
SEC. 10.6 CONSISTENCY AND REPLICATION 477
of the replicas of C notices it is dealing with a replicated reply message that has
been generated by each replica of C.

Kết quả (Việt) 2:

N
Nhiều hệ thống phân phối dựa trên đối tượng theo một cách tiếp cận truyền thống đối với
các đối tượng nhân rộng, đối xử với họ một cách hiệu quả là các thùng chứa dữ liệu riêng của họ với
hoạt động đặc biệt. Kết quả là, khi chúng ta xem xét như thế nào sao chép được xử lý trong
hệ thống hỗ trợ đậu Java, hoặc các hệ thống phân phối CORBA-compliant, có
không thực sự nhiều mới để báo cáo khác so với những gì chúng ta đã thảo luận ở Chương. 7.
Vì lý do này, chúng tôi tập trung vào một số chủ đề cụ thể liên quan đến tính nhất quán và
nhân rộng được sâu sắc hơn trong các hệ thống phân phối dựa trên đối tượng hơn so với những người khác.
Đầu tiên chúng ta sẽ xem xét tính nhất quán và di chuyển đến các viện dẫn nhân rộng.
10.6.1 nhập quán
Như chúng tôi đã đề cập trong Chap. 7, tính nhất quán dữ liệu tập trung cho các đối tượng được phân phối
một cách tự nhiên trong các hình thức nhất quán mục. Nhớ lại rằng trong trường hợp này, mục tiêu
là để hoạt động nhóm trên dữ liệu được chia sẻ sử dụng các biến đồng bộ hóa (ví dụ, trong các
hình thức của ổ khóa). Khi các đối tượng tự nhiên kết hợp dữ liệu và các hoạt động trên dữ liệu đó,
khóa các đối tượng trong một lời gọi tuần tự truy cập và giữ chúng phù hợp.
Mặc dù khái niệm gắn một khóa với một đối tượng là đơn giản, nó không
nhất thiết phải 'cung cấp một giải pháp thích hợp khi một đối tượng được nhân rộng. Có hai
vấn đề cần được giải quyết để thực hiện nhất quán mục. Người đầu tiên là
chúng ta cần một phương tiện để ngăn chặn thực hiện đồng thời of'multiple lời gọi trên
cùng một đối tượng. Nói cách khác, khi bất kỳ phương thức của một đối tượng đang được thực hiện,
không có phương pháp khác có thể được thực thi. Yêu cầu này đảm bảo rằng quyền truy cập vào
dữ liệu nội bộ của một đối tượng thực sự là tuần tự. Đơn giản chỉ cần sử dụng khóa cơ học địa phương
chủ nghĩa sẽ đảm bảo serialization này.
Vấn đề thứ hai là trong trường hợp của một đối tượng nhân rộng, chúng ta cần phải đảm bảo
rằng tất cả các thay đổi đối với nhà nước nhân rộng các đối tượng đều giống nhau. Nói cách khác,
chúng ta cần phải chắc chắn rằng không có hai lời gọi phương pháp độc lập diễn ra trên
bản sao khác nhau cùng một lúc. Yêu cầu này có nghĩa là chúng ta cần phải đặt
lời gọi như vậy mà mỗi bản sao thấy tất cả triệu gọi theo thứ tự. Đây
SEC. 10,6 Nhất quán và nhân rộng 473
yêu cầu nói chung có thể đáp ứng được một trong hai cách sau: (1) sử dụng một chính dựa
trên. Cách tiếp cận hoặc (2) sử dụng multicast hoàn toàn ra lệnh cho các bản sao
Trong nhiều trường hợp, việc thiết kế các đối tượng nhân rộng được thực hiện bằng cách thiết kế đầu tiên một đơn
đối tượng, có thể bảo vệ chống lại truy cập đồng thời thông qua các khóa địa phương, và
sau đó sao chép nó. Nếu chúng ta sử dụng một chương trình tiểu học có trụ sở, sau đó bổ sung thì các
nỗ lực quốc từ các nhà phát triển ứng dụng là cần thiết để serialize đối tượng invoca-
tions. Vì vậy, nó là thường thuận tiện để giả định rằng các middleware cơ bản
hỗ trợ multicasting hoàn toàn ra lệnh, vì điều này sẽ không đòi hỏi bất kỳ thay đổi ở
các khách hàng, và cũng không nó sẽ đòi hỏi nỗ lực lập trình ứng dụng bổ sung từ
các nhà phát triển. Tất nhiên, làm thế nào multicasting hoàn toàn lệnh được thực hiện bởi các
trung gian cần phải minh bạch. Đối với tất cả các ứng dụng có thể biết imple- của
việc triển có thể sử dụng một chương trình tiểu học có trụ sở, nhưng nó có thể tốt như nhau căn cứ vào
đồng hồ Lamport.
Tuy nhiên, ngay cả khi các middleware cơ bản cung cấp hoàn toàn theo lệnh đa
đúc, hơn có thể cần thiết để đảm bảo trật tự đối tượng gọi. Vấn đề
là một trong những granularity: mặc dù tất cả các bản sao của một máy chủ vật thể có thể nhận invoca-
yêu cầu tion trong cùng một thứ tự, chúng ta cần phải đảm bảo rằng tất cả các chủ đề trong các máy chủ
xử lý những yêu cầu theo thứ tự đúng là tốt. Vấn đề được phác họa trong
hình. 10-15.
Hình to-IS. Xác định lịch trình thread cho server đối tượng nhân rộng.
Multithreaded (object) các máy chủ chỉ đơn giản là lấy một request đến, vượt qua nó trên
cho một chủ đề có sẵn, và chờ đợi cho các yêu cầu tiếp theo đi vào. Các máy chủ
bai Scheduler sau đó phân bổ CPU để đề Runnable. Tất nhiên, nếu
các trung gian đã làm hết sức mình để cung cấp một tổng số đặt hàng để giao hàng theo yêu cầu,
các schedulers thread phải hoạt động trong một thời trang xác định để không trộn
các đặt hàng của lời gọi phương thức trên cùng một đối tượng. Nói cách khác, nếu chủ đề
474 CUNG CẤP VẬT DỰA TRÊN HỆ THỐNG CHAP. 10
rl và rT từ hình. 10-15 xử lý giống nhau đến (nhân rộng) gọi lại
quest, họ nên cả hai được lên kế hoạch trước khi r ~ và r ~, tương ứng.
Tất nhiên, chỉ cần lên lịch tất cả các chủ đề deterministically là không cần thiết. Trong
nguyên tắc, nếu chúng ta đã đã hoàn toàn đặt hàng giao hàng yêu cầu, chúng tôi chỉ cần
đảm bảo rằng tất cả các yêu cầu cho các đối tượng nhân rộng giống được xử lý theo thứ tự chúng
đã được chuyển giao. Cách tiếp cận này sẽ cho phép các viện dẫn cho các đối tượng khác nhau để
được xử lý đồng thời, và không có hạn chế nào từ sched- đề
uler. Thật không may, chỉ có vài hệ thống tồn tại mà hỗ trợ đồng thời như vậy.
Một cách tiếp cận, được mô tả trong Basile et AI. (2002), đảm bảo rằng các chủ đề chia sẻ
cùng (địa phương) khóa được lên kế hoạch trong cùng một thứ tự trên mỗi bản sao. Tại các
vấn đề cơ bản nằm một chương trình tiểu học có trụ sở trong đó một trong các máy chủ sao có những
chính trong việc xác định, cho một khóa cụ thể, mà thread đi đầu tiên. Một cải tiến
mà tránh giao tiếp thường xuyên giữa các máy chủ được mô tả trong Basile et al.
(2003). Lưu ý rằng các chủ đề mà không chia sẻ một khóa do đó có thể hoạt động đồng thời trên
mỗi máy chủ.
Một nhược điểm của hệ thống này là nó hoạt động ở mức độ cơ bản
của hệ điều hành, có nghĩa là mỗi khóa cần được quản lý. Bằng cách cung cấp cận
thông tin quăn cấp, một cải tiến lớn trong hiệu suất có thể được thực hiện bằng
việc xác định chỉ những ổ khóa đó là cần thiết cho việc tuần tự truy cập để quan sát nhân rộng
jects (Taiani et ai., 2005). Chúng tôi trở về những vấn đề này khi chúng ta thảo luận về lỗi dung nạp
ance cho Java.
Replication Frameworks
Một khía cạnh thú vị của các hệ thống dựa trên đối tượng phân phối nhất là bởi
bản chất của công nghệ đối tượng nó thường có thể làm cho một tách sạch được-
tween chức năng quan xây dựng và xử lý vấn đề thêm chức năng như nhân bản
tion. Như chúng tôi đã giải thích trong Chap. 2, một cơ chế mạnh mẽ để thực hiện việc này
tách được hình thành bởi hệ thống đánh chặn.
Babaoglu et al. (2004) mô tả một khuôn khổ trong đó họ sử dụng tên lửa đánh chặn để
nhân rộng đậu Java cho các máy chủ J2EE. Ý tưởng là tương đối đơn giản: các viện dẫn tới
các đối tượng được chặn ở ba điểm khác nhau, cũng như thể hiện trong hình. 10-16:
1. Ở phía khách hàng chỉ cần gọi trước khi được thông qua để còn sơ khai.
2. Bên trong còn sơ khai của khách hàng, nơi đánh chặn là một phần của
thuật toán nhân rộng.
3. Ở phía máy chủ, ngay trước khi các đối tượng là về để được gọi.
Các đánh chặn đầu tiên là cần thiết khi nó chỉ ra rằng những người gọi là nhân rộng.
Trong trường hợp đó, đồng bộ hóa với các người gọi khác có thể cần thiết khi chúng ta có thể bị
đối phó với một nhân rộng gọi là thảo luận trước.
SEC. 10,6 Nhất quán và nhân rộng 475
Hình 10-16. Một khuôn khổ chung để tách các thuật toán nhân rộng từ
đối tượng trong một môi trường EJB.
Một khi nó đã được quyết định rằng cách gọi có thể được thực hiện, các intercep-
tor ở gốc phía máy khách có thể đưa ra quyết định về nơi để được chuyển tiếp yêu cầu đến,
hoặc có thể thực hiện một cơ chế không-hơn khi một bản sao không thể đạt được.
Cuối cùng, các máy bay đánh chặn phía máy chủ xử lý các thỉnh nguyện. Trong thực tế, liên này
ceptor được chia làm hai. Tại điểm đầu tiên, chỉ sau khi yêu cầu đã đi vào và được-
fore nó được bàn giao cho một bộ chuyển đổi, các thuật toán nhân rộng được kiểm soát. Nó có thể
sau đó phân tích cho người yêu cầu đang có ý định cho phép nó để kích hoạt, nếu cần thiết,
bất kỳ nhân rộng các đối tượng mà nó cần phải thực hiện việc sao chép. Điểm thứ hai
là ngay trước khi gọi, cho phép các thuật toán nhân rộng, ví dụ,
nhận và thiết lập các giá trị thuộc tính của đối tượng nhân rộng.
Các khía cạnh thú vị là khung có thể được thiết lập độc lập của bất kỳ
thuật toán nhân rộng, dẫn đến một cách đầy đủ tách chức năng đối tượng
và nhân rộng các đối tượng.
10.6.2 nhân rộng các viện dẫn
Một vấn đề khác cần được giải quyết là các lời gọi được sao.
Hãy xem xét một đối tượng A gọi một đối tượng B như hình. 10-17. Đối tượng B được
giả định gọi thêm một đối tượng C. Nếu B được tái bản, mỗi bản sao của B sẽ, trong
nguyên tắc, gọi C một cách độc lập. Vấn đề là C bây giờ được gọi là nhiều
lần thay vì chỉ một lần. Nếu gọi là phương pháp trên kết quả C trong việc chuyển giao của
$ 100,000, thì rõ ràng, người nào đó sẽ phàn nàn sớm hay muộn.
Không có nhiều giải pháp có mục đích chung để giải quyết các vấn đề của repli-
invocations tạp. Một giải pháp là chỉ đơn giản là cấm nó (Maassen et ai., 2001),
trong đó có ý nghĩa khi thực hiện đang bị đe dọa. Tuy nhiên, khi nhân rộng cho
khả năng chịu lỗi, các giải pháp sau bằng Mazouni et ale (1995) đề xuất có thể được
triển khai. Giải pháp của họ là độc lập với chính sách nhân bản, đó là, chính xác
thông tin chi tiết về cách thức bản sao được lưu giữ phù hợp. Bản chất là để cung cấp cho một nhân bản
layer truyền thông tion-aware trên đầu trang trong đó các đối tượng (nhân rộng) thực hiện.
Khi một đối tượng nhân rộng B gọi một đối tượng C nhân rộng, việc gọi
476 CUNG CẤP VẬT DỰA TRÊN HỆ THỐNG CHAP. 10
Hình 10-17. Các vấn đề của lời gọi phương pháp tạo bản sao.
Yêu cầu đầu tiên được giao cho cùng, định danh duy nhất của mỗi bản sao của B. Lúc đó
điểm, một điều phối viên của các bản sao của B chuyển tiếp yêu cầu đến tất cả các bản sao của
đối tượng C, trong khi các bản sao khác của B giữ lại bản sao của họ về lại gọi
quest, như thể hiện trong hình. LO-18 (một). Kết quả là chỉ có một yêu cầu duy nhất là cho-
ngăn chặn, để mỗi bản sao của C.
Hình 10-18. (a) Gửi một yêu cầu gọi từ một đối tượng được sao chép tới
một đối tượng nhân rộng. (b) Trả lại một trả lời từ một đối tượng nhân rộng để An-
khác.
Các cơ chế tương tự được sử dụng để đảm bảo rằng chỉ có một tin nhắn trả lời duy nhất là lại
quay sang các bản sao của B. Tình hình này được hiển thị trong hình. LO-18 (b). Một điều phối viên
SEC. 10,6 Nhất quán và nhân rộng 477
trong các bản sao của C thông báo nó đang đối phó với một tin nhắn trả lời được sao mà đã
được tạo ra bởi mỗi bản sao của C.