SOA Toxic----SOA Business Development Platform (III)

SOA is toxic
That day in the QQ group, and a lot of internet users to discuss the topic of SOA, found that the industry's advocacy of SOA, not too much aircraft, said is the concept of high level, is too much, is talking about how to develop SOA. But the lack of an intermediate level of implementation, that is, the concept level to project managers and programmers down the side, rather than always soar in the architect, master planner this level.
Because now a large number of programmers, are the new generation of programmers, they write less code, do less software projects, can not understand how much code will be resolved, but also can not understand how the project will be more customized how to solve. No problem of pain, of course, do not quite understand why to synthesize the function. During the discussion, it was found that many programmers, even the functional level, did not understand how the functions in their code came into being, they were generated by the events of the components in the programming process, such as the onclick function. They themselves are not active or rarely active in encapsulating functions. And many people also put the function just stay in order to public call, or a code is more than 1500 lines, it is not clear thinking, just cut the code into another function, and my initial understanding of the function is exactly the same. There is not much depth to the encapsulation of a true understanding of a function. Let alone pain and pain, further application of object-oriented and component-oriented methods. Because the amount of code written is not much, there is no problem, so there is no need for more advanced methods. Many people write object-oriented and component-oriented code because the 3GL development language and the IDE are now determined by nature, rather than by the programmer's own initiative to object-oriented or component-oriented. However, some awakened people began to imitate the use of object-oriented, but the real benefit of the object-oriented understanding is not very deep, but also in the suit phase. A lot of people wrote COM +, wrote EJB, but they are the IDE tool and the other person's component specification is determined by their own internal code to write the idea does not match it, or the accumulation of code.
So, at this stage, so that we can use service-oriented, many people certainly do not understand and feel that there is no need. There are also some technology-driven companies that are starting to use service-oriented development, but the idea is still to write COM +, where the code shell is component oriented, but the inner code mentality and component-oriented are irrelevant.
Technology is to solve the problem, not to show off the fashionable. The customer does not understand the technology, if your technology does not bring the obvious value benefit to the customer, the customer will not pay for your technical cost. In the past, there are a number of customer CIO staff, very concerned about the latest technology products, if you are PB do, he is. NET to do, you will buy. Net. But now China's information more popular, the implementation of the project case more than the past n times, there are N-times the project died or failed to declare. There have been a lot of painful lessons, so many blind aimless pursuit of technology software companies and CIOs suffer.
SOA seems to be another level of component-oriented, but SOA is very complex when programmers write code to see code. If you're not facing complex business and business investments, it's better to touch SOA less.
The last blog I wrote, I am from the programmer to write the code level to tell you the origin of the component-oriented. But on the other side, from an architectural perspective, component-oriented is not what I'm talking about. It's just that the code needs to be a little more encapsulated.
In the industry, there is OMG organization, namely Object Management Group. The group is backed by companies like IBM, HP and Bea, and almost all the world's top IT companies are joining in. All industry unified understanding is that the world of software, should be the various functions packaged into a component, the programmer as long as the components within the implementation of a good, packaged, the implementation of internal specifications and external interface specifications to meet the unified standard on OK. Then, this component needs to be plugged into a component platform. This is like what video card, sound card, network card, have a standard interface, can accept the signal scheduling of the motherboard, so all inserted into the motherboard, accept the unified management of the motherboard data bus. Therefore, the industry believes that software should be the same, in order to achieve software flexibility. This is a component-oriented benefit from the height of the architecture. I didn't say that last time, because most people are programmers, they're more concerned about how their code changes more flexibly, and they feel a little bit more empty and far away from the architecture. So, with the foreshadowing of the previous article, this article is much better.
As we all know, COM + has component specifications, EJB has component specification. NET has component specification, CORBA also has component specification. And this software motherboard is what, in COM + has a COM container, formerly known as MTS, now called Component Services. NET's component container is the. NET platform, which has a framework, a virtual machine, and a component container. Microsoft has become a package to shield technical details so that everyone feels that Microsoft's product is simple. And the Java side, afraid of all the modules are tied together, so each module is separate, the EJB component container independent of the middleware, Java, as well as the virtual machine and framework.
I know a lot of people are confusing webservice and SOA. SOA also has component specifications, that is SCA, the full name is the service component architecture. It's about what the service-oriented component should be. The CORBA component specification, which was developed in the past, is component-oriented rather than service-oriented. Service-oriented components that are more than a layer of higher-level services for component-oriented components.
There is a component specification, and there must be a communication specification between components. CORBA has ORB,EJB middleware specification, COM + has the actual landing, but because of Microsoft's closed to this technology, I do not see too much of this specification. To SOA, is there a communication specification between components?
Yes. But SOA does not have its own set of independent communication specifications. This is a good open mind for SOA. Now that we have so many specifications, why do we have to reinvent the wheel, why don't we use the specs and protect the investment. As a result, SOA leverages the WebService communication specification, or it can apply the JMS communication specification. This is where many people easily confuse the roots of WebService and SOA.
But webservice just defines how the interface is going to be, you have to unify, but your internal code how to write, WebService regardless of you. Originally WebService's invention is for the heterogeneous call, this is WebService's goal, is also the key point. So webservice does not have a component specification. Because the world, the three major mainstream. NET, EJB, CORBA, have their own component specifications, why do you have to redo the component specification?
Many people think that you control how I write the code inside, I tell you webservice interface, you call can return the result you want not OK. Yes, for the caller of the service, there is nothing that can be invoked to achieve the requirement on OK.
However, it is the need of the container to control how you write the code inside. If you put the webservice in a bunch, and then these webservice call each other, this is just an integration platform. The integration platform is concerned with how these webservice are managed.
And SOA wants to do more than that. It is a set of ideologies. It does not just want to manage your interface, communication between your components, but also to manage your components.
Further, SOA also wants to manage your data exchange.
In the past with WebService, the exchange of XML, but the XML inside also have a format, and this format used to be no specification, as long as the two sides agreed on how to resolve the OK. But SOA does not look like this. It also worked out SDO. Specify the internal format of the data you exchange. A lot of people see this, and you should want to understand why SOA defines SCA specifications. As we all know, the exchange of data, if the internal format is unified, so that the use of exchange data, rather than their own custom set, do not know the definition of flexible inflexible, rigorous. SCA is also designed for the same purpose, if you write the code inside, are free to do their own thinking code stack, so even if the application of SOA, can not achieve the flexibility of component-oriented.
We all want to build a business platform, we hope that our functions can be flexibly modified, rather than move a lead. But without a specification, how can we build a platform that is flexible and scalable? We are now all in their own experience to build a business platform, to feel that they are flexible to build. But the industry has given the standard, so set up a platform, with such thinking, with such a standard, built out platform can achieve flexibility. But many people are still trying to contemplate what kind of architecture can be achieved flexibly.
SOA is a very open architecture for service-oriented components. Whether you are a COM component, an EJB component, a. NET component, a Coraba component, is used. NET virtual machine, or JVM, as long as the compliance with this SCA/SDO specification, you can build a flexible platform. And there's already a flexible platform, and that's the ESB. ESB is also not a very new thing, it is also a mixture of WebService technology, message middleware technology, component container technology, BPEL process engine technology, component container technology. The essence is to integrate component container Middleware + message middleware + process Orchestration Middleware +webservice, if the SCA/SDO standard is met, then this ESB can be said to be an SOA ESB.
SOA is to protect existing investment as far as possible, without creating independent kingdoms, existing virtual machines, middleware, WebService, integration technology, no need to waste. And can achieve a higher level of unity. You can of course put the existing. NET component or EJB component is packaged as an SCA component, or you can develop SCA components directly.
We used to face such a variety of technology, our vision blurred, no choice. Now that we have SOA, we need to select this higher level, more abstract level of specification, and we can implement components and component platforms that are as flexible as hardware motherboards and graphics cards.
Of course, this platform just gives us a foundation platform, we want to develop our business, but also need to build on this basis of our business functions need basic functions, our specific business functions, need to be based on our own business base layer to develop, rather than on the ESB directly develop SCA components. This is well understood and we are not in. NET platform to develop our business functions directly, and often build a business base Class library, everyone in the business base Class library to develop business functions more easily. Of course, this business base Class library is not built up, no architecture, no compliant component architecture, then the base Class library will make the business developers feel very twisted, not to do this layer of basic code.
So say, understand, conform, just feel smooth and free. Do not understand, can not adapt to the idea, forced to base on the development, can only feel twisted, think why this layer so in the way.
SOA, service oriented, component, architecture. These three key words. Architecture, it is certainly a layered chunking. So there are component containers, there are components, there are component communication protocols, there are Component Services inline orchestration tools and execution engines.
However, I always feel that the service choreography is still not good. Because I used to have business components and process components for component development. And BPEL is the goal of working with process components. Now looking at the XML of BPEL, I always feel twisted. I vaguely feel this is not the best way to organize XML, but it is not suitable for describing processes. Describe the process, now the most suitable, but also the most versatile, most flexible, should be JavaScript.
My personal opinion believes that the future of the focus of the decisive battle, must be JavaScript. And JAVASCRITP's battle, not only now has been burned to the Chrome browser, burn to flex action script, burning to the open API, burning more promising than restful WebService atom app, the future, It will also burn into SOA in the enterprise market.
JAVASCRIPT, did you see it?
I admire my friend Zhou, who has studied in JavaScript for years, and is very diligent, and I believe he has seen the future.