Document directory
- New SOA business language new system architecture-SOA and BPM
SOA new business language New System Architecture -- in the wave of joint development of SOA and BPM, we must first clarify that the nature of BPM and SOA is completely different: SOA is an architectural method, while BPM is a set of process coordination management concepts. Before SOA is available, BPM products have appeared and been successfully applied. The main application scenarios of BPM are as follows: 1. Business Process Automation. This is the concept of business process automation (BPA). It automates the process according to business needs. This is what workflow technology is still doing. 2. Integrate application systems to achieve seamless communication between heterogeneous systems. This involves the concept of EAI, but the implementation method is completely different from the old EAI technology. 3. Enterprise Process Modeling analysis. This is the core of BPM. After a detailed understanding of enterprise process division, we will use a global perspective to sort out the process and provide a global diagram of the enterprise process. 4. Monitor enterprise activities to achieve continuous improvement of enterprise processes. This is the function of business activity monitoring (BAM). Bam needs to use the previous enterprise process global diagram to analyze the enterprise process effects and efficiency, provide optimization directions, and achieve enterprise-level process management. In the four application scenarios of BPM described above, each of them is closely related to SOA. From the technical point of view, SOA and BPM combined with a variety of methods, SCA WS-BPEL client and implementation model specification shows how the WS-BPEL2.0 and SCA are used together, the specific method has the following three.
Implementation of a BPEL process as a componentIn SCA, an effective BPEL process can be implemented as a component. For the definition of a component, sub-elements can be used to indicate that the component is implemented using a BPEL process. The process attribute of the child element specifies the target name of the executable BPEL process. This method starts with BPEL. Define a BPEL process first, and then include it into the SCA container, as shown in 1.
BPEL defines the type of componentWhen a component is implemented using a component defined by a BPEL process, the workflow definition of the component also determines the type of the component. If a component type only uses the WSDL interface to define services and references, we can use BPEL to obtain such a component type. This can be achieved through the "reflection" mechanism. The partner links in BPEL correspond to services and references in SCA. In SCA, the difference between a service and a reference is that in a session, which party initiates a communication for the first time, in BPEL, the partner link does not care who is the initiator of the session. Therefore, in order to map the process and Component Types in the BPEL process, you must find a way to identify the initiator of the session. In BPEL, it is possible for a partner link to initiate a session: receive a message in the activity, and receive a message in the active sub-element, receives a message from the child element of an event processor. In the above case, partner links should be mapped to services in SCA, and vice versa, to references in SCA. If the partner link is mapped to a service in SCA, the service type corresponds to the partner link type in BPEL. If the partner link is mapped to a reference in SCA, It is opposite to the service. 2. The service component service can have the WSDL porttype interface.
Add SCA extension for BPELWe can add an SCA extension to BPEL to generate an SCA component type definition and use it to complete SOA assembly. For example, a variable declaration in a BPEL can contain an SCA extension, which indicates that this variable represents the attribute of an SCA component. From the above discussion, we can see that the combination of BPM and SOA can help BPM achieve more functions. BPM In the SOA environment is different from the old workflow in the non-SOA environment as follows: 1. cross-organizational business process description language and tools. In the early stages of workflow system migration, we often find that the processes of different organizational units and departments within the same enterprise adopt different Descriptive methods, for example, the Account Management System of the four departments A/B/C/F adopts a certain workflow system, the order and sales management system of A/B/D/E adopts another Workflow System. This situation is particularly evident within a large enterprise group, affecting the business collaboration among various business units and refining and promotion of business best practices. BPM is committed to describing the language and tools of business processes across different organizations, avoiding the situation where all departments of an enterprise talk about business processes and communicate with each other. 2. Unified Process architecture. A workflow designed by an enterprise based on a single management topic usually lacks overall considerations for business operations in the enterprise, and is limited to the business needs of the Department or the business, the processes between different departments and management topics cannot be linked, information sharing and transmission are difficult, and a large number of process breakpoints exist. BPM connects and coordinates processes to avoid islands of processes. BPM aims to form an end-to-end process system, improve the efficiency, cost, and quality of the entire business process, and meet customer needs in a fierce market competition. 3. No "Party A's advantages. If we use a general workflow system as an interface, we find an interesting phenomenon, that is, the "Party A advantage" Phenomenon of the service provider. Generally, a workflow system must interface with another existing system. A workflow system is an existing system, that is, the existing system has the "Party A advantage ". In this way, the workflow system must be implemented according to the technical specifications of the existing system, which is more and more far away from the "cross-organization business process description language and tool, let alone "cross-Enterprise Business Process Management ". BPM establishes a fair agreement between the "workflow system" and "existing system", without the "Party A's advantages ". 4. Continuous improvement of the process. Due to the existence of the workflow system, the relevant business personnel usually ignore the embedded business processes. the business department lacks intuitive understanding and attention on the embedded processes of the information system, and the improvement of the workflow system is very complicated, let alone continuous improvement. However, BPM helps business personnel closely follow the relationship between embedded information system processes and other business processes, and becomes the most important factor to improve the overall process operational efficiency of enterprises. 5. The nature of bpm soa. SOA is an architectural method for creating more flexible enterprise infrastructure, while BPM is a set of coordinated Business Process activities. SOA allows you to easily connect business processes to the basic system, saving time and IT resources. In comparison, linking a process to a traditional application usually relies on a large number of different proprietary technologies. Furthermore, turning to SOA while adopting BPM can promote reuse of SOA components, thus minimizing the complexity of business processes. 6. BPM must be enterprise-level. To implement bpm, we must establish a circular management philosophy of process strategy, process design, process implementation, and process monitoring: Develop a process strategy starting from the enterprise's development strategy, break down strategic indicators into the target system of the Process, implement the strategy through the process, and sort out, design and optimize the business process according to the process strategy; business processes are implemented by adjusting the organizational structure and Information System. Process compliance management and process performance monitoring are used to monitor the process execution. Business Process Design is adjusted based on the results. BPM and SOA have already joined forces. An enterprise's business process should be well organized, analyzed, and planned from a strategic perspective, at the tactical level, appropriate enterprise system architects need to be identified to correctly implement the hybrid and step-by-step deployment of BPM and SOA, and continuously improve the performance based on BPM process analysis, identifies the most valuable business process model to implement enterprise-level SOA. On the basis of enterprise-level SOA, it gradually accumulates to promote BPM applications more deeply and extensively. The rational adoption of software products that integrate SOA and BPM will result in a multiplier effect. View the source of this Article
