The first post posted on javaeye

I know I want to pull bricks. It's okay. Come on :)

Khhe, let me talk about spring vs EJB. First of all, I stress that I am not an advocate of ejb, but I appreciate his integrity, his school spirit, and his deep injury, I am not a supporter of spring, although I saw it in and

Spring once made me shine. There are too many misunderstandings about ejb and too much criticism about spring. I hope this is a relatively fair comparison.

I think the difference between spring and ejb is in three aspects: one is the scope of the audience, that is, the two things called framework or platform, the other is component architecture, and the last one is semantics.

.

[B] 1. Scope comparison [/B]

First, let's talk about scope. What is the scope of ejb? Which system is ejb designed? I want to answer this question by myself. If I say this, it doesn't matter. If you say this, it doesn't matter. Let's look at the specifications.

I'm qualified to talk about ejb here. I don't have many projects to use ejb, but I have a habit of reading normative technology. No matter what others say, Let's first look at how this thing came about, I think this makes me feel a little confident, not too confident.

The first few words of the ejb specification:
[B] Enterprise JavaBeans is an architecture for component-based computing. Enterprise beans are components of transaction-oriented enterprise

Applications. [/B]

Well, it is clear that ejb is a component for the transaction-oriented enterprise application, so that ejb is an enterprise software for [B] transaction-centric [/B, instead of anything else. The core of ejb is

Transaction, not a domain model or something else.
Why transaction? I have worked as an information software architect in the power industry. In the field of electric power that needs to process a large amount of data, there are very few oo models. Instead, I have completed entity Analysis and handed it over to the dba for optimization and Data

Performance-oriented. In such a system, the granularity of data operations is transaction, not object or anything else. I think this is a large enterprise-level system. What I see is transaction. Therefore, ejb sets the scope

Such a design is also reasonable for enterprise-level things. In addition, the processing of the transaction part by ejb is indeed complete. The cmt, bmt, and different transaction scope are well controlled. Based on this understanding,

I know that transaction script is the standard application mode of ejb, not the domain model or something else.
This is the source of the biggest misunderstanding of ejb. In all the ejb books I have read, only one of o 'Reilly vaguely mentions that transaction is the center of ejb. I will not mention anything else. I am crazy about how good ejb is and how powerful ejb is.

If you do not know that ejb is transaction-oriented, the strange object model of ejb is indeed unacceptable.

What is spring? I didn't see a very clear definition, but I want to follow the ejb and define spring:
Spring is a Javabean-based framework that supporting component architecture development. Spring provides lighter context for heterogeneous entrprise

Application.

I am poor e text, CET-6 6 times have not, I would like to note that spring is a lightweight component architecture, can support a variety of enterprise application models. someone should have said this again. no, no, and ioc, and aop. That's right.

Some cool features I didn't say, but they contain. component architecture means two aspects: component working (component writing) and container working (container compiling environment). spring's ioc and aop are

Used in container working. of course there are some other things that are not summarized, but I still want to talk about the subject. in this way, scope is very clear. spring is based on javaBean, and javaBean supports complete oo creation.

Therefore, spring can apply more structures, such as domain model and others.

At the beginning of the comparison, spring has a theoretical universal component model. However, given that most large applications use transaction-oriented, the reason for using spring is domain model. ejb cannot provide a complete oo model.

Spring can.

Conclusion: Because the scope is different, it is meaningless to compare spring and ejb, which are more suitable for enterprise development, because there are two different categories at all, and the scope points out that ejb is not as good as spring, it's like raimundox, you

I can't give birth to a child for my wife, but also make her so painful pregnancy in October. In fact, I don't want to, and I also want to replace it. Unfortunately, we are far away from this function. So is ejb. How can you force it without this function? You have to say that the ejb Design is poor.

No. People have specialized fields. Therefore, it is meaningless to compare spring and ejb in scope, and it is not a level at all.

[B] 2. component architecture [/B]

Component architecture has a basic idea: the separation of component and context. Ideally, component is only responsible for business implementation, while container provides context, which is only a technology

Context, such as security support for transactions. Therefore, the basic idea of component architecture is that the business focus and technique focus are separated. The business is the responsibility of component, and the technique is

Context or container implementation. It is clear that there are two programming methods in component architecture, for component and for iner.
Well, with this understanding, we can continue. If someone is skeptical, I am sorry. This article is not suitable for you. All the arguments behind it are based on this point of view, if you do not recognize this, the following will not be recognized.

You don't have to waste time.

First, let's take a look at the component aspect of ejb. ejb is a business component. In the case of container-managed, the component declares that it can apply the technology provided by the container.

Context: When container-managed is not necessary, bean-managed can be used, as long as the external transaction semantics is maintained (remember? Ejb is transaction-oriented, which is the most important task ). In ejb

The conventions between components and containers are very clear. Which components need to be written and which are provided by containers are very clear. This is a good habit in component architecture, clarify the boundaries between components and containers (a disadvantage of ejb, too many mistakes

Yes, some operations are also prohibited ). Code writing is very easy, business, only business. In fact, in the ejb specification, the ejb coder is actually better than domain expert to implement business logic.

Now let's take a look at spring's component. spring is based on javaBean and has no requirements for containers. Therefore, spring is the first disadvantage, the contianer and component conventions are unclear.

Some people have heard that this is the advantage and freedom of spring. Don't worry. I will prove this is the weakness of spring later), but spring uses a clever method, that is to strengthen the container working.

Let's take a look at spring's container working. Through spring's aop api, we can easily customize the container environment for specific components, and weave the container technology environment required by a component to component in the form of aspect.

Is very flexible and powerful. spring uses this form to make up for component/Container Conventions. Everything is selected by component, except for assembly (ioc/dip) no technical context is provided.

This gives the component implementer the right to choose. It is good (but it also implies the biggest weakness of spring. Don't worry, I will talk about it later ).

Let's take a look at ejb. Unfortunately, the ejb container working capability is almost 0. Of course, it is not too bad if it is regarded as jca, but it is only a resource rather than a technical context. Why? Because ejb considers that it has provided all

The technology context necessary for enterprise-level development, transactions (I always put it first in ejb), distribution, concurrency, security, and so on. In ejb's view, the workiner working capability is almost useless and insecure, except for the jboss open

Many container working interfaces are provided by other ejb container. of course, it is not a bad thing to provide many technical contexts. It cannot be configured, either completely or not.

Atomic). This is the biggest drawback of ejb, and the container environment is not available. It is also a place where spring is better than ejb.

As we have seen above, both spring and ejb are component architecture, so the most direct use that component can think of is reuse. Therefore, we can compare ejb and spring component.

The key to architecture. Spring's supporters should have breathed a sigh of relief here. spring reuse must be better than ejb reuse, but I have come to the opposite conclusion: ejb reuse is better than spring reuse !! Hide your anger

, Hide your disdain and listen to me.

In component architecture, component is a business implementation without technical code. Even if it is used, it must interact with the container through the container environment, such as ServletContext. [B] Actually

The key to reuse in the build structure is not to build a container !! [/B]

In the past, there was a well-known dx (gigix doesn't look at it, let's talk about you), saying, "both COM and EJB advocate modularization and reuse. modularization is true, and reuse is a lie ", I am not very familiar with com, so it is difficult to draw conclusions. What about ejb? Ejb is not easy to reuse me

Admit it, but lie? Don't lie. I will give you a reference to the idea of ejb reuse later. Components are not technically used at all. Only when the business logic is used, the corresponding container environment is required. the reusability of the container environment is component duplication.

The key to application. Ejb is not easy to reuse because, if we leave the container, we must provide it with the corresponding technical context, and there should be no less one such as transactions, distribution, and concurrency, [B] Therefore, the efficiency of reusing ejb outside the container is very low [/B]. Note,

[B] is outside the container. [/B] components are originally running in the container. Who asked you to take them out for use?) in the container? Because the ejb specification specifies that the ejb container should be compatible, not to mention how difficult it is to port webSphere to bea, but it is not difficult, or

The difficulty is a little more complicated than porting the spring component to pico. Of course, you can't use the vendor-specified feature. This is no longer a standard. If you violate the rules, don't blame others. Therefore, the reuse of ejbs is acceptable, and the specification is guaranteed.

There is a way out of the container, and it is not very difficult, I will talk about it later.

Let's look at spring. It's true that he is flexible, but this is a fatal injury. component is completely implemented by the business, but what about containers? How does spring ensure the container environment? No, you can only ensure that, when you are complacent, spring

When the component in is pojo and can be reused well, I thought that the cost of reuse is to reuse the container. For example, if there is A componentA that requires transaction model A and Security Model A in SystemA, you need something in SystemB.

Service Model B and Security Model B. What do you do when you reuse componentA from SystemA? Rewrite Transaction Model B and Security Model B. Then you can simply say that you have reused the components. Indeed, you have reused the components,

You have rewritten the container, the value? What's more terrible is that there is no agreement between spring containers and components, so how can you ensure that your organization does not write technical code? Ejb only needs Bean-Managed and provides a unified transaction model. What about spring? You

What guarantee does it rely on? Yourself? This is a major weakness of spring. It lacks specific component Boundary Control Under container-managed. You can say that the transaction model ejb with special requirements cannot be implemented yet. Indeed, this is possible.

But what are the situations where the ejb transaction model cannot be applied? If it doesn't work, you can only say that simple reuse of ejb fails here.

Another problem with components is deployment, which is also a criticism of ejb. indeed, the deployment of ejb is complex enough, but there is a dedicated role in the ejb specification to be responsible for the deployment. ejb is the component architecture, that

For example, if one person binds technology and business, this person should not be a programmer (as I said earlier, it is best for ejb practitioners to be business experts to implement business logic ), the deployment of ejbs is amazing. He needs to know what business

What kind of technical support is needed and how to get the performance? So deployer is the best in ejb architecture. I never thought that I was a master in ejb, but I always admired deployer. of course there is a debugging

The difficult problem is that it is an error in ejb development.
Let's look at spring. spring claims that it is easy to deploy. I think rod johnson is moving his line of sight. How much is the difference between dividing a war into an ear? So what are the differences in deployment? Difference in deploy of ejb

Description and spring context. xml! In spring development, one person needs to write context. xml. This person often knows the system, what components are used to intercept, And what components depend on or even

If the architect is doing this, what is the difference between deploy and those who have a general picture of the system in ejb? It may be the compilation of Xml. I think it is a matter of proficiency with the support of tools, so I think the deployment

Spring is similar to ejb. spring does not need to start the server, so debugging is easy.

Conclusion: In component architecture, spring is flexible, and ejbs are unified and complete. spring flexibility is at the cost of reducing reuse. However, if common technology is implemented, it is indeed well-used,

Spring + a set of common technology implementation is about equivalent to ejb, right?

[B] 3. Semantics [/B]

So what does spring reuse mean? In fact, there is a lack of semantic support. ejb development can be seen as being implemented in a unified semantic environment, which is defined by the ejb specification. Therefore, the reuse of ejb has a semantic guarantee.

What about spring? Poor semantics, everything must be implemented by developers themselves. Therefore, if the environment semantics of ejb is scalable and configurable (such as removing the distribution), spring has no advantages. The consistent and complete standard component architecture makes ejb

There will be much to do, but now it is not enough to have spring popularity. this is a malformed victory. The complete semantics is lost to the poor semantics. What is the problem? forced consumption... who forced the client to buy distributed data that could not be used?

Environment ticket? However, the power of unified semantics is not hidden. Now there are two ways to combine spring with the OS community to develop a lightweight j2ee semantic set and strive to become a standard. Second, the technical semantics of ejb implementation can be configured and scalable.

Who will win? Not easy to say, but it seems that the pace of ejb is faster!

[B] Appendix: Out-of-container reuse ejb [/B]

In fact, ejb can be used outside the container, but to maximize the availability, bean-managed is recommended (not cmp, bmp, but cmt, bmt ), so how to transfer a transaction? SessionContext (

It seems that this name is hard to remember. It's almost, so sleepy... it's the context interface of ejb). For an interface, just mock it yourself and just give it a transaction. How to assemble? Spring setter

Injection. If spring is used, the cmt can also be implemented and intercepted, but it depends on whether the ejb transaction model can be implemented. Entity bean. If it is bmp, use it. cmp inherits one

Hibernate. These are all simulated. Find a jndi in memory and seal the spring context. This is equivalent to implementing a lightweight ejb container using spring (in fact, it is

To what extent? There is nothing except injection.
Then the client can construct the jndi and then lookup
Some people may say that you are full of support, so it is difficult to reuse ejb outside the container. Why not use spring directly? This is not enough for pojo. Every component has the inheritance of ejb classes, well, I will tell you the benefits of doing so first.

Although pojo is not enough, bean is enough, so spring can manage ejbs, proving that I can use ejbs outside the container (Hehe, don't say rpwt ...). second, when your business develops, your system needs to be distributed.

Remove spring, take out ejbs, redeploy, OK, extend, stability, and distribution. This is to reuse the existing realm and change the entire deployment environment, remove lightweight's ejb iner and transfer

Heavyweight is a heavyweight.
Of course, this implementation is very difficult, and it will be easier in ejb3. I bet that spring will be the vendor of lightweight ejb container in the future. It is free of charge, and the OS does not have to look at rod johnson, but I don't think there is much hope.

Thanks:

First of all, I would like to thank dlee for forming the topic of this article in his discussion with him. Then, I am on ice cloud. He helped me review the article until, and both udoo and perhaps put forward pertinent comments, thank you.

Of course, you are also welcome to visit my blog: www.cnblogs.com/raimundo