Spring in Action
Learn notes
--
Sixth Chapter
Remote CallA remote call is a session between the client application and the server. Some of the features required on the client are not included within the scope of the application. So the application seeks help from other systems that can provide these capabilities. Remote applications expose these functions through remote services.
One,
Spring
Remote Call OverviewSpring provides a tool class for the integration of various remote access technologies. Spring remote support is implemented by the common (spring) Pojo, which makes it easy to develop services with remote access capabilities. Spring remote calls support 6 different RPC modes: Remote method call (RMI), Caucho hessian and Burlap, Spring's own HTTP invoker, EJB, and Jax-RPC Web Services.
| RPC mode |
Under what circumstances is useful |
| Remote method call (RMI) | td> access to/expose java-based services
| Hessian or Burlap |
when considering network restrictions, HTTP access/ Exposing a java-based service |
| HTTP invoker |
Accessing/exposing a service based on Spring when considering network restrictions |
| EJB |
Access legacy Java EE systems implemented with EJBS |
| Jax-RPC |
access Web Services |
where (from Spring2.0 reference manual): l Remote method call (RMI). By using Rmiproxyfactorybean and Rmiserviceexporter, Spring supports both traditional RMI (using the Java.rmi.Remote interface and java.rmi.RemoteException) and transparent remote calls implemented through the RMI caller (any Java interfaces are supported). l Spring's HTTP caller. Spring provides a special remote invocation policy that allows Java serialization over HTTP, and supports arbitrary Java interfaces (like RMI callers). The corresponding support classes are Httpinvokerproxyfactorybean and Httpinvokerserviceexporter. l Hessian. With Hessianproxyfactorybean and hessianserviceexporter, services can be transparently exposed using lightweight, HTTP-based binary protocols provided by Caucho. l Burlap. Burlap is another subproject of the caucho that can be used as an xml-based alternative to Hessian. Spring provides support classes such as Burlapproxyfactorybean and Burlapserviceexporter. l Jax RPC. Spring provides support for remote Web services through JAX-RPC. Regardless of which remote mode you choose, you will find that spring has a common style of support for each of these patterns. This means that once you understand how spring configures and uses one of these patterns, you will have a very low learning curve when you decide to use a different pattern. In all modes, a service can be configured as a spring-managed bean into your application. This is implemented with a proxy factory bean that allows you to place the remote service as a local object into the other BIn the properties of EAN. The client initiates a call to the proxy, as if the agent provided the functionality of those services. The agent communicates on behalf of the client and the remote service. It handles the specifics of the connection and initiates a remote call to the remote service. On the server side, you can expose the functionality of any spring-managed bean to a remote service, using any of the schemas listed in Table 6.1 (except EJB and Jax-RPC). Whether you are developing code that uses remote services, code that implements those services, or both, using remote services in spring is purely a configuration issue. You don't have to write any Java code to support remote invocation. Your service Bean doesn't have to care if they're involved in RPC (although any bean passed to a remote call or returned from a remote call might need to implement java.io.Serializable).
second, with
RMI
work together
1
. Connection
RMI
Service Spring's Rmiproxyfactorybean is a factory bean that can create a proxy that points to the RMI service. Using Rmiproxyfactorybean to refer to an RMI Paymentservice is very simple, just declare the following <bean> in the spring configuration file: <bean id= "Paymentservice" class= "Org.springframework.remoting.rmi.RmiProxyFactoryBean" > <property name= " Serviceurl "> <value>rmi://${paymenthost}/PayService</value> </property> <property name= "Serviceinterface" > <value>com.springinaction.payment.PaymentService</value> The URL for the </property> </bean> RMI service is set through the Serviceurl property. Here, the service is named Payservice and is on a machine configured with an attribute placeholder in a name (refer to section 2.4.3 of Chapter 2nd). The Serviceinterface attribute indicates the interface implemented by this service, and the client invokes the method in the service through this interface. By defining this payment service as a spring-managed bean, you can place it as a partner on another bean, as you would any non-remote bean. For example, suppose Studentserviceimpl needs to use this payment service to approve a credit card payment. You use the following code to place the RMI service into Studentserviceimpl: <bean id= "Studentservice" class= "Com.springinaction.training.service.StudentServiceImpl" >  . <property name= "Paymentservice" > < Ref bean= "Paymentservice"/> </property> </bean> Studentserviceimpl does not even need to know that it is dealing with an RMI service. It simply receives the Paymentservice object through the injection mechanism and does not have to care where it comes from. In addition, the agent captures any remoteexception that might be thrown by the service and throws them back as Run-time exceptions so that you can safely ignore them. This also makes it possible to exchange the remote service bean and the additional implementation of the service-perhaps a different remote service, or possibly a mock implementation of unit testing.
2
. Output
RMI
ServiceSpring provides a simpler way to publish RMI services: Using Pojo. Before you begin, you need to write the interface of this service:
Public
InterfacePaymentservice {
PublicString Authorizecreditcard (String cardnumber, String cardholdername,
intExpiremonth,
intExpireyear,
floatAmount
throwsAuthorizationexception;
Public
voidSettlepayment (String Authcode,
intMerchantnumber,
floatAmount
throwsSettlementexception; Since the service interface is not inherited from Java.rmi.Remote, its methods do not throw java.rmi.RemoteException, which makes the interface a lot shorter. But more importantly, when clients access the payment service through this interface, they no longer need to capture the exceptions that they might not be able to handle. Next, define the implementation classes for the service:
Public
classPaymentserviceimpl
ImplementsPaymentservice {
PublicPaymentserviceimpl () {}
PublicString Authorizecreditcard (String creditcardnumber, String cardholdername,
intExpirationmonth,
intExpirationyear,
floatAmount
throwsauthorizationexception {//String Authcode = ...; Implement authorization
returnAuthcode; }
Public
voidSettlepayment (String Authcode,
intAccountNumber,
floatAmount
throwsSettlementexception {//Implement settlement}} The next thing you need to do is to put Payme in the spring configuration file Ntserviceimpl configured as a <bean>: <bean id= "Paymentservice" Org.springframework.payment.PaymentServiceImpl "> </bean> Paymentserviceimpl does not set the characteristics inherent to RMI. It is simply a simple pojo that is appropriate to be declared in the spring configuration file. In fact, it is entirely possible to use this implementation in a remote manner by placing it directly into the client.
third, the use
Hessian
and
Burlap
the remote callHessian and Burlap are two of the solutions provided by Caucho Technology (http://www.caucho.com), which are lightweight remote services based on HTTP. They are all committed to simplifying Web services by making their APIs and communication protocols as simple as possible. In fact, Hessian and burlap are two aspects of the same problem, but each serves a slightly different purpose. Hessian, like RMI, uses binary messages to establish communication between the client and the server. However, unlike other binary remote technologies (such as RMI), its binary messages can be ported to other non-Java languages. Burlap is an xml-based remote technology that makes it possible to migrate to any language that can parse XML. Because of its XML, it is more readable than the Hessian binary format. Unlike other xml-based remote technologies, such as SOAP or XML-RPC, however, the burlap message structure is as simple as possible without the need for additional external definition languages (such as WSDL or IDL) [1]. How to make a choice between Hessian and burlap. To a large extent, they are the same. The only difference is that the Hessian message is binary, and the burlap message is XML. Because the Hessian message is binary, it is more dominant in bandwidth. But if readability is important to you (for debugging purposes) or your application will communicate with a language that is not Hessian implemented (any other than Java or Python), then burlap XML messages will be a better choice.
1
. Access
Hessian/burlap
Service All RMI details are included in the configuration of the bean for the spring configuration file. The advantage of this is that, because the client ignores the implementation of the service, it is extremely easy to go from one RMI client to the Hessian client, without changing any client code. The downside is that if you really like to write code, this section may disappoint you a little. Because the only difference between writing client code that is based on RMI and the client code based on the Hessian service is that you will use spring's hessianproxyfactorybean instead of Rmiproxyfactorybean. The Hessian payment service in client code can be declared with the following code: <bean id= "Paymentservice class=" org.springframework. ➥remoting.caucho.hessianproxyfactorybean "> <property name= "serviceurl" > < value>http://${servername}/${contextpath}/pay.service</value> </property > <property na
