官术网_书友最值得收藏!

The classic Business Delegate pattern scenario

In a classic Business Delegate pattern scenario, the implementation of the Business Delegate pattern receives a request from a Java client and sends the response back to it. In addition, to minimize the coupling between the presentation tier and the business tier, it was the responsibility of a delegate to locate remote services (in most cases, a remote EJB service) and provide a caching mechanism for accessing business services to reduce the network traffic.

So, when EJB was used as a remote service in the past, Business Delegate patterns were used with another pattern, the Service Locator Pattern, which is responsible for locating the remote (and local) EJB. Also, the stub (a kind of EJB reference based on the RMI (Remote Method Invocation) protocol) of the remote EJB is cached by the delegate.

The following diagram shows the class diagram for the Business Delegate pattern. This represents the basic structure of this pattern. The client sends requests to the Business Delegate, which in turn accesses the correct business service. The Business Delegate can use a service locator in the case of a remote service lookup:

As the Business Delegate re-passes the business request to the Business Service, one natural approach in code development is to make both classes (Business Delegate and Business Service) implement the same business interface.

This is shown in the following diagram:

In the following diagram, we show the sequence diagram for the Business Delegate pattern:

主站蜘蛛池模板: 财经| 澎湖县| 马龙县| 鄂托克旗| 莲花县| 卓尼县| 霸州市| 银川市| 武宁县| 红河县| 郓城县| 泾川县| 三亚市| 洛宁县| 曲靖市| 新宾| 平武县| 柳江县| 大宁县| 镇远县| 山西省| 固镇县| 睢宁县| 连云港市| 抚顺县| 庐江县| 凤庆县| 肃南| 黎城县| 濉溪县| 怀安县| 九龙坡区| 寻甸| 鄱阳县| 衡水市| 宝应县| 凌云县| 开化县| 南川市| 太原市| 防城港市|