Web services changes in EJB 2.1 through EJB 3.0

The business-level component of enterprise-class JavaBeans, known as the Java 2 Enterprise Edition platform, serves the evolution of the software and does not have a structural stagnation. In comparison with earlier versions of the EJBs3.0 version, we can already see a completely different development model, which makes the process of using Web services simpler.

If you're an early adopters of EJBS, you should know more about the complexity of the technology since its inception. Complexity has made many people abandon the idea of using EJBS, let alone the possibility of Web services based on this Java specification. In this way, many projects use a separate API, such as JAX-RPC or a framework similar to the Apache axis, to deploy Web services in the Java environment. While this approach provides a new low entry threshold, it lacks intrinsic middleware services--such as transaction processing and security services--many of the main reasons for using the EJB architecture, making it possible for developers to work with Java WEB Services in a not-so-good situation So that it can operate with advanced middleware performance or lead to a very complex development lifecycle.

First of all, it should be pointed out that EJB is not an intrinsic EJB, but an extension of the session EJB for the broader guidance of everyone. That is to say, a Web services enables EJB to start with an improved session EJB. In EJB version 2.1, the specification designer sees the need to provide an implementation of a branch that is using SOAP message access, but at what time is not an existing EJB--session, entity, and message--the decision is to use the extended session bean to accommodate Web services.

The problem with the EJB2.1 species mentioned earlier is that it is addressed in a traditional interface--serving in the form of a Web service terminal--and an additional deployment descriptor defining specific service behavior. Still, most of the drudgery in this process is not just the actual creation of the underlying EJB session bean, but also the idea that you want to turn it into a Web services EJB.

In short, we just enumerate the flaws in some particular process, and then we'll move on to a real EJB3.0 code to see how it's changed. The most significant problems with deploying a Web service in EJB2.1 are as follows:

The Web service needs to take its behavior from a session EJB, which itself is closely linked to an inheritance hierarchy-such as the version before EJB3.0-and also has a series of accompanying interfaces for the EJB environment.

You need to define a traditional Java interface that will be used to provide service endpoints, which are similar to the remote interfaces already contained in a session EJB.

Another configuration file-the deployment descriptor-is further required to indicate the service behavior of the EJB.

The mitigation of problems with these Web services EJBS is divided into two main forms: annotations and simple old Java objects (POJO ' s). Annotations are metadata that can be placed in Java source code files in order to provide further configuration properties or processing instructions to execute the Java environment. In another respect, POJO ' s is split into Java classes, which have no genetic dependencies.

By commenting, all the data that has been defined in the deployment descriptor can be replaced in a read file, which is the source file that contains the business logic. This is not to say that the external deployment descriptor was abolished in Web Services EJB 3.0. Instead, they are still very effective, although they will now provide a fallback mechanism to form a more natural and simple process to configure embedded information for business logic.

On the other hand, the design and coding phases of business logic can be achieved, just as Web services can achieve great simplification by using Pojo ' s. In EJB2.1, the process of creating an EJB that provides Web services forces you to deal with the inherited conditions imposed by the session EJB. So for these situations, if you start with a simple and understandable set of Web service operations, creating a simple Java object is just the beginning of the EJB process, because you need to do a lot of other work to reach the end of the EJB designed by Web services.