As the information technology (IT) industry moved away from, or found alternatives to, the mainframe computing paradigm, smaller, more localized computers began to emerge. As this infrastructure of smaller, more localized, computers began to grow, a need to make these machines communicate with each other evolved. This need to have co-located computers “talk” with each other, first, brought about the client/server architecture, and then, distributed systems architecture with distributed data and functions, from roughly 1995 to 2005.
Point-to-point integration between a client and server was, in the early days of system integration, the main method of communicating. The client had to know about the server, and the server had to know about the client. In addition, each of the integrated computers had to use the same protocol and then use “language translation” in order to communicate.
The client/server and its point-to-point strategy brought about what today is called the “spaghetti integration” picture. Each client/server system has its own language schema or data model. If another application is added, every application needs to communicate with that new application through an additional custom interface. Each interface does a different language translation. One can see how the maintenance and support of this architecture can become unwieldy very quickly.
Enterprise application integration
在1990年代末,为了简化点-to-point communication, a new strategy called Enterprise Application Integration (EAI) became popular. This is the so-called “hub-and-spoke” method of integration, in which all communication comes through one central point before arriving at its final destination. The hub is responsible for routing, language translation, transaction sequencing, and mediating content and protocol of the message before ultimately sending it on to its final destination.
This EAI approach was much simpler to create and maintain than the point-to-point approach. With the hub-and-spoke approach, the sender only needs to know how to communicate with the hub, rather than having to know how to communicate with n-number of end points. In essence with this approach, the logic for message routing, content and protocol mediation is moved from the sending and/or receiving machine to the hub. Therefore, the applications (spokes) need only be concerned with the business logic they are to provide, rather than how to communicate to multiple end points.
With the hub-and-spoke method, the routing, mediation and transformation logic in the hub can also get difficult to maintain without complex configuration management practices. There is a tendency for the business logic to creep into the hub, which makes changing that logic more difficult as more and more content builds up in the hub. Also, with EAI, you are still dealing with large, monolithic, and disparate applications that communicate in different ways.
The industry is now moving toward a services-based approach to integration, in which smaller, self-describing pieces of logic interact and communicate together on an Enterprise Services Bus (ESB). The ESB is one of the major components of a services oriented architecture.
SOA is an IT systems model that gives companies flexibility in the way they create business applications. SOA is not just focused on application integration, but also application construction from existing IT assets. The architecture allows for the creation of composite business applications from independent, self-describing and interchangeable code modules called services. These services are available for use on a services bus and can be arranged together, into a business process, or composite application, using process choreography. Most important, services are based on business concepts, not IT ones.
Gary Mintchell, gmintchell@automationworld.com,
Editor in Chief ofAutomation World, adapted this article from the MESA International(www.mesa.org)white paper, “SOA in Manufacturing Guidebook.”
Point-to-point integration between a client and server was, in the early days of system integration, the main method of communicating. The client had to know about the server, and the server had to know about the client. In addition, each of the integrated computers had to use the same protocol and then use “language translation” in order to communicate.
The client/server and its point-to-point strategy brought about what today is called the “spaghetti integration” picture. Each client/server system has its own language schema or data model. If another application is added, every application needs to communicate with that new application through an additional custom interface. Each interface does a different language translation. One can see how the maintenance and support of this architecture can become unwieldy very quickly.
Enterprise application integration
在1990年代末,为了简化点-to-point communication, a new strategy called Enterprise Application Integration (EAI) became popular. This is the so-called “hub-and-spoke” method of integration, in which all communication comes through one central point before arriving at its final destination. The hub is responsible for routing, language translation, transaction sequencing, and mediating content and protocol of the message before ultimately sending it on to its final destination.
This EAI approach was much simpler to create and maintain than the point-to-point approach. With the hub-and-spoke approach, the sender only needs to know how to communicate with the hub, rather than having to know how to communicate with n-number of end points. In essence with this approach, the logic for message routing, content and protocol mediation is moved from the sending and/or receiving machine to the hub. Therefore, the applications (spokes) need only be concerned with the business logic they are to provide, rather than how to communicate to multiple end points.
With the hub-and-spoke method, the routing, mediation and transformation logic in the hub can also get difficult to maintain without complex configuration management practices. There is a tendency for the business logic to creep into the hub, which makes changing that logic more difficult as more and more content builds up in the hub. Also, with EAI, you are still dealing with large, monolithic, and disparate applications that communicate in different ways.
The industry is now moving toward a services-based approach to integration, in which smaller, self-describing pieces of logic interact and communicate together on an Enterprise Services Bus (ESB). The ESB is one of the major components of a services oriented architecture.
SOA is an IT systems model that gives companies flexibility in the way they create business applications. SOA is not just focused on application integration, but also application construction from existing IT assets. The architecture allows for the creation of composite business applications from independent, self-describing and interchangeable code modules called services. These services are available for use on a services bus and can be arranged together, into a business process, or composite application, using process choreography. Most important, services are based on business concepts, not IT ones.
Gary Mintchell, gmintchell@automationworld.com,
Editor in Chief ofAutomation World, adapted this article from the MESA International(www.mesa.org)white paper, “SOA in Manufacturing Guidebook.”
![Mps035 Sm 1200x628 D[2]](https://img.automationworld.com/files/base/pmmi/all/image/2021/03/MPS035_SM_1200x628_D_2_.604a4a336bc60.png?auto=format%2Ccompress&bg=fff&fill-color=fff&fit=fill&h=146&pad=5&q=70&w=340)
