Spring-based remote services

Source: CCID

I. Introduction

Fundamentally, remoting is actually a distributed computing component of enterprises. Services (or classes) that are called within the same server (Java Virtual Machine) do not need to be exposed as a remote service. However, if you need to communicate with an external program (on a different server or in a different organization), you must implement it as a remote service. The Spring framework provides a unique and flexible way to expose business classes to remote services.

The core of spring remoting architecture is service objects. These objects are actually some pojo, also known as spring bean. The Spring framework can isolate these service objects from the basic structure details (such as the way they are exposed as remote services, developers can focus on implementing the Business interfaces of service objects rather than involving these details.

This remoting model provides remote abstraction of business services. It orchestrates and deserializes method parameters and is also responsible for handling any exceptions thrown in service methods-packaging them with unchecked remoteaccessexception exceptions. Spring uses several design patterns to implement various services. For example, it uses the proxy design mode to translate your http post request call into a URL pointing to the output service.
This article will focus on how to use spring to implement a remote service. That is to say, we need to demonstrate how to use spring remoting API to convert a common Java object (pojo) into a remote service. In this way, external programs can call this service from their business implementation. This example uses a loan processing application to implement a service as a remote HTTP service and call the business methods in this class from a test client.

Ii. Working Mechanism of spring remoting

In this section, let's analyze the remoting mechanism of spring in more detail. To implement a common Java class as a remote service, you need to provide the following content:

1. Exporter-these classes are used to create remote service endpoints called by client programs. The service export server also manages any registries used to query remote services.
2. Proxy factory beans-they are factory classes used to create proxies. Clients can use these proxies to connect to remote services.
3. HTTP invoker-as mentioned above, spring HTTP invoker uses a remoting model that allows you to implement cross-HTTP remote calls and use Java serialization technology to transmit Java objects. This makes it much easier to implement a remote service from a common Java class, and allows you to focus on the service interfaces of the remote service without having to consider the implementation details of the remote infrastructure.

This technology relies on the basic structure of RMI invoker, but uses HTTP as the transmission protocol.

Spring HTTP invoker provides two types of clients: Standard APIs provided by Java SE and commons httpclient APIs. By default, httpclient is used.
Next, let's take a look at the remoting technology supported by the Spring framework.

Examples of remote technologies supported by Spring framework

The Spring framework supports multiple remoting technologies. Next, we will give a brief introduction to them one by one.

1. Remote method call (RMI)

RMI is a distributed Java technology. Remote Java object methods can be called from a different Java virtual machine. It is basically the Java version of Remote Procedure Call (RPC), but it also provides the ability to pass multiple objects together with the corresponding request. RMI uses real object serialization to orchestrate parameters of the anti-Orchestration method without truncating the corresponding types.

Spring supports RMI in two ways: Traditional RMI and remote technology using RMI invoker.

2. Hessian

Hessian is a lightweight binary RPC protocol developed by Caucho Technology. It uses a custom serialization technology to send Java objects across networks. In addition to Java support, Hessian also provides implementation support for other languages such as PHP, Python, C ++, and C.

3. burlap

Burlap is a lightweight XML-RPC protocol for implementing Web Services. Similar to Hessian, Hessian also uses a patented serializer to serialize Java objects. More information about Hessian/burlap is not required here.

4. Http invoker

Spring provides a special remoting policy-HTTP invoker, which uses a standard Java serialization mechanism and exposes services through the HTTP protocol. This is a very important feature, especially when the method parameters you want to pass to the service are complex type objects and not just simple text messages.

5. EJB

Spring also supports the EJB component model. The EJB component also provides other J2EE/Java EE services, such as role-based authentication and authorization, as well as declarative and programmatic transaction management. However, the EJB model is a heavyweight component model, so most business applications tend to stay away.

6. Java Message Service (JMS)

The jms api is a message sending standard that allows Java applications to create, send, receive, and process messages asynchronously. It provides loose coupling and Reliable Distributed communication. By default, JMS remoting uses Java serialization, but a JMS provider (such as WebLogic JMS or jbossmq) can use another different mechanism (such as xstream API) to allow message sending through other technologies.

7. Web Services

With the open source web service engine Apache axis and JAX-RPC technology, Spring provides support for soap-based Web Services. Web Services provide real platform-independent remote technology, but their establishment is very complex and requires additional SOAP message processing overhead compared with conventional HTTP remote calls. Therefore, if you do not really need platform independence, you should avoid using web services as much as possible. In addition, you can use xfire (a lightweight SOAP library developed by codehaus) to expose Web Services.
In fact, each remote technology has its own advantages and disadvantages. Below they are a simple comparison.

RMI: fully supports Java object serialization. Therefore, you can send complex data types over the network. RMI is only a Java-to-Java remote solution. If you have any non-Java client, you cannot use it. In addition, you still cannot access objects through the HTTP protocol, unless you have a dedicated "channel" for RMI communication. Note that it requires an Rmi Compiler (to generate a proxy and framework) and an external Registry (for query services ).
Hessian/burlap: works well across firewalls. They use a patented Object serialization mechanism. Burlap only supports Java clients. They can serialize hibernate objects, but perform "inertia" loading on the collection objects.
HTTP invoker: HTTP-based Java to Java remoting; Java serialization through HTTP; easy to establish. Spring is required for both the server and client applications. It is only a Java solution.
EJB: supports the remoting J2EE service, application security, and transaction processing. EJB is a heavyweight technology. It requires a J2EE container.
Web service: the platform and language are independent. A Web service engine is required for soap operations.

As you can see, each spring remoting technology has its own advantages and disadvantages, but most practical applications require a lightweight remoting technology. When implementing remote services, using heavyweight remote component models such as EJB requires additional overhead. Generally, it is enough to use an HTTP service that supports object serialization.

3. Remote application programming example

Now, let's start to discuss the corresponding sample programs in this article. The program is designed for the following purposes:

◆ Interface-based design: an interface-based design eliminates the need for the client to understand the Implementation Details of remote services, and the Implementation can be changed without any modifications to the client code.

◆ Test-driven development: All components in the application should be testable outside the container. This example uses JUnit to write simple unit tests to validate the design of each class generated when you write code.

◆ Layered architecture: a layered architecture provides loose coupling, isolation, and flexibility. A typical J2EE application is implemented in layers-User Interface (UI) layer, application (or controller) layer, domain (domain model or service) layer, and infrastructure layer. The example application in this article provides three layers: controller, service, and domain.

◆ Separation of focus: Since the remoting function is unrelated to the business service, separation of focus plays a very important role in the process of implementing the service.

◆ Lightweight service: In this example, spring HTTP invoker API is used to implement remote services. Compared with other component models, HTTP invoker is quite lightweight.

◆ Non-intrusive: Spring is an excellent framework and is very suitable for using non-invasive APIs in business applications. With the help of technologies such as aspects and AOP, as well as design patterns such as control inversion (IOC), proxy and factory patterns, you can encapsulate the implementation details of a business-related task into a service class and expose only interfaces to the client.

In addition to these goals, this example also follows an Agile Software Development Method to compile the classes used by the sample application (refer to the corresponding source code in this article ).

Business Requirement Analysis

Now that you know the specific application design goals, let's discuss the actual business requirements. This example application is a loan Processing System (loanapp) that the customer uses to submit the application for home mortgage. In this remoting example, the business case is to perform a flood authentication check for a specified household property. Each home loan application requires a flood certification check to ensure that the property is not located in a flood area. If it is located in a flood area, the home owner is required to obtain flood insurance by paying a "813 fee" (813 is the code used to identify the flood certification fee.

On flood maps, high, medium, or low-risk areas are generally used as "Flood dangerous areas", and the highest-risk areas are used as "special flood dangerous areas ". Property in High-flood-risk areas (AE, A, or AO) has a probability of floods of about 1% each year, for a property mortgage that has lasted for 30 years, there is a possibility of 26% flood. Property in the ve or V region (also high-risk areas) is also prone to about 1% of floods each year, and faces dangers such as coastal storms. Households in low-level or intermediate flood-risk areas (B or C) are clearly located outside high-risk areas, although the flood risk in these areas is greatly reduced, but cannot be deleted.

Once the borrower completes the home loan application and selects the corresponding interest rate for the loan amount, the flood certification check will be triggered. A flood check must be conducted before the mortgage processing and insurance phase begins.

Case Analysis

The following are the steps for implementing the flood authentication check case:

1. The customer enters detailed data (such as the borrower name, property name, property address, city, postal code, and loan amount) to complete the loan application.

2. Select a loan product and Interest Rate and lock the loan within a specific period (for example, 30 or 45 days.

3. In this article, the loanapp calls a flood authentication check based on detailed attributes (such as addresses and postal code.

4. based on the postal code attribute of the client, the flood Service determines whether the specified attribute is in a flood zone and whether it requires flood authentication (this call is synchronous; therefore, before processing the loan application, the client needs to wait for the service response ).

5. Once a flood check request is returned, the loan is submitted to an automated Insurance System (AUS) for the credit history of the borrower and risk assessment of the loan application.

Technical Design

According to the idea of agile development, the next step is to design the technical requirements defined above. In this example, the following designs (classes and methods) are used to meet the requirements in the use case:

1. The client class (floodcertclient) calls the requestfloodcheck () method of the flood controller class (floodcertcontroller.

2. Then, the Controller calls the processfloodcheck () method in the Service (floodcertservice) and sends the loan details in the HTTP request.

3. The flood service calls the flooddao class to access the backend database and checks whether the specified attributes require flood authentication.

4. Dao returns a result object containing the flood authentication result. Then, the result data is returned to the client and displayed on the web page.

Since remote services act as the entry point for entering an enterprise's business domain model, it is very important to design the service layer as a whole. The following are some of the issues you need to keep in mind when designing remote services:

1. Remote Call type (is a remote call stateless or stateful ?)

2. Remote Call activation type (synchronous or asynchronous call ?)

3. Client type (Java,. Net or some other types of clients)

4. Operating System (Windows, Unix or another OS)

5. Transaction (do you need this remote service to be transactional so that any database or JMS queue update in the service method can be committed or rolled back as an independent work unit ?)

To meet all the above requirements for this use case, the example loan processing application in this article requires the following technologies and frameworks:

◆ Tomcat 5.5
◆ Spring 2.0
◆ JUnit
◆ Commons httpclient
◆ Eclipse
◆ Ant

Spring Configuration

The HTTP invoker remoting example in this article uses two configuration XML files, which define the spring bean corresponding to the class you wrote to implement the remote flood service; they are loanapp-servlet.xml and loanapp-client.xml respectively.

Implementation

The following are the steps required to implement a remote service for the example loan processing application based on HTTP invoker technology:

1. Create an HTTP invoker output class (httpinvokerserviceexporter ).

2. Create an HTTP proxy (using httpinvokerproxyfactorybean ). You need to specify parameters such as serviceurl and serviceinterface in this class.

3. Define a URL ing so that the client can call the remote HTTP service.

4. Configure spring bean in the loanapp-servlet.xml file.

5. Configure the spring web layer (dispatcherservlet) in the web. xml file ).

6. Compile the client class (using HTTP or commons httpclient ).

7. Compile a JUnit test case to call methods in the client class.

Test

The source code downloaded in this article contains a client class for the JUnit test Client Program (floodcertclienttest) to test the call to the flood remote service. It calls the client through several different test loan applications (using different postal code attributes. With the submitted Postal Code attributes, the flood service can return the results of the flood authentication analysis.

Iv. Summary

Spring remote technology provides a simple and flexible solution for exposing service domain services to remote services. At the same time, it also provides considerable flexibility for exposing the same service under multiple protocols (of course, at different URLs. For example, you can implement the flood authentication check service in the example program in this article as an Rmi service (for Java customers, you should use Java to Java remote technology more quickly, for non-Java customers, an HTTP service is recommended ). In this way, you can write business service logic in one place, but you can expose the service as two remote service endpoints.

The HTTP invoker framework provides necessary proxies for common Java service interfaces. It also provides consistent usage and configuration styles for remote services by implementing Java classes. This is a remote solution that combines the implementation of both worlds to achieve the best possible combination-combining the simplicity of HTTP Communication with the Java built-in Object serialization technology. This makes HTTP invoker both RMI and Hessian/burlap an excellent choice.

Of course, an important limitation of HTTP invoker is that it is only provided by the Spring framework-this means that both the client and service applications must be implemented using the Spring framework. However, this is a good option when you need a lightweight, easy-to-install and flexible solution.