SOA newbie
What is a service-oriented architecture (SOA)? Service-Oriented Architec-Ture, SOA is a component model that links the application's different functional units (called services) to define a good interface and 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 build in a wide variety of 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. The benefits of loosely coupled systems are two points. It is its flexibility; the other is that it can continue to exist when the internal structure and implementation of each service that make up the entire application gradually changes. In contrast, the interface between the different components of the application is closely linked to its functions and structures, and thus they are very fragile when some or the entire application needs to make some form changes. Demand for loosely coupled systems is derived from business applications to become more flexible according to the changes in business, to accommodate changing environments, such as regular changes, business level, business focus, partnerships, industry status, and other business These factors that 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. Dividing the interface using XML-based languages (called Web Services Definition Language, WSDL), the service has been transferred to a more dynamic and more flexible interface system, non-previous CORBA interface description languages (Interface Definition) Language, IDL) is comparison. 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 between services should be defined, which often uses the service-class agreement and operational strategy. 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 flexible specific implementations, IT systems can use existing systems, but also ready to make some changes in the future to meet the interaction between systems. 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 considering problems from applications and programming, which makes business management to clearly determine what needs to be added according to business operations. Modify 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, depending on whether there is a change to know how the interface is defined, and between them How to interact. Unlike developers, architects' role is to make a big change in the SOA model. This division of labor is to let developers focus on creating a service definition function unit, while allowing architects and modeling people to concentrate on how to properly organize these units. This approach has been more than ten years of history, usually with universal modeling language, UML, and describes model-Driven Architecture, MDAs. What is the technology of SOA? SOA itself should be "how to organize the software together" abstract concept. 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 require interaction, there is specific guidelines; the most common way to implement the SOA model from tactics is the SOAP message passed through HTTP. Therefore, from essentially, the web service is one of the specific methods of implementing SOA. Although we think that 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 include the design SOA model, development services, and service objects, and test SOA applications, including these processes come in and form 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, the SOA can be a simple object, complex object, object collection, and a flow of many objects, including the flow 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-driven architecture that is proposed by the object management organization (Object Management Group, OMG) and the model drive architecture 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 maintain strategies and service-class protocols, and the overall 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 to build a SOA system? The benefits of using SOA are not just that it is 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. The first level is the easiest because it simply creates a separate service. 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. The third level involves converting your business IT infrastructure to the SOA model, and the fourth level of SOA is used to convert your business model to make it a model of the on-demand. 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 deliver 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.
How to improve my SOA skills? Skill's acquisition depends on what type of professionals: information analysts, software architects, software developers, software quality analysts, system administrators, etc. As mentioned earlier, the concept of SOA spans all of these work roles. Therefore, it is very helpful to understand the role of each working role. Next, you should be familiar with the technical concept included in each role. Information analysts and software architects should be familiar with model-driven architecture (MDA) and UML 2.0. Software developers and programmers should understand the programming interface, MQ, and other protocols, MQ and other protocols, and how to protect interactions, and the concept of workflow processing. Quality analysts and system administrators should understand the implementation of the SOA process model and the actual SOA functional architecture, and how to develop a separate service how to affect the overall performance of such distributed applications. System administrators should also know how the application security and trust model work, and how the application uses policy affects the operating system platform and network system.
