Microsoft SOA in the real world Note 10-Chapter 2
Service CategoryWhen examining the service category, we will notice two major service types: services that are originally infrastructure and provide general functions that are not considered part of the application, and services that are part of the application, providing application building blocks. The software uses a series of different general functions, including the underlying services provided by the operating system, such as memory management and I/O processing, as well as the C Language Runtime Library (RTL), Java platform or.. NET Framework. Solutions created using SOA also use common features, such as service verification frameworks (such as WCF) and a group of services used to support distributed computing. These services are named bus services ). Bus Services can be further divided into communication services, which provide messaging functions such as message routing and publishing and subscription mechanisms, as well as utility services ), provides functions such as service discovery and federal security, which are irrelevant to message transmission. Using coarse-grained and high-level building blocks can further improve the efficiency of software development. In the component-oriented era (such as VB or Delphi), the popular rad development environment provides the ability to quickly and easily combine function modules to create new applications, these functional modules are provided by existing build blocks and have specific application domains. Examples of such components include more common GUI controls, database access components, and more specific chart or event log components. The combined application in SOA also uses this attribute as the building block. These building blocks are called application services ). The Application Service can further serve Entity services, which are used to expose and operate business entities, functional services, and activity services ), it is used to implement application building blocks (sometimes called components or modules) and process services, used to combine and orchestrate functional services and activity services to implement business processes. Shows a possible combination of the service categories described above. Bus Service is a general function that does not provide any clear business value, but it is a necessary infrastructure for implementing business processes in SOA. Bus services are usually outsourced or core components that provide services for multiple applications and are generally centrally managed.
Communication ServiceThe Communication Service is responsible for transmitting and transmitting messages to and from the system, and transmitting messages within the system without considering the message content. For example, a bridge can pass messages back and forth through network boundaries (that is, bridge two different disconnected networks ), or pass through the Protocol boundary (for example, passing queue messages between WebSphere MQ and MSMQ ). Examples of communication services include forwarder, publish and subscribe system, router, queue, and gateway. Communication services do not maintain any application status, but in many cases, they are configured to be used in related applications. A specific program may need to instruct and configure how the communication service transmits messages within the application to implement inter-component communication in a loosely coupled architecture. For example, a content-based Router may require the application to provide routing instructions so that the router can know where to forward the message. Another example is the publishing-subscription server, which sends messages to registered subscribers by applying the message content filter. The application can set this filter. In both cases, the communication service does not process the message content, but uses a part of the message as a command to determine the Message destination. In addition to specific application requirements, restrictions imposed by security, specification, or other types of constraints indicate that users need to obtain certain permits to use the functions provided by communication services. You can set these licenses within the scope of the application (that is, to allow the application to use the service without considering specific users of the application ), it can also be set within the user's scope (that is, to allow specific users to use the service without considering the specific application that the user is using ), or set it within the application and user scope (that is, to allow specific users to use specific applications when running specific applications ). For example, the publish/subscribe service can be configured to restrict only subscribed users to access specific topics. Other application-level functions provided by communication services include monitoring, diagnostics, and business activity monitoring (BAM ). Communication Service can provide application statistics, such as message traffic mode analysis (for example, the number of messages passing through a bridge per second ), error Rate report (for example, the number of errors in the soap sent by a vro every day) or performance indicator at the business level (for example, the number of purchase orders that come in through a partner's gateway ). Although these features may only target specific applications, they are no different from those that control message streams. This information is generally provided by common functions of communication services and is usually configured by applications. The statistical information provided is usually consumed by a specific part of the application, and the application knows how to process the information (for example, generating a security warning in the data center, or update a bam-related chart on the CFO computer screen ).
Application ServiceApplication Services provide universal services unrelated to specific applications and are used to handle problems unrelated to message transmission. Like communication services, they provide functionality as part of the SOA infrastructure and have nothing to do with specific application logic and business processes. For example, in loosely coupled applications, the Discovery Service can be used by components to find other components based on specific conditions (for example, services deployed in the pre-production environment can find other services that implement specific interfaces. These services are also deployed in the pre-production environment ). Examples of application services include security and identity services (such as identity Federation services or security token services), discovery services (such as UDDI servers), and message Conversion Services. Like communication services, specific applications can also instruct and configure how application services perform operations on them. For example, the message conversion service can convert a message style to another message style, which is based on the Conversion shadows provided by the application that uses the conversion service. Although the application service does not retain the status information of any application, the status of the application service may be affected by changes in the system status. For example, adding a new user to an application may need to update the trust certificate settings in the security token service. Different from communication services, customer services interact directly with application services. These application services process and reply (if necessary) messages sent by customer services. Application Service users may need to configure corresponding licenses for them to use these services. They can be configured within the scope of applications, users, or program-users. For example, the Discovery Service only provides services for users who have passed Domain Verification (that is, those users have the trust certificates published by the Windows Domain Controller ). Like communication services, application services can also provide application-level functions, including monitoring, diagnostics, and business activity monitoring (BAM. These features include statistical information on usage patterns (for example, how many users in an organization use federal identities for authentication) and error rates related to the business (for example, number of failed Message format conversion due to bad format of incoming messages. Consistent with communication services, these features are also common features of application services. They need to be configured and applied in specific solutions.
Application ServiceApplication Services are those involved in business process implementation. They provide clear business value and exist in multiple ways, from general services that can be applied to any combination application in an organization to special services that can only be applied to a single combination application, and the services between the two that can be used for two or more combined applications.
Entity ServiceEntity services unbind business entities in the system and provide unified access services. They may be seen as data components in business processes ("Terms"): employees, customers, sales orders, and so on. Examples of Physical services include customer services, which are used to manage customer information and order services, and to track and manage orders placed by customers. The entity service abstracts data storage (such as SQL Server and Active Directory) and exposes the data stored in one or more data sources in the system through the service interface. Therefore, it is certain that the entity Service manages the persistent state of the system. In some cases, the information managed exceeds the boundaries of a specific system and is used in multiple systems or even all systems in the Organization. Entity services provide the following functions: Provide object-level crud interfaces, add related operations for specific problem domains, and support application features and user scenarios. An example of operations in a specific domain is to expose a method named findcustomerbylocation in the customer service. This method can be used to determine the customer ID through the given customer address. The information managed by physical services is usually longer than the business process. Information exposed by Entity services is usually structured, rather than relational or hierarchical. For example, the entity service can aggregate information stored in multiple database tables or even multiple scattered data, and publish the information as a single customer service entity. In some cases, especially for convenience, the implementation of the entity service chooses to expose the data as dataset rather than the XML data that is strongly formatted. Even if dataset is not a strict entity, these services are still treated as Entity services in terms of classification. Users of Entity services may need to configure corresponding licenses for them to use these services, which can be configured within the scope of applications, users, or program-users. These permits can impose restrictions on data access and modification. They can be applied at the "row (entity)" level, or at the "Column (entity element)" level. An example of applying restrictions at the column level is as follows: an HR system can access the social insurance number and home address of the employee entity, while a print check service can access the home address. An example of a row-level restriction is as follows: A expense report program allows the manager to view and approve the expense reports of employees who report to him, rather than handling reports that do not report to employees. Errors in Entity services are mostly limited to finding alternative data sources, or they are not compensated at all. For example, if the entity service cannot access the local database, it tries to connect to the remote copy of the database to obtain the required information. To support system state consistency, Entity services usually support tightly coupled distributed atomic transactions. Services that support distributed atomic transactions participate in their transactions, and Commit Changes in the state in data storage to the results of distributed atomic transactions. To reduce the coupling of state changes, Entity services can support more loosely coupled reservation modes, regardless of whether or not distributed atomic transactions are supported. Entity services are usually built internally into a packaging container for an existing database. Typical implementation of these services is to map databases to entities and expose them as service interfaces through manual coding, or to generate ing code and service interfaces through the software factory. The Web Services software factory from Microsoft's patterns & practies group is an example of a software factory. In some cases, databases (such as SQL Server) or data-centric applications (such as SAP) may provide the ability to access data through service interfaces, this eliminates the need to create and maintain separate entity services. Entity services are usually used in more than one combined application, so they are usually centrally managed.
Function ServiceFunction services enable the business-level functions of an organization. They represent activity-centric construction blocks (or "Atomic Verbs") that form the business processes of an organization. A few examples of functional services include third-party interface services, such as credit card processing services, which are used to interact with external payment gateways in a combination application. This combination application supports credit card payment and value-added construction blocks, for example, the scoring service is used to process and calculate the ratings that users can score in applications (such as help pages, books, and vendors), or communication services, for example, the email gateway service can be used in all combined applications and sent to customers and employees by email. Functional services can be further subdivided according to the service categories they provide (such as third-party interfaces, value-added constructor blocks, or communication services). Further differences are beyond the scope discussed in this chapter. Function services expose service interfaces specific to the features they provide. In some cases, existing (legacy) or newly added business functions may be different from the way organizations expose functions as services, or even cannot expose service interfaces. In this case, the function is usually packaged into a thin service layer to expose the function API as a service interface, so as to be consistent with the way the Organization exposes the function. For example, the credit card processing service company has released an HTML-based API that allows users to enter web forms. Similar to the above features, they can be encapsulated by in-house-created-and-managed-fa C-service, providing easier programming access for features. This kind of appearance service is not transparent and masks the actual features of the functions behind the service, so that the corresponding functions can be replaced without changing the service interface. Therefore, this kind of appearance service can be used as a function service, and the corresponding function is only the implementation details of the appearance service. Function services usually do not directly manage the application status, but use the entity service in the application to change and modify the status. If a Function Service performs status management, the status is usually temporary, and the duration is shorter than the time required to complete the business process involved by the function service. For example, the service that provides the parcel transportation quotation form may need to record the request sent to the transportation provider until it receives a response and then deletes the record. Further, the function service that implements the workflow will manage the persistent and temporary execution status information of all currently running workflow instances. Because most features are "stateless", there are obvious features such as Event Logs to manage and encapsulate the status. Users of Entity services may need to configure corresponding licenses for them to use these services, which can be configured within the scope of applications, users, or program-users. Generally, the access permissions of function services are set at the application level. A single user's license is usually managed by the process service using functional services, which simplifies management and prevents access failures in the process. The Error Compensation in function services is limited to the service level Exception Handling (lupus) and service level agreement (SLA) that meet the function ). For example, the email gateway service can put email notifications in the queue in the background to facilitate delayed delivery. That is, if the email service encounters a problem, it will be resent after the email connection is restored. Express delivery services usually compare the rate and delivery time of four suppliers (such as FedEx, UPS, DHL, and a local service company, may compensate for a vendor's unavailability by ignoring the failure and continuing with the comparison of the rates that it was able to secure as long as it has ed at least 2 quotes. These examples show that failure may cause lower efficiency. This downgrade can be expressed as follows: response time (when the customer email service is used), service quality (for example, the express delivery service can only compare two quotations instead of four quotations) as well as many other aspects, it is necessary to describe them in the Service's systemic and SLA. Function services support distributed atomic transactions and subscription modes. Most function services do not manage resources that require state management through atomic transactions, but function services can pass the atomic transactions they contain to the Entity services they use. Capability services are also used to implement a reservation pattern over Entity services that do not support that pattern, and to a much lesser extent over other capability services that do not support that pattern. Function services can be developed and managed internally, purchased from a third party and managed internally, or "rented" from an external supplier and used as SAAS, services are developed, maintained, and managed externally. During internal development, function services can be implemented through rule code or declarative workflow. If implemented through a workflow, function services are typically modeled as short-term running (atomic, non-episodic) business activities. For long-running business activities, errors may occur or compensation is required, which is usually classified into process services. Function services are almost always used for multiple combined applications, so they are usually centrally managed.
Activity ServiceFunction Services implement business-level functions, or some activity-centric business logic elements (or "constructor blocks"), which are unique to specific applications. The main difference between activity services and function services lies in their application scope. A function service is an organizational resource, and an activity service is used in a much smaller scope, such as a single combination of applications or a single solution (composed of multiple applications. After a certain amount of time and enough reuse, activity services can evolve into functional services. An active service is usually created to facilitate the decomposition of complex processes or reuse of specific functional modules. These functional modules can be used in multiple places of a specific process service, it can also be used in different process services in applications. The motivation for creating activity services comes from multiple aspects, such as the strength of the Organization, security requirements, and standardization requirements. An example of an activity service used to break down a scenario is, A vacation eligibility confirmation service that due to security requirements separates a participant part of a vacation Authorization application's behavior such that part cocould run behind the safety of the HR department's firewall and access the HR department's protected databases to validate vacation eligibility; an example of an activity service used to share features is: a blacklist service that provides information on A customer's blacklist status such that this information can be used by several process services within a solution. Like function services, activity services provide service interfaces specific to the functions they provide. It is possible to encapsulate existing functional units as active services, especially in the case of a transition from an existing system upgrade to an SOA solution. Like function services, activity services usually use entity services in applications to change and modify the application status instead of directly managing the application status. If a Function Service performs status management, the status is usually temporary, and the duration is shorter than the time required to complete the business process involved by the function service. However, due to their slightly larger granularity and the cases where activity services are used to wrap an existing system, it is more likely than activity services will manage and encapsulate application state. Active Service users may need to configure licenses for them to use these services, which can be configured within the scope of applications, users, or program-users. Like function services, access permissions for active services are usually set at the application level. A single user's license is usually managed by a process service that uses functional services. The active service has the same error compensation and transaction usage methods as the functional service. Activity services can be developed and managed internally, and implemented through rule code or declarative workflow. Like function services, if implemented through workflows, activity services are typically modeled as short-term running business activities. Active services are usually used in a single application or solution, so they are managed separately (for example, at the department level ). If an activity service evolves to a functional service, service management is usually switched to centralized management.
Process ServiceThe process service connects data-centric construction blocks and behavior-centric construction blocks to implement the business processes of the Organization. The process service combines the functions provided by the activity service, function service, and entity service, and connects them with the business logic in the process service. These process services create a blueprint for defining business operations. An example of a process service is the procurement order processing service. This service receives procurement orders, verifies and checks the blacklist service to identify legal customers, uses credit verification service to check customer credit, and passes Inventory (entity) confirm the service inventory, use the express service to arrange delivery, notify the customer that the order has been completed and the ETA of the goods through email gateway, and finally mark the order as completed in the order list. Process services can be combined into workflows of other process services. However, due to its long-term running characteristics, they cannot be converted into function services or activity services. Because process Services implement business processes in the Organization, workflows are often started, controlled, and monitored through the user interface. The service interface that these services expose is typically geared towards consumption by an end user application, and provides the right level of granularity required to satisfy the use cases that the user facing front-end implements. monitoring business processes sometimes need to expose the isolated monitoring interfaces of BAM information. For example, the Order Processing Service can report the number of unconfirmed, processed, and completed orders, and their statistical information (the average time for processing orders, the average order size, and so on .). Process services usually need to manage the application status related to the process during the process activity. For example, the status of the purchase order service management order is not completed until the process is completed. At the same time, the process service also maintains and tracks the current steps of the business process. For example, the process service implemented as a workflow maintains the execution status of all currently running workflow instances. Process service users may need to configure licenses for them to use these services, which can be configured within the scope of applications, users, or program-users. Generally, process service access permissions are set at the user level. Process services seldom participate in Distributed atomic transactions because they support long-running business activities (well-known long-time transactions) and error compensation occurs at the business logic level, workflow that may involve participants. When calling the services they use, the process service can also use distributed atomic transactions. Process services are usually developed and managed internally, because they capture the core value in the organization, that is, "secret spices", which determines the way organizations engage in business. Process services are designed to enable process agility (I. e. to be easily updatable) and the process that they implement is typically episodic in nature (I. e. the execution comprises of short bursts of activity spaced by long waits for external activities to complete ). therefore, the process service is best implemented as a declarative workflow, and an integrated server (such as bzitalk server) or workflow framework (such as a Windows workflow basis) is used for implementation ). Process services are generally used in a single application, so they can be managed separately (for example, at the department level ). In some cases, reusable business processes can be provided and used as SAAS. When designing business software, we should remember that our goal is to deliver agile systems for business support, rather than for service-oriented (so ). So is a way to make business and technology agile, not itself. This must particle ly be borne in mind with references to Web Services. achieving the agility that so often accompanies web services is not just a consequence of adopting web service protocols in the deployment of systems, but also of following good design principles. in this article, we consider several principles of good service architecture and design from the perspective of their impact on agility and adaptability.
