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

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:

主站蜘蛛池模板: 扎兰屯市| 商都县| 洛浦县| 德昌县| 那曲县| 台南市| 织金县| 佛学| 怀安县| 长宁区| 临沧市| 武陟县| 娄烦县| 安国市| 华蓥市| 长海县| 托克逊县| 枣强县| 阜新市| 手机| 苍溪县| 蒙城县| 讷河市| 鄂伦春自治旗| 壶关县| 涞源县| 辉县市| 彝良县| 望城县| 宜州市| 株洲县| 昌黎县| 利津县| 临邑县| 宝兴县| 盐城市| 南召县| 阜城县| 临桂县| SHOW| 罗源县|