Bluedavy, a new employee from brothers, was just an indirect mentor when I started osgi (I read his osgi Advanced Course and shared some practical experiences). I met bluedavy for the first time on the Internet at noon, after talking about it for a while, I have a little time in the afternoon to read three new articles about osgi, SCA, and service framework. I have some experiences and share them here, I have a basic understanding of osgi, so the analysis may not be in place. I can only talk about ^ _ ^, but I look forward to cooperating and communicating with each other later.
Osgi --> in the last three or four months of SCA, the platform needs to be restructured. The front-end framework is not included in the scope of the first refactoring, reconstruction focuses on the reconstruction of the backend overall framework and the design and implementation of the Service Framework. For this part of the service framework, the main requirement in the early stage is to prepare for future modularization, so I just studied osgi. The advantage of osgi is that it achieves real business component modularization (Implementation class, various resources, class libraries, etc.), just like its metadata bundle name, it is completely packaged. In fact, this is also true for the origin of osgi. It was first used in the design of automobile manufacturing. Like the embedded development of j2s, this kind of good encapsulation of component interaction (Interface Stability ), dynamic Loading and replacement all provide excellent support. The current Java application development also pays more and more attention to the encapsulation and reuse of business modules. Dynamic Loading and independent management of class libraries are all future trends. However, after a period of practical operations, I considered finding a new technical framework specification to implement my service framework. Why? First of all, I mentioned 1.1 in my article with bluedavy. The osgi service framework did not provide external display calls. At the same time, it was difficult for my equiox to be embedded on the platform, unless the unified osgi framework is adopted from top to bottom, it is not convenient to interact with external third-party systems. Furthermore, the classloader self-management mechanism, one of the highlights of osgi, is also a constraint. In actual development, it is necessary to do so. Due to the increasing reliance on third-party open-source projects, this issue becomes more prominent, let's just say that the Stax API framework in jdk1.6 is implemented by any third party. The loading method is also to achieve loading during dynamic runtime search, at this time, the unit test was okay, and problems with Web iner emerged. However, osgi isolation needs to deal with complex dependencies. In this case, there will always be a problem that cannot be solved. In the end, osgi is not very consistent with my needs. At least after the platform strategy changes, osgi is not the preferred technical implementation. Because the company now needs to build an application access platform and an Saas-based operating platform, osgi's strength lies not in the implementation of this distributed, heterogeneous, loosely coupled service framework, it is specialized in implementing a single-host homogeneous and modular service framework. Therefore, osgi has come to an end. The old saying goes, there is no bad technology. Only the abused technology is the best. Switching from osgi To sca does not mean that osgi is inferior to SCA and there is no comparability, I just said that SCA is more suitable for my current application scenarios and there is no need to use chopsticks. SCA and service framework my blog already has a lot of articles on SCA application design implementation. I will not discuss them here, just to explain why I chose SCA when designing the service framework. In fact, the technical selection, experiment, practice, and application of the service framework are all coming step by step. The Application Service Framework (ASF) is a service framework that is implemented based on SCA specifications. It is also a required feature of the application access platform in the future. Modularization: The SCA specification clearly defines the encapsulation interaction of service modules. (Many people think modularization is a concept. The increasing scale of the system, frequent changes in inter-module coupling requirements, modular integration testing, and dynamic loading requirements will have a great impact.) Openness: A friend in my blog asked me why I had to come up with SCA to implement these functions more than enough with spring. There were a lot of independent web service frameworks. Khhe, if so, it proves that SCA is not fully understood. SCA is just a framework specification, and all the above mentioned are implementation technical means. Spring can also be used to implement the SCA framework, it is easy to implement, but it is far from simple to construct n composite using N spring factories to reflect the openness of SCA. In fact, Now ASF has integrated spring, Hessian, Jetty, axis2, JMS, etc. To put it simply, if you want to integrate it with an SCA implementation, that is to say, SCA is not actually a technology, but a technical implementation specification. Any technology can be implemented according to this specification, that is, an SCA extension. The SCA framework is like Eclipse, SCA is like Eclipse's plug API and flow design. How to make a good recipe, how to make a full view of the cook, what material to use, what pot shovel, the cook has the say, if the technology is compared with SCA, it will be farther and farther away from SCA. SOA: When I went to bea to attend the SOA Annual Meeting, I attended several technical courses on SOA. Due to time, several teachers quickly talked about the general concept of SOA, but the most prominent one is Web Service. In fact, they think this may mislead many people. As I mentioned, many of my friends who have just been familiar with SOA say that they are using Web Services for service downtime. But in fact, they have made the same mistake with SCA, web Service is only a technical implementation method of a certain part of SOA. The mature application of WS is undoubtedly the technical support of SOA, but the management of services by SOA is actually the most important part. The support of the SCA framework on WS mainly comes from its openness that can be integrated with a variety of good open-source applications, Jetty + axis2 (integration of cxf to meet rest-type service release will be considered in the future) jetty + Hessian can be used to call and assemble internal distributed services. In terms of service management, flexible framework specifications have enabled service call assembly to achieve transparency. Loosely Coupled and isomorphic services are well supported in the SCA framework. The only thing to consider is that, in the future, BPM can be integrated to support higher-level service flows. Some time ago, I considered whether to integrate an Open-Source ESB into the framework to provide more service management functions. But I looked at several good Open-Source ESB frameworks, many functions are already implemented in ASF and are relatively heavy, so there is no further work for the moment. The service assembly and call management mentioned in the service framework of bluedavy has been well supported by ASF. SCA & osgi then let's look back at the relationship between SCA and osgi. In fact, I think it will be more vivid to use a metaphor. Now it is like the fact that our platform needs to develop a weapons attack range that can be close to or far away. I chose a bow and arrow, SCA is like a bow and arrow design, and ASF is like a bow, a rocket, an ice arrow, a wooden arrow, and so on. osgi is a variable arrow, and the arrow is changeable to defeat the enemy. The integration of osgi in ASF serves as an internal extension implementation and plays its biggest role in a variety of suitable application scenarios. The reason why osgi is not widely used in Internet applications is that, first of all, there are few scenarios that require modular dynamic loading and deployment of applications, especially in the production environment, the complexity of classloader management is also very important because the current large applications are often more effective and convenient to redeploy and start. However, in terms of future trends, one of the key points of jdk7 is the dynamic nature of osgi, and osgi has been used as JSR, so we can see the future of osgi. No good or bad, only suitable and unsuitable, on-demand design, simple things, is the most important principle of design.
