What is a service-oriented architecture (SOA)?
Service-Oriented Architecture (SOA) is a component model that links different functional units of the application to the contract between these services. The interface is defined in a neutral manner, which should be independent of the hardware platform, operating system, and programming language that implements the service. This allows services to construct in a variety of such systems to interact in a unified and universal manner.
This feature having a neutral interface definition (no forced binding to a specific implementation) is called a loosening between services. There are two points of loosely coupled systems, one is its flexibility, and the other is that it can continue to exist when the internal structure of each service of the entire application is gradually changed. On the other hand, it is impossible to connect the interface between the different components of the application, and it is very fragile when some or the entire application needs to make some form of changes.
The need for loosely coupled systems is derived from business applications to become more flexible according to business, to accommodate changing environments, such as regular changes, business level, business focus, partnership, industry status, etc. Business-related factors, which will even affect the nature of the business. We call the business that can be flexibly adapt to the environmental changes in-Demand service, in on-demand services, once you need, you can make the necessary changes to the way you complete or perform tasks.
Although the service-oriented architecture is not a new thing, it is a more traditional alternative model of object-oriented model, and the object-oriented model is tight, and there is more than 20 years. Although SOA-based systems do not exclude the use of object-oriented design to build a single service, its overall design is a service-oriented. Since it takes into account the object within the system, although SOA is object-based, it is not an object-oriented. The difference is that the interface itself. One typical example of the SOA system prototype is a common object requesting agency architecture, CORBA. It has already seen a long time, and its definition is similar to SOA.
However, the current SOA has different because it relies on some updated progress, which is based on Extensible Markup Language, XML. The interface is described using an XML-based language (called Web Services Definition, WSDL)), the service has been transferred to a more dynamic and more flexible interface system, non-previous CORBA interface description language (Interface Definition language, IDL is comparable.
Web services are not the only way to implement SOA. The previous CORBA is another way, which has a message-oriented middleware system, such as the IBM's MQSeries. But in order to establish an architecture model, you need is not just a service description. You need to define how the entire application executes its workflow between services. You especially need to find the conversion point between the operations of the business and the operations of the software used in the business. Therefore, SOA should be able to associate business processes with their technical processes and map the relationship between the two. For example, the operation of payment to the vendor is a business process, and your part database is updated to include the new supply of goods is a technical process. Thus, workflows can also play an important role in the design of SOA. In addition, the workflow of dynamic services can not only include operations between sectors, or even operate with external partners that do not control you. Therefore, in order to improve efficiency, you need to define how the relationships should be recognized, this policy often uses the form of service-class agreements and operational strategies.
Finally, all of this must be in a trust and reliable environment, as expected, based on the agreed terms, based on the agreement. Therefore, security, trust and reliable messaging should play an important role in any SOA.
What can I do with a service-oriented architecture?
The needs of SOA come from need to make the business IT system more flexible to adapt to changes in the business. By allowing strong definitions and still flexible specific implementations, IT systems can use existing systems, but also ready to make some changes to meet their interaction between them.
Let's take a specific example. A clothing retail organization has 500 international chains, which often need to change the design to catch up with fashion. This may mean not only need to change style and color, or even need to replace cloth, manufacturers, and deliverable products. If the retailers and manufacturers are not compatible, the replacement from a vendor to another may be a very complex software process. By using the WSDL interface flexibility in operation, each company can maintain their existing systems, but only match the WSDL interface and develop new service-level agreements, so they do not have to fully refactor their software systems. This is the level of business, that is, they change their partners, and all business operations are basically unchanged. Here, the business interface can make a little change, while the internal operation does not need to change, which is done, just to work with external partners.
Another form is internal change. In this change, the retail organization now decides that it will rent some places in the chain retail store to small stores who specialize in popular clothes, which can be seen as a store in the store (Store- In-store) business model. Here, although most of the company's business operations remain unchanged, they now need new internal software to handle such a rental arrangement. Although the internal software system can withstand a comprehensive overhaul, they need to do a big impact on the interaction with the existing supplier system while doing. In this case, the SOA model remains uncovered, and the internal implementation has changed. Although new aspects can be added to the SOA model to join the duties of new rental arrangements, the normal retail management system can continue as usual.
In order to continuing internal changes, IT managers may find that new configurations can also be used in another way, such as renting a poster for advertising. Here, new business proposals are derived from a flexible SOA model in new design. This is a new achievement from the SOA model, and is still a new opportunity, and such new opportunities may not have it before.
Vertical changes are also possible, in this change, retailers are completely transformed from selling their own clothing to a place to rent in the store. If vertical changes are completely started from the bottom, there will be a significant change in the SOA model structure, and there may be new systems, software, processes, and relationships with one of them. In this case, the advantage of the SOA model is that it considers problems from the perspective of business operations and processes rather than from the perspective of applications and programs, which makes business management to clearly determine what needs to be added according to the operation of the business. Or delete. The software system can then be constructed to be suitable for business processing, rather than other means they often see on many existing software platforms. As you can see, here, the ability to change and adapt changes in the SOA system is the most important part. For developers, such changes may occur in the range of their work or in their work, depending on whether there is change to know how the interface is defined and how they are Interact. Unlike developers, architects' role is to cause large changes to the SOA model. This division of labor is to let developers focus on creating a functional unit as a service definition, and the architect and modeling staff concentrate on how to properly organize these units, it has been more than ten years. Usually use a unified modeling language (UML), and describe the Model-Driven Architecture, MDA).
What is the technology of building SOA?
SOA itself is how to organize the abstract concepts together. It relies on more specific ideas and technologies that implement and exist in software in the form of XML and Web services. In addition, it requires security, policy management, reliable message delivery, and support for accounting systems to work effectively. You can also further improve it by distributed transaction processing and distributed software status management.
The difference between SOA services and web services is design. The SOA concept does not exactly define how the service is interactive, but only how the service is mutually understanding and how to interact. The difference is to define how the strategy between the process and how to perform the difference between the process. On the other hand, the web service communicates between services that need to be interactive, there is specific guidelines; from tactical implementation SOA models is the most common SOA model in the SOAP message passed by HTTP. Thus, from essentially, the Web is one of the specific modes of implementing SOA.
Although we think the web service is the best way to implement SOA, SOA is not limited to web services. Other protocols that use WSDL directly to communicate and communicate through XML messages can also be included in SOA. As noted elsewhere, the MQ system of CORBA and IBM can participate in SOA by using new features that can handle WSDL. If two services need to exchange data, they also need to use the same messaging protocol, but the data interface allows the same information exchange.
In order to establish appropriate controls for all this information, a new software object is added to the framework of the SOA architecture in order to apply security, policies, reliability, and accounting requirements. This object is the Enterprise Service Bus (ESB), which uses many possible messaging protocols to be properly controlled, and the stream may even be the transfer of all messages between services. Although ESB is not absolutely necessary, it is a component that correctly manages your business process in SOA. The ESB itself can be a single engine, or even a distributed system consisting of many simplicity and sub-ESBs, these ESBs work together to maintain the operation of the SOA system. In concept, it is developed from the early, such as message queues and distributed transactions, computing these computer science concepts. From a developer's perspective, they use tools to know the capacity of SOA and allow developers to effectively use SOA objects. This will design SOA models, develop services, and service objects, and test SOA applications These processes include coming in and forms a whole. Thus, the development of developers must prepare for service-oriented application design / development, soad.
What is the relationship between SOA and other technologies?
SOA can be used together with many other techniques, however, components packages and polymeric plays an important role. As mentioned earlier, SOA can be a simple object, complex object, and a collection of objects, including many objects, and flows of other processes, or even a total set of applications that output a single result. In addition to the service, it can be seen as a single entity, but in itself, it can have any level of complexity (if necessary). For performance considerations, most SOA services do not drop to the particle size of a single object, and is more suitable for large and medium-sized components.
SOA is not a language except that may be inseparable from XML and WSDL. You can implement the service in any programming language, as long as this programming language can generate a service and can be used with WSDL. SOAP itself is not absolutely needed, but it is a common messaging system. Therefore, you can use almost any programming language and a platform that supports WSDL to implement member services in SOA.
There are many components that must be connected to SOA based on General Object Broker Request Architecture (CORBA) applications. Although Interface Description Language in CORBA is conceptually similar to WSDL concept, it is not strict, so it first needs to be mapped to WSDL. In addition, you need to use a more advanced SOA protocol (such as a protocol for processes and policy management), not similar concepts in CORBA. Keep in mind that this is the case where the CORBA component (represented as a service) needs to interact with the SOA service; in the CORBA model, all independent subsets can still work as before.
The model drive architecture that is proposed by the object management group and implemented in many IBM Rational products has strong correlation with the concept of SOA at a more abstract level. MDA is based on such concepts, any software process can be defined as a model or even a meta-model (ie model model), and then convert these models and meta models into actual components of the application. Therefore, MDA creates a model that compiles to software applications first, and the software application is then compiled into an executable program so that you can run on the platform. MDA does not distinguish between two concepts of services and objects, but it does allow the model to be composed of other subset model itself, which is similar to the concept of process aggregation in BPEL (one core component of SOA). SOA and Web services are independent of programming languages, but Java is one of the main development languages. You can use a well-known Java interface and a wide range of protocols that have an advantage to build developers who are building this model. Java acts as a function of developing each service, managing data objects, and other characters that are logically encapsulated in the service.
Another important relationship between SOA and the Web is the concept of autonomous computing and grid computing. The concept of autonomous computing is applied to managing the scope of the distributed service architecture. Specifically, it is to help maintenance strategies and service-level protocols, and the total stability of the SOA system.
In addition, grid calculations can be used with the SOA system with two levels. Grid is a form of distributed computing, which utilizes interactions between distributed features and services to provide calculation support for SOA applications. In this case, the grid has played the role of the framework, in which some or all individual services are implemented. Therefore, the SOA application can be a consumer of grid services.
On the other hand, the grid itself can be constructed above SOA. In this case, each operating system service is a member of the entire SOA application, and the SOA application is the grid itself. Therefore, a separate grid assembly can be communicated using a web service, but also interact in SOA. All in all, the grid system can be SOA itself, and it is also possible to provide services to build application-level SOA models.
How can I build a SOA system?
The benefits of using SOA are not only a software development process, but also a business development process. With SOA has four levels, your implementation can span from creating specific software services to a process of fully converting your business model to an on-demand system. To get further information, you should read the article "The Four Levels of SOA Adoption" at the end of this part.
The first level is the easiest because it simply creates a separate service. This is explained in detail in the "SOA novice entry" listed in this section and provides more resources.
In the second hierarchy, you can not only create services, but also begin to integrate business functions into SOA. This involves multiple hierarchical integration, including application integration, information integration, process integration, and integration of the entire system. Migrating to a service-oriented architecture is an important article that introduces questions in this level.
The third level involves converting your company IT infrastructure to the SOA model, and the fourth level using SOA is focused on the translation of your business model so that it is a model in need.
From the perspective of IT professionals (compared to the business layer), you want to create an SOA application, you usually have experienced four stages: build, deploy, use, and manage. In the build phase, you can define business models or processes, software models, and SOA models. After that, you can create a set of services that can be reused with the published general interface. In the deployment phase, you extract the created service and put them in an executable, manageable environment. In the stage of use, you assemble applications based on the SOA and software models mentioned earlier, and test their software quality and non-functional demand, such as performance, scalability, etc. The application is now ready and can be used for users. The final management phase is a long-term process. In this stage, you can monitor and manage security and usage, and compare performance in many aspects of service-class agreements or policies that you may have developed with SOA.
These are the conceptual phase of the life cycle of SOA. In order to make the actual working role corresponding to these phases, there are many characters that need to be added to the creation of the SOA application. These roles may be engaged in the same work, or may even have even multiple teams across multiple teams. The role divided in Rational Unified Process (RUP) is very good to express the role concept.
RUP roles include project managers, analysts, architects, modeling staff, developers, testers, and deployment and operators. SOA is almost completely moving this role division method. The only difference is that the work of SOA modeling staff is to extract conceptual software models, and test it according to the SOA model and resources of IT infrastructure. The developer role can also include a secondary role like an assembler (in the stage of use), the role of the assembly person is to extract a separate service and build the actual SOA application based on the defined model. Whether it is explicit or implicit, these characters exist in support of SOA.
Personal experience: Soa's loose coupling characteristics can adapt to the flexibility of business needs, and it can continue to reduce the cost of software secondary development when the internal structure and implementation of the service changes. SOA is better than a service intermediary to link different systems, different platforms, and achieve the interaction of various services and data to meet the needs of rapid market.
Wen Xiaoyi
