Lightweight, heavy-weight

Source: Internet
Author: User
Tags hosting jboss

This article is copied from Baidu

Simple operation, low hardware configuration required. The magnitude is determined by the dependence of the vessel, the smaller the dependence, the lighter the weight, and Jim Rivera is a technical director of BEA Search company, responsible for promoting the application of BEA products through technical communication. Jim joined Bea in 1999 as a technical product manager for Bea WebLogic Server 6, 7 and 8. In this role, Jim is responsible for the strategy and roadmap for various server components, including EJBS, Web services, XML, and clustering. Jim has a blog on the Dev2dev. Dev2dev An email interview with Jim to get his perspective on the lightweight Java, application framework, and persistence framework, as well as their relationship to enterprise computing on the application server. Lightweight Java Dev2dev: How do you define "lightweight Java"? Jim: I think, in the Java Application development environment, "lightweight Java" is mainly about two things: a simplified programming model and a more responsive container. Lightweight Java is designed to eliminate the unnecessary complexities and limitations associated with traditional Java EE APIs. It will also shorten the deployment time of the application, which is important for supporting development best practices such as frequent unit testing.

Dev2dev: What kind of lightweight technology is most important to you, and how does lightweight Java help end-users?

Jim: Obviously, the inversion of Control (IoC) model has a significant impact in this area. With IOC, developers can resolve object dependency issues without having to write complex code to execute queries, handle infrastructure exceptions, or manage connections. This helps simplify the code, separating the business logic from the infrastructure, and making the application easier to maintain. Another key feature of lightweight Java is that it does not force business objects to follow platform-specific interfaces. This allows developers to implement business logic in common legacy Java Objects (POJO) to increase productivity. In contrast to specific classes, these features also make it much easier to unit-test code when combining development best practices with interfaces. Because the business logic is implemented in Pojo, it is no longer necessary to deploy the object to a heavyweight container to practice it in unit tests. Therefore, hosting objects in a simple test environment such as JUnit and "simulating" external dependencies for fast iterative unit testing becomes insignificant.

Dev2dev: As a technology propagator, you must have witnessed many new and deployed technologies. Do you see a trend toward lightweight technology?

Jim: Of course. Among the early adopters, there was a clear tendency to turn to frameworks such as Spring, Hibernate, and beehive. It has a significant difference in the way the application is built, and has a positive impact on the direction of the future of EE technology. For example, EJB 3.0 is basically based on a concept that makes lightweight Java popular.

Heavy-weight

Dev2dev: When people think about application server vendors, they usually put them in the "Heavyweight camp." I think you're trying to change the situation, right? In other words, many people think that application vendors are already paying a heavy price for implementing heavyweight components, such as EJB 2.0, and they are reluctant to abandon them easily.

Jim: First of all, I think there's no reason to abandon the existing investments on EJBS, because in some scenarios it's still the best technology, such as when you want to expose business services remotely through RMI. Of course, the value of open standards such as EJBS in protecting customer investments cannot be underestimated. As has been said, I think people often overemphasize the actual value of EJB in the application server. While this may not be appropriate for all application server vendors, BEA only invests a relatively small portion of development resources to support the Java EE API. The primary goal of our work is to build the most reliable, scalable, and fault-tolerant cores for our hosting applications. These qualities, along with distributed transaction services, high-speed messaging, legacy system integration, Advanced WEB Services, configuration Management, diagnostics and troubleshooting, and advanced Security, represent the true value of WebLogic Server and have a huge impact on total cost of ownership (TCO). Fortunately, the relevance and applicability of these added values to spring or beehive-based applications is the same as for applications built with EJB. While lightweight Java technology makes application development and maintenance easier, they do not replace the quality of a truly high-end application server. In fact, we think that lightweight Java is consistent with WebLogic Server.

Does Dev2dev:bea have a lightweight Java strategy? What is the way BEA implements lightweight Java?

Jim: Our strategy is to embrace all the technologies that will help improve developer productivity and provide the best platform for deploying these technologies in the market. Lightweight Java helps reduce development costs, and WebLogic Server helps reduce operational costs, which are a very powerful combination. Application Framework

Dev2dev: The Beehive Project, sponsored by BEA, is clearly a lightweight Java component model. Can you talk about Beehive and its position in your entire strategy?

Jim:beehive is an application framework that is dedicated to making Java EE applications and SOA-based applications easier to develop, based on our experience of releasing WebLogic Workshop. It provides a programming model based on POJO and metadata for configuring dependencies, quality of service, and so on. Metadata is supported in the form of J2SE 5.0 code annotations and external XML files. There are a number of components that are used to access Java EE resources, define business and Web services, and develop Web applications based on the MVC pattern. Beehive is a critical part of our efforts to increase developer productivity and consolidate the overall Java market.

Dev2dev:beehive can be considered an "application framework". A very popular lightweight Java approach is available in the Spring framework. How important is Spring (and other similar frameworks) to BEA?

Jim: Anything that can help our customers improve their productivity is important to us. We welcome and embrace these technologies and can integrate or share them at the technical level at the right time.

Dev2dev: Have you considered explicitly supporting these frameworks?

Jim: As I said, WebLogic server has many features that can provide applications based on lightweight Java technology. Many are implicit, but in some cases, the smallest amount of integration work can provide valuable value to lightweight Java developers. For example, some of the adapters that exist today allow Spring applications to use the distributed transaction capabilities of WebLogic Server without changing any application code. We are investigating many other opportunities and, of course, listening to the needs of our customers.

Dev2dev: We've seen some of the impact of the lightweight framework on EJB 3. Do you think this will extend to other aspects of the EE?

Jim: Yes. I think JSR 175, or Java metadata, is a key support technique for simplifying the Java EE programming model. EJB 3.0 uses it, and it is the basis for JSR 181, the Web Services meta-data, a BEA-advocated specification. There is no reason to believe that it will stop there. Lightweight persistence

The DEV2DEV:IOC container appears to be the center of lightweight Java. Another key factor is pojo and lightweight persistence. Can you speak on this question?

Jim: Similarly, the common theme is simplifying the programming model. Nothing is more simple than pojo. Of course, enterprise development requires that we have the ability to apply additional qualities such as persistence rules, transactional semantics, and POJO security constraints. A widespread approach is to define these qualities in metadata, either as code annotations or in external files.

Dev2dev: Do you think there are some dangers because there are many ways to do things like persistence? For example, we will soon have EJB 2, EJB 3, JDO, Hibernate, and so on.

Jim: I think it's just a reality in the mature world. Over the years, the Java EE specification does not fully cover this particular area, and will naturally lead to the emergence of other specifications. As I know what is happening in the JCP, we seem to be moving towards unification. This is a good thing for the industry as a whole. Future

Dev2dev: Can you foresee the future of lightweight Java and BEA?

Jim: We will continue to be active in this area by driving innovation through channels such as Apache Beehive, XMLBeans, Eclipse and JCP, and by absorbing other leading technologies such as Spring and collaborating for the benefit of our customers. Albert Einstein once said: "Everything should be as simple as possible, but not simpler." "Indeed, simplifying the basic assumptions of a theory allows us to focus on what really matters, and that is what has always been the pursuit of scientific truth." The same is true for enterprise software development. Providing an application framework that hides complex objects (for example, transaction, security, or persistence) from developers is key to simplifying enterprise software development. A well-designed framework can improve code reuse, developer productivity, and software quality. However, the existing j2ee1.4 EJB2.1 framework is generally considered to be poorly designed and too complex. Dissatisfied with the EJB2.1 framework, Java developers have tried a variety of middleware service delivery methods. Most notably, the following two frameworks have generated significant interest and positive feedback from developers. They are presented in the framework of the future Enterprise Java application Selection.

The spring framework, though popular, is not a standard open-source framework. It is primarily developed and controlled by INTERFACE21 Inc. The spring framework structure is a design pattern based on dependency injection (Dependency injection (DI)). It can be run standalone or on an existing application server, and is heavily used with XML configuration Files EJB3.0 is a standard framework developed by Java Community Process (JCP), supported by all major EE vendors.

JBoss has provided a trial version of the EJB3.0 standard for open source or commercial implementations.

EJB3.0 takes full advantage of Java annotations both frameworks have a common Core design concept: passing middleware services to loosely coupled POJOs (Plain old Java Objects, simple clean Java objects). Such a framework uses the interception execution context or injects the service object into the Pojo at run time to "wrap" the application service to Pojo. Pojo itself does not care about this "entanglement", nor does it have any reliance on this framework structure. As a result, developers can focus on business logic and Pojo unit testing out of the framework. In addition, since Pojo does not need to inherit the framework's class or implement its interface, developers are extremely flexible in building inheritance structures and building applications. However, with the same philosophy, two framework structures use different ways to deliver Pojo services.

Many books or articles compare spring or EJB3.0 with EJB2.1, but comparisons of spring and EJB3.0 are not studied carefully. In this article, I'll examine the key differences behind the srping and EJB3.0 frameworks and discuss their pros and cons. The view of this article also applies to other less well-known frameworks, as they are designed for "loosely coupled Pojo". Hopefully this article will help you choose the best framework for your needs.

Vendor agnostic

  One of the most compelling reasons for developers to choose the Java platform: vendor agnostic. EJB3.0 is a set of open standards that are not designed to be vendor-agnostic. The EJB3.0 standard is developed and supported by vendors of open source or commercial nature in all enterprise Java communities. It completely isolates developers from application server implementations. For example, JBoss's EJB3.0 implementation is based on Hibernate,oracle-based TopLink, but developers do not need to learn the specific API of hibernate-or TopLink to enable the application to run on JBoss or Oracle. Vendor independence distinguishes EJB3.0 from the other Pojo middleware frameworks of today. However, as many EJB3.0 commentators have quickly pointed out, the EJB3.0 standard has not yet reached a final version at the time of this writing. About a year or so. EJB3.0 can be widely supported by all major Java EE vendors. Even if your application server itself does not support EJB3.0, you can still run the EJB3.0 app by downloading the "inline" EJB3.0 product. For example, JBoss embedded EjB3.0 is an open-source product and can be run in any j2se5.0-compatible environment (for example, on any Java server), and this product is in the software testing phase. Other vendors will soon be releasing their embedded EJB3.0 products, especially for data persistence in the standard. Spring, on the other hand, has long been a non-standard technology that will last for a foreseeable period of time. While you can use the Spring Framework on any application server, the Spring app is locked into the spring itself and the specific services you choose to integrate into spring. The spring framework is an open source project, but at the same time it has an XML-formatted configuration file and programming interface. Of course any non-standard product will have this "lock-in" (lock-in) situation, is not unique to spring. But the long-term viability of the spring application still has to be blessed with the project (or INTERFACE21, which employs most of the spring's core developers). In addition, if you use any of the specific spring services, such as spring transaction manager or Spring MVC, you will also be locked into these APIs. The application of spring is not known to the end user. For example, for data persistence services, the spring framework is compatible with different DAO and JDBC Template helper classes, such as Hibernate, IBatis, and JDO. So if you need to switch to the data persistence service (for example, from JBDC to hibernate) for the spring app, you need to modify your code to fit the new template helper class.

Service integration

From a high point of view, the spring framework is above the application Server and service library. The Code for service consolidation (for example, data access templates and help classes) belongs to the framework and is exposed to the application developer. Instead, the EJB3.0 framework is highly integrated with the application server, and the service integration code is packaged behind a standard interface. As a result, vendors that implement EJB3.0 can greatly optimize overall performance and enhance the developer experience. For example, in the implementation of JBoss EJB3.0, when you persist an entity bean with Entitymanager, the Hibernate session transaction in the background is automatically set to the JTA transaction that invokes the method, in JTA The Hibernate session transaction is also committed while the transaction commits. You can even use a simple @PersistenceContext note (a later example) to bind Entitymanager and its background hibernate transaction to an application transaction in a stateful session bean. Applying transactions across multiple threads in a single session is useful in transactional Web page applications, such as multi-page shopping carts. Thanks to the highly integrated EJB3.0 framework, a simple, integrated programming interface can be made possible. The Oracle EJB3.0 framework and its back-end toplink persistence services are equally integrated. Another great example of EJB3.0 Integration Services is cluster support. If you deploy a EJB3.0 application on a server cluster, all fault tolerance (fail-over), load balancing, distributed buffering, and state replication are automatically available to the application. Back-end cluster support is hidden behind the EJB3.0 framework, which is completely invisible to EJB3.0 developers. In spring, it is difficult to optimize communication between frames and services. For example, in order to manage hibernate transactions using the claims transaction service in spring, you must configure the Spring TransactionManager and Hibernate sessionfactory objects in the XML file to be displayed. Spring must electronically manage transactions that span multiple HTTP requests. In addition, there is no other way to balance the clusters in the spring application.

Elasticity of the service mix

Because spring's service integration code is exposed as part of the programming interface, application developers have the flexibility to assemble services on their own terms. This feature allows you to combine your own lightweight application server. One common use of spring is to combine Tomcat and hibernate to support database-driven Web applications. In this case, spring itself provides transactional services, and Hibernat provides a persistent service-a setup that creates a pocket-sized application server. The EJB3.0 application server typically does not provide the flexibility to pick and choose the service as needed. Most of the time, all you get is a set of packaged features, some of which you might not need at all. But if the application server provides a modular internal design like JBoss, you can just take some of it and strip away the unnecessary parts. In any case, to customize a powerful application server is of little value. Of course, if the application already exceeds a single point, then you should join the services on the common server, such as the resource pool (resource pooling), Message Queuing (Messages queuing), and the cluster (clustering). In terms of overall resource consumption, spring solutions are as heavyweight as other EJB3.0 solutions. In the spring framework, flexible service assembly makes it easier to bind virtual objects rather than real business objects into an application to make unit tests out of the container. In EJB3.0 applications, most components are simple pojo, and they can be easily tested outside the container. However, in-container testing is recommended for objects related to container services, such as persistent real entity manager Entitymanager. Because it is easier, stronger and more accurate than the virtual object test method.

XML Vs. Annotations

From the application developer's point of view, Spring's programming interface is mainly based on the XML configuration file and EJB3.0 Extensive application of Java annotations. XML can express complex relationships, but it is also lengthy and not robust; annotations are straightforward, but it is difficult to express complex or inherited relationships in annotations. Spring Select XML or EJB3.0 Select annotations are determined by the architecture of their two frameworks. Because annotations can only hold very little configuration information, only the pre-consolidated framework (plays are in the frame) can use annotations extensively as a configuration choice. As we have discussed, EJB3.0 just meets this requirement, and spring is not consistent as a normal DI framework. Of course, EJB3.0 and spring complement each other, and in some ways they support XML and annotations. For example, in EJB3.0, an XML configuration file changes the default behavior of annotations as an optional overloaded mechanism. Annotations can also be configured with some spring services. Examples are the best way to learn the difference between XML and annotation methods. In the following sections, let's look at how spring and EJB3.0 provide critical services to the application. Both the declarative services spring and EJB3.0 bind runtime services (for example, transactions, security, logging, and configuration services) to the app. Because these services are not directly linked to the business logic of the application, they are managed only by the application itself. In other words, these services are transparently applied by the container to the application at run time. The developer or manager configures the container to tell it exactly when and how to apply the services. EJB3.0 uses Java annotations to configure declarative services, and sring use XML configuration files. In most cases, the EJB3.0 annotation approach is simpler and more straightforward for this service.

Here is an example of applying a transactional service to Pojo in EJB3.0.

public class Foo {

@TransactionAttribute (transactionattributetype.required)

Public Bar () {

Do something ...

}

}

You can also declare multiple properties for a code snippet and apply multiple services.

This is an example of applying transaction and security services to Pojo at the same time in EJB3.0

Lightweight, heavy-weight

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.