The overhead of the front car, the rear car
- On the Experience of Open Source Project
(This article published in "Programmer" 2005 No. 2) With the increasing popularity of open source culture, "participation in open source" seems to have become a fashion. For a time, it seems that everyone is happy to share their code. Just on the eve of the New Year, an old friend, a J2EE architect that came to open source, had also released an open source J2EE application framework (aunt called "x framework"), have to laighten the open source culture The influence is powerful.
Unfortunately, open source is not free for lunch, and the source code will mean to bear the review of the public. Just a few days later, several senior J2EE architects have come to a conclusion: under a look, the X framework can only count a failure project in any one angle. What is the reason for a good wish, I can only get a failure result? This paper takes an X-frame as an example, reviews some of the mistakes of the project leader in the initial open source, pointing out some of the principles that should be followed by the open source, and cleave some obstacles for the subsequent open source enthusiasts.
Maturity
Open the X Framework in SourceForge project site, we can see it: "5 - production / stable" in the "development status" column. That is, the author believes that the X framework has been mature and can deliver users. Then, it is not too late to evaluate it now. However, is the X framework is really ready?
Open the source package of the X framework downloaded from SourceForge, the author can't help but surprise: Really only source code in the compressed package - compile, the library files required to run the entire project are all. From the author's own forum, the project needs to rely on many open source projects such as JBoss, Jdom, Castor, Hibernate. The author had to download these projects himself, and a toss finally successfully compiled the entire project in Eclipse.
You don't have to understand the open source culture, as long as you have used some mainstream open source products, you should know that one open source software should at least provide the source code release package and binary release bag, at least there should be necessary in the source code package. Dependent library file (or packed the dependency library), the complete unit test case (for JAVA project is usually a JUnit test suite), and the script that is compiled (for Java project is usually an Ant script or Maven script), but these The content is not visible in the release package of the X framework. If you want to use this framework, you must download all dependencies like the author, then manually complete compilation and build, and there is no understanding of whether there is any error (because there is no unit test). This is the form of publishing, is it "Production / Stable"?
Open source must-read: Convenient build open source software should provide the most convenient build mode, allowing users to complete the compilation, build, and test of the entire project and get running binary. For Java projects, this usually means providing a complete JUnit test suite and Ant script. Your potential users may try all similar open source software within a day. If a software requires him to use it for a long time to complete build, and there is no correctness from verification, and there is no need to write his own test case, this software is likely to The first time was thrown into the corner.
From the SourceForge project page, you can see that the Liche License V2.0 (APL) of the X framework is Apache License V2.0 (APL). However, in its release package, the author did not see any formal license agreement text. As is well known, SourceForge's project description is a modified (the License Agreement of the X framework itself is once GPL). If there is no official authorization protocol text in the release package, once the author modifies the SourceForge project description, the user should be Where do I find evidence to support my legal use? In the source code of the X frame, most source files add APL's authorization statement, but some source code is very worry. For example, Utilcche This class, there is no authorization declaration at the beginning, and the author information is made in Javadoc:
@Author David E. Jones
That is, the source code of this class is from another open source project OFBIZ. It is worth mentioning that OFBIZ has always been an advocate of "commercial open source", and its authorization agreement is quite strict. Anything that uses the OFBIZ source must be copied in full text. Like the X framework, copy the OFBIZ source code, but delete the behavior of the license agreement, in fact, has constituted infringement of OFBIZ.
In addition, the compressed format for the author is Rar, and this compression format is charged for business users. For a framework project that is hoped in the commercial project, choose such a compressed format is not well. And the author also saw several .jbx files in the source package, this is the JBuilder project description file. Place these JBuilder's dedicated files in the source package, how can we rest assured those who can't afford or don't want to buy JBuilder? What's more, for your concern, the author has to worry about whether the author of the X framework will receive the lawyer of Borland.
Open source must read: When you start a open source project, the first big thing is to determine your own authorization agreement, and in the most exactly the most exactly the most formal manner - of course, you must first Understand various open source licensing agreements. For example, GPL (license protocol adopted by Linux) requires expansion and derivation of the software to inherit the GPL, so this protocol is very unfriend of the commercial application of software; the APL allows users to extend the software's extension products Privatization, easy to commercial application, is not conducive to the development of the developer community. As a leader in an open source project, it is unknown for the advantages and consistency of various licensing agreements. In addition to the authorization agreement of the source code itself, the software needs to use the library, IDE, unzipping tool, etc. need to consider authorization issues. Open source is definitely not only means "free", and the open source community has a more strong copyright awareness and legal awareness. If your open source software will bring potential legal trouble to users, it is not far from the destiny of being abandoned.
It can be seen that no matter from the perspective of the law, the X framework is far less than "Production / Stable" level - the real, with its maturity, the top can only be considered a still planned Weekly open source project. Although the author promoted on his website, as a potential user, I had to calmly say: even if the X-frame technology really attracts me, but it is far from being unproved, it determines that it cannot be in any Apply in the actual project. To make business users interested in it, the author needs to do a lot.
I just said that "even if the technology of the X-frame is really attracting me", is this a reasonable hypothesis? Below, let us enter the inside of the frame that is hoped by the author, look at its technology level. Overall structure
On the X Framework Promotion page, we saw such a propaganda:
The X framework solves many problems in the development of J2EE development: EJB is difficult, J2EE level is complicated, the DTO is too chaotic, Struts winds, and the cache is difficult to do. The X framework is AOP / ICO [Note: The implementation of "IOC", suspected of incorrectly, and excellent cache performance is its advantages.
Below is the overall architecture of the X framework:
It can be seen that in the author recommended architecture, EJB is implemented as a business logic, while POJO is used to implement façade. Is this a good technical architecture? The author has evaluated it in a blog [1]:
Let us recall first, what is the reason for using EJB? Common answers include: distributed business objects; declarative infrastructure services (such as transaction management). So, if you add a layer of Pojo's Façade in EJB, you can't use the EJB infrastructure, because the complete business operation (that is, the border) will be here, so you must re- - Declarative method - realize infrastructure services such as transaction management, safety management, remoting, caching. In other words, you lost half of the session bean. On the other hand, "distributable business objects" does not exist, because Pojo itself cannot be - like EJB - distributed so that you lose the other half of the session bean.
Continue to recall, what is the reason for using POJO-based lightweight architecture? Common answers are: easy to test; easy to transplant; "Development - Publishing" cycle is short. And if you only put the Pojo as a layer of façade, put your business logic in the following EJB, then you still can't easily test business logic, and the transplantation is naturally not mentioned, and you must endure the long release cycle after each modification of EJB. Even if you use EJB as an O / R mapping, instead of business logic, you can only get a better business performance through the DAO package, but the "modification-release" cycle is still very long, because there is still Entity Bean exists. That is, even the best aspect, this architecture has lost at least half of the lightweight architecture.
As a summary, the X framework is still not equipped with the full advantages of the lightweight architecture even in the most appropriate case, at least the agile development of small steps (because of the presence of EJB), and no Spring Frames have implemented infrastructure (such as transaction management, remoting, etc.) must reinvent these wheels; on the other hand, it does not have any advantages of EJB, and EJB declarative infrastructure, which can distribute business objects, etc. It is all use. Therefore, it can be briefly concluded that the X framework is an architecture: it combines the shortcomings of both EJBs and lightweight architectures, but abandoned their respective strengths.
When you have to use EJB, a common architecture mode is: use session beans as Façade, implements portable and tested business logic with POJO. This mode can combine both EJB and POJO's strengths. The X-frame recommended architecture mode, although it seems to be 依 葫 画 画 画 画, the effect is just the opposite, is that it is "taking it to the ruins, go to its essence".
Open source must-read: The architecture must be correct in the initial stage of open source software, the function is not perfect, the code can be unfamiliar, but the architecture thinking must be correct. Even if you don't have a perfect implementation, other people who participate in open source can help you; but if the architecture has a serious mistake, no one can help you. From the nearly two years of container project, it can be seen that there is only 20 classes, hundreds of lines of code, but it has a clear and elegant architecture, so many people have a clear function; Avalon containers provide Complete features, but the landing of the architecture forces the Apache Foundation only to discard it. So if you are interested in launching an open source project (especially the framework project), it is important to take the architecture ideas to discuss the entire community. As long as everyone recognizes your architecture, you have the opportunity to get a lot of help; contrary, I am afraid you can only get endless ridicule. technical details
Since the overall architecture is already as possible, then if the X-frame implementation is like the problem it claims, what can I solve many problems? Since the X framework is known as "AOP / IOC implementation", we select these two technologies to see their implementation and application in the X framework.
IOC
The X framework claims that he is a "IOC-based application framework". According to the definition, the framework itself has the characteristics of the "Business Code Non-invoking Framework, Frame Call Service Code", so all the frameworks are inevitably based on IOC mode. Therefore, in the framework, "IOC" is usually specifically referred to as "object dependencies" and IOC ", which is the Dependency Injection mode of Martin Fowler [2]: The creation and assembly of the container unified management component, The component itself does not contain the logic of dependencies. So, how is the X framework implements IOC?
We quickly found the interface of ContainerWrapper, which specified a main function that Pojo container core should have:
Public interface containerwrapper {
Public void registerchild (String name);
Public void register (String Name, Class ClassName);
Public void register (String Name, Class ClassName, Parameter [] parameters;
Public void register (String name, Object instance);
Public void start ();
Public void stop ();
Public Collection getAllInstances ();
Public Object Lookup (String Name);
}
In this interface, DEFAULTCONTAINERWRAPPER is implemented, these functions are forwarded to the corresponding method of the PicoContainer. That is, the X framework itself does not implement the function of the component container, which will be forwarded to other IOC component containers (such as PicoContainer, Spring or HiveMind, etc.). In the comments of the ContainerWrapper interface, we saw a quite playable words:
/ **
* Encapsulated Container, decoupling the specific application system and PicoContainer relationship.
Understand the readers of the IOC container should know that most POJO components do not need to depend on containers using PicoContainer or Spring and other containers: they only need to be the most ordinary JavaBean, just implement their own business interface. Since there is no dependence on the container, there is no need to "decouple". As for a very small number of needs to get a life cycle callback, do you have to rely on the container, let them depend on the PicoContainer and dependent the difference? What's more, PicoContainer is a more mature, more popular framework than the X frame, why users should choose the X framework such as less mature, not so popular frame holders to "decouple" in the middle? Anyway, at least we can see that the X framework provides the core function of the component container. So, how is IOC (or Dependency Injection in the X framework? It is well known that the goal of introducing IOC containers is to eliminate flooded plants (including Service Locator) in applications, and is created and assembled by the container unified management components. Regrettably, we still see a lot of factories and service locators, whether in the framework or in the sample application. For example, the author is proud of the cache section, the specific cache policy (ie the implementation of the Cache interface) is created by cachefactory, and the implementation class is still hardcoded in the factory inside:
Public cachefactory () {
Cache = new lrucache ();
That is, if the user needs to change the cache policy, you must modify the source code of CacheFactory - Please note that this is a class inside the X frame, the user should not, and there is no ability to modify it. In other words, the user is actually unable to change the cache policy. In this case, what is the use of CacheFactory?
Open source must-read: Open-Closed principles Open source software should comply with open-Close Principle (OCP): Open open and closed. If you want to provide users with any flexibility, you must use the user to use, such as derived subclasses, or profiles, cannot be required (or even allowed) users to modify the source code. If a flexibility must be obtained by modifying the source code, then it is meaningless to the user.
In the example application, we also didn't see the figure of the IOC. For example, JDBCDAO needs to use a data source (ie DataSource object), which takes this object with Service Locator in the constructor:
Public JDBCDAO () {
ServiceLocator SL = new serviceLocator ();
DataSource = (Datasource) sl.getDataSource (JNDINAMES.DATASOURCE);
The same situation also appeared in the user of JDBCDAO. That is, although the X framework provides the function of the component container, it is not (at least there is currently no), using its dependence, only uses it as a "big factory". This is a typical misuse for the IOC container: uses the container in this way, not only does not get the ability of "automatic management dependencies", but also lost the advantages of the ordinary service Locator "strong type check", another Design of "Takening it to the Essence".
Open source must read: Know yourself when you decide to use a technology in open source software, make sure you understand its pros and cons. If you use a "XX technology" label for your own software, you will only give your project negative impact on your project. AOP
In the Source Pack of the X Frame, we found some interceptors that conform to the AOP-Alliance API, such as CacheInterceptors for cache. Although not unexpected - do not find how to use these interceptors to wore logic or configuration files, we can believe that there is indeed AOP figure. However, a deep entry into this "AOP-based cache mechanism" inside, but the author discovered more problems.
From the implementation of CacheInterceptor, this is the simplest, most common cache interceptor. It intercepts the call of all business methods, and performs the following logic for each method call:
IF needs to cache
Key = (Generate key according to method signature);
IF (cache.get (key) == null)
Value = (actually invoked is intercepted);
Cache.PUT (Key, Value);
Return (cache.get (key));
Else
Return (actual call is intercepted);
It looks very good, AOP-based cache implementation should do this ... but where is the logic of clearing the cache? If we divide the business method into "reading methods" and "write methods", then this interceptor actually takes care of the "reading method". The "Write method" will change the status of the business object, so it must be cleared from the cache, but this part of the logic is not visible in the cacheinterceptor. If the cache content cannot be cleaned up in time, is the information taken from the cache is not completely wrong?
After being shocked, I found the logic of the Cache from a few Struts Actions (i.e., calling Pojo Façade's Client Code). The original X-frame so-called "AOP-based caching mechanism" only implements a leg: "Put data into cache" and "taking data from the cache" independently implemented, but "how to clear the failure data" logic It has to be scattered in all customer code. The AOP is originally to centrally concentrate the infrastructure logic of the cache such cross-cutting into a module management. This cache is implemented like the X framework, not only the cross-cutting code still four dispersion, and the relevance of the cache logic is Conceptual integrity is broken, isn't it?
Open source must read: If you have a letter in the propaganda, you must implement it completely in your software. Don't just provide a half-hanging implementation, don't let your commitment to empty. If you don't have one thing, don't promise it. Not only for open source software, this is the principle that should be remembered.
More interesting, the author of the X framework requires the domain model object inherits the Model base class and claims that this is for the need to cache - the fact is true: CacheInterceptor can only handle the child objects of Model. However, as long as the implementation of the cache section will find that this requirement is completely the author plus: Cache interface for cache objects allows any Object; while Model provides setCacheable () Wait for managing cache logic, there is no code to call them. In other words, even if we modify the CacheInterceptor, it can cache any Object, and there will be no impact on the X-frame current function. In this case, why do you have to add this level of restrictions? After returning 10,000 steps, even if the X framework will use Model's way to manage cache logic, this limit is still insufficient. After all, the current X framework also provides only the infrastructure of the cache (INFRASTRUCTURE). If all infrastructure is implemented with the "inherited a base class", the Model class is not a huge and hidden? When it truly provides all the infrastructure required by the enterprise application. Is the user's domain object no longer ported? Moreover, the idea of "judging if you need to cache yourself" is also wrong: if you can't just cache the domain object, you have to cache String, Integer, etc. Simple objects, what should I do? What should I do if the same domain object requires different caching strategies in different methods? The X framework design allows the domain objects to have too much responsibility, and these responsibilities should be transferred to Aspect via AOP. In the X frame, the AOP does not exactly its own utility.
Open source must-read: Avoid binding open source software (especially framework software) should try to avoid binding your users. The functionality that can be implemented on Pojo, do not force the user to implement your interface; if you can implement the functionality, don't force users to inherit your base class. In particular, the Java language allows only single inheritance, once requiring the user's class inherits the framework base class, then the former can no longer inherit any other base class, which is a very serious binding, regardless of the user and frame design avoid.
Written in the last
After reading this, I'm afraid that readers will inevitably want to blame me "not thick". After all, bad open source software is comparable to the number of hedges, why do you want to select the X framework? Here, I have to give you readers, all of which have a letter from open source, but it is the most important recommendation:
Open source must-read: Don't be a long-awaited source is a long-term and arduous job. Doing the source must be on the ground, make the product first discuss within the small circle, and then gradually expand the propaganda circle. Don't blow big cattle, put satellite, regard "future vision" as "today's commitment" - because once the work is busy, no one can guarantee which day to achieve. There is still a hobby: Everything likes to catch a "gift", or tied himself to the banner of "national software", which is an open source taboo. Any programmer who has done a government project is not annoying to "National Day Gifts", "New Year's Eve", and when you use your open source project, why bother to put your own into this strange circle? Of course, if your open source project is originally done to see some officials, it is another matter.
