On the road-application service framework growth notes based on SCA specifications (I) (Under serialization ...)

Everyone is growing at different stages of their lives. Parents record their past growth processes and record their own growth processes in adulthood. Programmers and architects all have their own "children". No matter whether their children are good or bad, they are excited for their children to make a little achievement. Now, I am also cultivating my own "child". Although I have to pay a lot during its growth, I am still watching it grow, it makes me feel that all the efforts are worthwhile. Therefore, in this way, we can record its growth and various difficulties and solutions, provide yourself with information that may be helpful when developing "children" for other programmers and architects. I. I also moved from the Business Development Group to the platform architecture group when I was a new subsidiary of SCA. The platform architecture group was responsible for improving xplatform to support business development in multiple business product lines, xplatform is a rapid development platform based on the concept of MDA. However, with the increasing requirements of business department development flexibility, xplatform becomes increasingly inadequate in terms of customization and modularization. After the technical strategy was adjusted in March, I started a huge xplatform reconstruction plan, and I was assigned to consider the underlying architecture reconstruction and service framework design. At that time, when we first considered modularize the underlying layer, we felt that osgi was a good direction. Therefore, we adopted the osgi policy when restructuring the cache module in the early stage of the service framework to dynamically Replace the cache, however, we found that this modularization is not what we need. Osgi is completely modularized. Even the dependency of each bundle is maintained and managed by itself, which provides a solid foundation for dynamic loading and unloading, however, it also provides the most difficult problem to solve: the complex classloader mechanism. Looking back at the current business development scenario, the answer is often no if there is such a demand for strong module isolation. Dynamic Loading and unloading is indeed a good feature, but as a commercial product, especially for Internet applications, application modules deployed in a cluster do not need to be loaded and deployed separately. On the other hand, osgi focuses on developing modular solutions for standalone services, rather than SOA solutions. At present, Internet applications need to be interconnected to a large extent, while modularization is the basis, but it is not the final solution. At this time, I began to pay attention to SCA. I was deeply impressed by the modular scalability of the specification itself, a practical specification for SOA implementation. SCA and osgi have many similar ideas in modularization. In SCA, composite is the bundle virtual body. The advantage of SCA is that it is only a standard, but a design concept, without restrictions on implementation languages, platforms, and other details, this is also a trend of Internet applications. Information sharing maximizes the value of information, which is the goal of enterprise applications. To achieve this goal, we need to put aside the details in the implementation process. For example, programmers tend to focus on the best technologies used to develop the most dazzling applications, while the boss is concerned about how to meet user needs in the shortest and shortest ways, it is the responsibility of the architect to achieve a win-win situation between the two. Now that we have determined the path of SCA, let's start. The first step is to look at the specifications. The SCA specifications on osoa are very detailed. Although the SCA specification has been in use for some years, it takes not long to formally incorporate it into osoa and become a widely recognized specification. Sun and Bea both use similar products abroad, however, Tuscany has not been widely promoted. In the Apache incubator project, Tuscany is the most famous open-source practice project of SCA. For me, I certainly joined the open-source family. When I was in touch with Tuscany, it was still milestone2 before 0.9, but so far, it has been released to the V1 version in just a few months. It can be seen that it has developed rapidly. I have seen more and more attention on Tuscany in China. The biggest feature of Tuscany is its strong architecture scalability, which is also the architecture system required by SCA specifications, to achieve the modularization and scalability of SCA, a flexible infrastructure must be supported. I used Tuscany to set up some common scenarios described in the SCA specification, such as simple Java Bean, spring integration, asynchronous callback, and RMI remote calls. Of course, many problems were encountered, because Tuscany itself is also in the hatching process, the biggest problem is that there are few relevant documents. As a beginner, you can only use the demo to understand the general usage, if you encounter problems, you will learn by tracking its Code. However, this process also gives me some understanding of the architecture of the entire framework, as Daniel said, the real architecture is a concept of operation period, rather than the design period. The design period is actually the SCA specification itself, and the part of the operation period is the real system architecture. After all, pre-research is doing experimental work. Whether it can be productized still needs to be tested by practice. The reconstruction of xplatform was officially started. The platform architects organized a seminar on internal restructuring technical solutions. I presented the results of the previous research and the idea and implementation of SCA, at the same time, the technical implementation feasibility is introduced based on our restructuring objectives. Another architect proposed a solution to use spring to implement the ESB model of SOA. After comparison and discussion, my plan was affirmed, but I did not have a thorough understanding, after all, if SCA is implemented in the xplatform architecture, the underlying architecture of each product line will be affected. If problems cannot be solved in the future, this responsibility is not limited. At the same time, in the past few years, EJB is a good negative example. A standard concept is important, but whether or not the implementation environment is suitable determines success or failure, I was not sure whether SCA was suitable for the future of Alibaba software technology. Finally, I proposed a design scheme to reduce risks. The bottom layer of the platform is divided into two parts: Basic Service Framework (BSF) and Application Service Framework (ASF ), the former is mainly used for plug-and-play interaction of core components inside xplatform, while the latter is used for assembly, release, and interaction of upper-layer applications. Alisoft-xplatform-core-service-framework: This is the sub-project directory name of the service framework project and the first step on my sca path. After taking this step, I can no longer look back. I often use the old horse's sentence to motivate myself: I may not be the smartest or the hardest person, however, persistence may make me better than others. Tuscany opened the way to sca practice for me, But Tuscany is not as beautiful as it looks. It is just the beginning of the problem to take the SCA path suitable for the service framework.