Source:
http://blog.9cbs.net/zzpchina/archive/2005/02/16/289293.aspx
When the New Year begins, it is necessary to post. Why? In fact, it is very simple, this article is very good, more good is about his comment, I said it is very good, it is very interesting, in fact, everyone is engaged in different applications, naturally derived in different contexts Various technologies and standards. Like: With Microsoft, it is not used to say that Kaiyuan is not used. The truth is very light, just as it has been ignored. . . . .
1.Scope compares to Scope, EJB scope is? What system is ejb designed? I think a one answer, I said it is not counted, and everyone says it is not counted, let's see the regulations (the topic said, I think I have n'thing to do.
Qualification is discusing the EJB, I have nothing to apply for EJB, but I have a habit, I read the standardization technology, no matter how others say, what is it coming first, I think this also makes me some open confidence. Not too
The first few words of the EJB specification:
Enterprise JavaBeans IS An Architecture for Component-Based Computing.Enterprise Beans Are Components Of Transaction-Oriented EnterpriseApplications.
Ok, it is clear that EJB is a component of Transaction-Oriented Enterprise Application, so that EJB is facing
Come into business software, nothing else. EJB core is
Transaction, not Domain Model or else.
Why Transaction? I have done an information software architect in the power industry, in such a field that needs to handle large amounts of data, I have oo model, but I finished Entity analysis, handed over to DBA optimization, with data
The performance is mainly, in such a system, the particle size of the data operation is Transaction, not Object or other. I think this should be a large enterprise-class system, I see transaction, so EJB is set to SCOPE
In the ENTERPRISE level, this design also makes reasonable. Moreover, EJB's processing of this part is indeed complete, CMT, BMT, and different transaction scope controls are very good. Based on this understanding,
I know Transaction Script is the standard application model of EJB, not Domain Model or other.
This is the source of EJB's largest misunderstanding. I have seen all EJB books, only O'Reilly's vague refer to Transaction is the center of EJB. Others will not mention, crazy advocacy, how much good ejb, I want to
If you don't know that EJB is Transaction-Oriented, the EJB strange object model is indeed unacceptable.
So say spring, what is Spring? I didn't see a particularly clear definition, but I want to imitate EJB, define Spring as:
Spring is a javabean-based framework That Supporting Component Architecture Development.spring provides lighter context for heterogeneous entropyApplication.
My E Wen is very poor, CET-6 6 times have never been, I want to explain that Spring is a lightweight component architecture that supports a variety of enterprise applications. Seeing that someone should say, NO, NO is also IOC, there is AOP, yes this
I didn't say, but included, Component Architecture means two aspects, Component Working, and Container Working, Spring's IOC and AOP are
Used in Container Working. Of course, there are some other few no summers, but I want to say that the main body is still said. This scope is very clear, Spring's foundation is JavaBean, JavaBean supports complete OO construction
Module, Spring can apply more structures, some of Domain Model and other.
Then start comparison, Spring has a theoretical general component model, but in view of the large application of more Transaction-Oriented, the reason for Spring is Domain Model, EJB cannot provide a complete OO model.
Spring can.
Conclusion: Due to scope, it is not significant for Spring and EJB more suitable for enterprise development. Because it is simply two different categories, accusing EJBs on Scope, it is like Raimundox, you
I can't give my child, but also let her feel so painful for October. In fact, I don't want to, I also want to replace, but we have this function ..... I am far away, EJB is also, don't this function, how do you force him? You have to say that the EJB design is not good.
It is not right, people have specialized fields. So I said, comparing Spring and EJB in Scope, it is not a level.
2.Component Architecture
Component Architecture has a basic view that Component and Context are separated. Ideally, Component is only responsible for the implementation of business, and Container provides context, this Context only technology
Context, such as transactions such as security support. Thus, the basic view of Component Architecture is the business attention point and Technique attention point separation. Business is responsible by Component, Technique
Context or called Container implementation. It is so clear that there are two programming in Component Architecture, for Component and for Container.
Ok, I have this understanding, we can continue, if someone has a doubt, then I am sorry, this article is not suitable for you, the back all the arguments are based on this point. If this is not recognized, the following will not Recognize, you
Needless to waste time.
First, see EJB's Component, EJB is very good in Component Architecute, EJB is a business component, and in the case of Container-Managed, the component can apply the technical context provided by the declaration to apply the container, when Container-Managed is dissatisfied Next, you can beam-managed, just keep the external transaction semantic (remember? EJB is Transaction-Oriented, the most important thing). In ejb
The agreement of components and containers is very clear and which requires components to write, which is very clear, which is very clear, which is a good habit in Component Architecture, clear components and containers (a shortcoming of EJB, overkill
Positive, some operations are also prohibited). Writing code is very easy, business, ONLY business. In fact, in the specification of EJB, EJB's CODER is actually dominated by Domain Expert, and it is good to achieve business logic.
Now let's look at Spring's Component, Spring is based on JavaBean, the poor container, that is, the container is not required, so the first shortcoming, the contract of Contianer and Component is not clear (write here I
I have heard some people are called, this is the advantages, freedom, don't worry, and I will prove that this is the soft ribs), but Spring uses a smart approach, which is to strengthen Container Working.
Look at Spring's Container Working, through Spring's AOP API, we can easily customize container environments for specific components, putting a component of the container technology environment in Aspect, Weave to Component
It is very flexible and very powerful. Spring makes up the component / container in this form, everything is selected by the Component, the container does not provide any technology context, I want.
What you have come, this gives the Component implementer's own right, very good (but also implies the biggest shortage of Spring, don't say, I will say it later).
Look at EJB, very sorry, the ability of EJB Container Working is almost 0, of course, the JCA is not too bad, but that is just resources, not technical context. Why? Because EJB think he has provided all
The technological context necessary for enterprise development, transaction (I always put him in the first place), distribution, concurrency, safety, etc. It seems that the ability of Container Working in EJB is almost useless, and is not safe, except JBoss openness.
The other EJB Container provides very little support in this area. Of course, it is not a bad thing, and whether it is not configurable, or it is either it is very
Atomic), this is the biggest shortage of EJB, and the container environment is not equivalent, and it is also a place for Spring stronger than EJB.
Above we have seen Spring and EJBs are Component Architecture, then the most direct use of Component can be multiplexed. So comparison is to compare EJB and Spring Component
The key to Architecture. Seeing that Spring's supporters are always angry, Spring multiplex must be strong than EJB multiplexing, Heph, but my conclusion is just the opposite, EJB is better than Spring multiplexing! ! Less your anger, put away your disdain, listen to me.
In Component Architecture, Component is a business implementation, without having a technical code, even if you use a container environment to perform operations, such as servletContext is waiting.
Then, in fact, the key to multiplexing under construction is not to be formulated but the container! !
I used to have a quite famous DX (Gigix said, saying you), say "COM and EJB have a modularity and reuse, modularity is true, multiplex is a lie", COM I am not very Cooked, not well conclusions, EJB? EJB is not easy to use me
Recognizing, but is it lie? Don't deceive, and I will give an ejB multiplex ideas. Anyway component is not made, only if the business logic wants to use the corresponding container environment, then the reuse of the container environment is the component
The key to use. EJB is not easy to reuse because if we leave the container, we must give it a corresponding technical context, transaction, distribution, concurrency, etc.
Therefore, the EJB efficiency of the container is very low. note,
Is outside the container, the components are originally in the container, who makes you don't have to use it), and the container? Because the EJB specification specifies that the EJB container should be compatible, don't say how difficult WebSphere to BEA is, it is not difficult, or
It is difficult to say that it is more difficult than transplanting the Spring component to Pico. Of course, you have no way to use Vendor-Specified's characteristics. This is no longer normally, you don't complain about it. Therefore, the reuse of EJB is ok, and it is a standard guarantee.
Certificate, there is also a way outside of the container, nor is it difficult, I will say it later.
Look at Spring, it is indeed flexible, but this is a fatal injury, and Component is completely business implementation, but the container? How does Spring ensure a container environment? No, you can only guarantee yourself, when you say it, Spring
Component is POJO, it can be used very well, it can be thought of that this reuse is to reuse the container. For example, there is a Componenta, which requires transaction model a and security model a in Systema, need to do in systemb.
How do you want to use Componenta from Systema? Rewrive transaction model B and security model B, then you can say that you have multiplexed the components. Indeed, you have multiplexed components, but
Are you overwriting the container, value? More terrible is that Spring containers and components have no agreement, so how do you guarantee your unwritten technical code? EJB is just as long as bean-managed and a unified transaction model, Spring? you
What guarantee? yourself? This is Spring a big hard injury, complete Container-Manage, lacks specific Component boundary control. You can say that the special requirements of the transaction model EJB will not realize it, it is possible
, How much is EJB TRANSACTION MODEL not available? If you really don't do it, you can only say that EJB is simple to reuse it here. There is also a problem for the component is deploying, which is also the place where EJB is a disease. Indeed, EJB deployment is complex enough, but there is a special role in the EJB specification to be deployed, EJB is Component Architecture, then
For example, if there is a person to bond technology and business, this person should not be Programmer (I just said, EJB's implementation is best business expert, realizing business logic), EJB deployment is a very powerful person, he needs Know what business
What kind of technical support is needed, so deployer is the most cattle in EJB Architecture. I will not think about writing EJBs, but I have always admired EJB Deployer. Of course there is a debuga
Difficult issue, this is the hard injury of EJB, no way, this is even the hard injury developed by the component.
Look at Spring, Spring claims that he is deployed, I think rod johnson is transferring the line, thinking about it, how much difference is made to be a WAR and a EAR? So where is the difference between deployment? Differences in EJB Deploy
Description and Spring's Context.xml writing! In the development of Spring, there is a person to write context.xml This person often knows the system, know what component is used, and that component relies on that, even
Will be the architect in this matter, then how much difference between the people who have a big view of the system in EJB? May be the writing of XML, I want to be a proficiency problem with the support of the tool, so I think it is deployed.
Spring and EJB are similar, Spring doesn't have to serve, and debug is easy.
Conclusion, Spring is flexible, and the EJB is unified, and the winners are good at, and Spring is flexible as the price, but if there is a CommON technology implementation, it is really good, but
Spring a set of CommON's technology is about equal to EJB?
3. Semantics
So what is the problem of Spring multiplexing? In fact, it is a lack of semantic support, and EJB development can be seen as a unified semantic environment, this semantic is specified by the EJB specification, so EJB has a language guarantee, and
Spring? In a poor language, everything has to developers to achieve themselves. Therefore, if the environmental semantics of EJB can be expanded and configurable (such as removed distribution), Spring has no advantage, the standard consistent consistent component architecture makes EJB
It will be a big act, but now there is no SpRing hot. This is a deformity of the victory. It is a complete semantic loss to the poor language. What is the problem, forced consumption ... Who let EJB I have to force customers to buy? Used distributed
Environmental single? But unified semantic power will not be masked, there are two roads, Spring combined with OS communities, develop the LightWeight J2EE semantic collection, and strive to become standard. Second, EJB implementation technology semantics can be configured.
Who will win? Not saying, but it seems that EJB footsteps!
Attachment: Container extraction EJB
In fact, EJB is fully available outside of the container, but in order to maximize the use, bean-managed is recommended (not CMP, BMP but cmt, bmt), then how to transfer a transaction? SessionContext (seems to be this one, you can't remember, you are 2:00, sleepy ... is the ejb that CONTEXT interface), an interface, you make your own Mock, it will be made in a transaction. How to assemble? Spring Setter
Injection. If you use Spring, then CMT can also be implemented, but you can see you can implement EJB Transaction Model. Entity Bean, if it is BMP, use it well, CMP, inherit one
Hibernate. These are simulated, find a JNDI of IN Memory, seal the Spring Context, which is equivalent to implementing a lightweight ejb container with Spring (actually gives Spring
EJB API's skin), what extent? In addition to injections nothing.
The Client can then construct JNDI, then lookup
Seeing that someone must say that you are full, so the hardship container is used to use EJB, why not use Spring directly, this is not enough, each component has the inheritance of EJB class, ok, I tell you this Be the benefits, first
Although it is not enough, it is enough to manage EJB, which proves that my view container can use EJB (Herk, do not say even rpwt ...). Second, when the business is developed, your system Need to be distributed
Remove Spring, take out EJB, RedEploy, OK, extended, stable, distributed, this is the realm of multiplexing this, change a deployment of the entire environment, remove the lightweight EJB Container, transfer
Heavyweight is heavyweight.
Of course, it is very difficult to achieve, it will be easier in EJB3, I bet, Spring must be the supplier of Lightweight Ejb Container, which is not free, OS does not look at Rod Johnson, but I think I hope.
