ejbconcepts6.html

j2eePDF格式的电子书

<a name="wp80060"> </a><h3 class="pHeading2">
Deciding on Remote or Local Access
</h3>
<a name="wp80061"> </a><p class="pBody">
The decision regarding whether to allow local or remote access depends on the following factors.
</p>
<a name="wp80062"> </a><p class="pBody">
<b class="cBold">Container-managed relationships</b>: If an entity bean is the target of a container-managed relationship, it must use local access.
</p>
<a name="wp80063"> </a><p class="pBody">
<b class="cBold">Tight or loose coupling of related beans</b>: Tightly coupled beans depend on one another. For example, a completed sales order must have one or more line items, which cannot exist without the order to which they belong. The <code class="cCode">OrderEJB</code> and <code class="cCode">LineItemEJB</code> entity beans that model this relationship are tightly coupled. Tightly coupled beans are good candidates for local access. Since they fit together as a logical unit, they probably call each other often and would benefit from the increased performance that is possible with local access.
</p>
<a name="wp80064"> </a><p class="pBody">
<b class="cBold">Type of client</b>: If an enterprise bean is accessed by J2EE application clients, then it should allow remote access. In a production environment, these clients almost always run on different machines than the J2EE server. If an enterprise bean's clients are Web components or other enterprise beans, then the type of access depends on how you want to distribute your components.
</p>
<a name="wp80065"> </a><p class="pBody">
<b class="cBold">Component distribution</b>: J2EE applications are scalable because their server-side components can be distributed across multiple machines. In a distributed application, for example, the Web components may run on a different server than the enterprise beans they access. In this distributed scenario, the enterprise beans should allow remote access.
</p>
<a name="wp80634"> </a><p class="pBody">
<b class="cBold">Performance</b>: Because of factors such as network latency, remote calls may be slower than local calls. On the other hand, if you distribute components among different servers, you might improve the application's overall performance. Both of these statements are generalizations; actual performance can vary in different operational environments. Nevertheless, you should keep in mind how your application design might affect performance.
</p>
<a name="wp80067"> </a><p class="pBody">
If you aren't sure which type of access an enterprise bean should have, then choose remote access. This decision gives you more flexibility--in the future you can distribute your components to accommodate growing demands on your application.
</p>
<a name="wp80068"> </a><p class="pBody">
Although uncommon, it is possible for an enterprise bean to allow both remote and local access. Such a bean would require both remote and local interfaces.
</p>
<a name="wp80648"> </a><h3 class="pHeading2">
Web Service Clients
</h3>
<a name="wp80651"> </a><p class="pBody">
A Web service client can access a J2EE application in two ways. First, the client can access a Web service created with JAX-RPC. (For more information on JAX-RPC, see the chapter, <a  href="JAXRPC.html#wp72279">Building Web Services With JAX-RPC</a>.) Second, a Web service client can invoke the business methods of a stateless session bean. Other types of enterprise beans cannot be accessed by Web service clients. 
</p>
<a name="wp80655"> </a><p class="pBody">
Provided that it uses the correct protocols (SOAP, HTTP, WSDL), any Web service client can access a stateless session bean, whether or not the client is written in the Java<img src="images/tm.gif" border="0" alt="Trademarked"> programming language. The client doesn't even &quot;know&quot; what technology implements the service-- stateless session bean, JAX-RPC, or some other technology. In addition, enterprise beans and Web components may be clients of Web services. This flexibility enables you to integrate J2EE applications with Web services. 
</p>
<a name="wp80738"> </a><p class="pBody">
A Web service client accesses a stateless session bean through the bean's Web service endpoint interface. Like a remote interface, a <em class="cEmphasis">Web service endpoint interface</em> defines the business methods of the bean. In contrast to a remote interface, a Web service endpoint interface is not accompanied by a home interface, which defines the bean's life-cycle methods. The only methods of the bean that may be invoked by a Web service client are the business methods that are defined in the Web service endpoint interface. 
</p>
<a name="wp80741"> </a><p class="pBody">
For a code sample, see <a  href="Session3.html#wp79822">A Web Service Example: HelloServiceEJB</a>.
</p>
<a name="wp80743"> </a><h3 class="pHeading2">
Method Parameters and Access
</h3>
<a name="wp80073"> </a><p class="pBody">
The type of access affects the parameters of the bean methods that are called by clients. The following topics apply not only to method parameters, but also to method return values.
</p>
<a name="wp80074"> </a><h4 class="pHeading3">
Isolation
</h4>
<a name="wp80584"> </a><p class="pBody">
The parameters of remote calls are more isolated than those of local calls. With remote calls, the client and bean operate on different copies of a parameter object. If the client changes the value of the object, the value of the copy in the bean does not change. This layer of isolation can help protect the bean if the client accidentally modifies the data.
</p>
<a name="wp80077"> </a><p class="pBody">
In a local call, both the client and the bean may modify the same parameter object. In general, you should not rely on this side effect of local calls. Perhaps someday you will want to distribute your components, replacing the local calls with remote ones.
</p>
<a name="wp80699"> </a><p class="pBody">
Similar to remote clients, Web service clients operate on different copies of parameters than the bean that implements the Web service. 
</p>
<a name="wp80078"> </a><h4 class="pHeading3">
Granularity of Accessed Data
</h4>
<a name="wp80079"> </a><p class="pBody">
Because remote calls are likely to be slower than local calls, the parameters in remote methods should be relatively coarse-grained. Since a coarse-grained object contains more data than a fine-grained one, fewer access calls are required. For the same reason, the parameters of the methods called by Web service clients should also be coarse-grained. 
</p>
<a name="wp80080"> </a><p class="pBody">
For example, suppose that a <code class="cCode">CustomerEJB</code> entity bean is accessed remotely. This bean would have a single getter method that returns a <code class="cCode">CustomerDetails</code> object, which encapsulates all of the customer's information. But if <code class="cCode">CustomerEJB</code> is to be accessed locally, it could have a getter method for each instance variable: <code class="cCode">getFirstName</code>, <code class="cCode">getLastName</code>, <code class="cCode">getPhoneNumber</code>, and so forth. Because local calls are fast, the multiple calls to these finer-grained getter methods would not significantly degrade performance.
</p>
    </blockquote>

   <img src="images/blueline.gif" width="550" height="8" ALIGN="BOTTOM" NATURALSIZEFLAG="3" ALT="Divider">


    <table width="550" summary="layout" id="SummaryNotReq1">
      <tr>
	<td align="left" valign="center">
	<font size="-1">
	<a href="http://java.sun.com/j2ee/1.4/download.html#tutorial" target="_blank">Download</a>
	<br>
	<a href="http://java.sun.com/j2ee/1.4/docs/tutorial/information/faq.html" target="_blank">FAQ</a>
	<br>
	<a href="http://java.sun.com/j2ee/1.4/docs/tutorial/information/history.html" target="_blank">History</a>
	</td>
        <td align="center" valign="center">
<a accesskey="p" href="EJBConcepts5.html"><img id="LongDescNotReq1" src="images/PrevArrow.gif" width="26" height="26" border="0" alt="Prev" /></a><a accesskey="c" href="J2EETutorialFront.html"><img id="LongDescNotReq1" src="images/UpArrow.gif" width="26" height="26" border="0" alt="Home" /></a><a accesskey="n" href="EJBConcepts7.html"><img id="LongDescNotReq3" src="images/NextArrow.gif" width="26" height="26" border="0" alt="Next" /></a><a accesskey="i" href="J2EETutorialIX.html"></a>
        </td>
	<td align="right" valign="center">
	<font size="-1">
	<a href="http://java.sun.com/j2ee/1.4/docs/api/index.html" target="_blank">API</a>
	<br>
	<a href="http://java.sun.com/j2ee/1.4/docs/tutorial/information/search.html" target="_blank">Search</a>
	<br>
	<a href="http://java.sun.com/j2ee/1.4/docs/tutorial/information/sendusmail.html" target="_blank">Feedback</a></font>
	</font>
	</td>
      </tr>
    </table>

    <img src="images/blueline.gif" width="550" height="8" ALIGN="BOTTOM" NATURALSIZEFLAG="3" ALT="Divider">

<p><font size="-1">All of the material in <em>The J2EE(TM) 1.4 Tutorial</em> is 
<a href="J2EETutorialFront2.html">copyright</a>-protected and may not be published in other works
without express written permission from Sun Microsystems.</font>

  </body>
</html>