Analysis of the Relationship between Microsoft service layer guidelines and osoa architecture (SCA, SDO, etc.) (non-original)

Analyze the correspondence between the Microsoft mode and the service layer guidelines of the practice team and the osoa architecture system (SCA, SDO, etc.

Note: This document assumes that you are familiar with some important concepts of SOA, including SCA, SDO, BPEL, ESB, and WCF, message queue, and workflow in Microsoft. This is because the architecture diagram of the two SOA technology systems will be compared below to introduce some interesting things.

The architecture diagram in osoa is first introduced:

Next is the figure in the article "Microsoft service layer Guidelines", which links to the article.

Let's first talk about Microsoft's architecture diagram:

In the Microsoft diagram, the business (Business Layer) and services (service layer) have two components:
Serviceinterfaces: used to expose service interfaces. Its core content is to "encapsulate" the implementation of the business logic layer, and these services will be consumed by the objects that call these services (custom ).
Messagetypes: Message type, that is, the Data Type exchanged on the service layer. The data structure is encapsulated by the message structure to support different operations. Including: Command Message (data), document message, or other message contracts that communicate between the service provider (Message contracts) and consumer (consumers ).

We can see that the front-end business presentation layer (Presentation) and external system collaboration use the service interfaces provided by this layer and the defined message type data.

Note: The serviceinterfaces in the above two layers are similar to the serviceregistry feature in the osoa standard body (as mentioned later), while messagetypes can be seen as the "Microsoft version" of SDO in the osoa system ".

The difference between the business layer and the osoa diagram is too large. Because osoa also has an enterprise business layer (enterprise business layer), and introduces the basic service architecture layer (infrastructure service layer) and business service layer (business service layer) and the service composition layer can also be collectively referred to as the service layer.

Microsoft uses business workflows, business components, and Business Entity classes to encapsulate applications (applicationfacade ), this structure is similar to the business logic encapsulation method used in our daily development. In addition, its businessworkflows and the osoa Process Orchestration layer have similar design intent, because the Process Orchestration service contains all the business processes. And other languages such as BPEL are used to implement the Process Orchestration service. This explains why many people regard Microsoft's workflow as a "transformation" of the BPEL. Of course, the difference between the two is still very large :)

Business Components (business components), like SCA in osoa, follow the descriptions in the document of the "mode and practice" group:

After a user Process collects the data it requires, the data can be operated on using
Business rules. The rules will describe how the data shocould be manipulated and transformed
As dictated by the business itself. The rules may be simple or complex, depending on
Business itself. The rules can be updated as the business requirements evolve.
Data Operations in its components must be performed according to business rules. The rule describes how data is operated and transmitted. The business rules may be simple and complex, depending on the business itself.

Here, we can make a bold guess:

Although Microsoft's solution does not include the Process Orchestration layer, business service layer, and Service Composition Layer in osoa, its business components should also support services (components) combination functions and similar Process Orchestration layer functions (provided through workflow ). The combined business components will appear in a new form of service. Of course, you can also regard these components as a new "component ". 1. These components are developed
After the workflow is completed, it is either published as a service interface or organized and driven by the business workflow to complete the corresponding business operations (the workflow can also be published as a service ).

Here we will introduce what is"Business Process":

A business process is a series of business activities integrated. Each business activity completes a specific business step throughout the process. We can regard business component as a specific business activity, and business process as a business workflow. Of course, a business workflow can also be seen as a composite business task. It can also be seen as a business component and can also be accessed through publishing through WCF. Speaking of this, I feel that Microsoft's business components and businessworkflows seem to overlap, because the business orchestration function provided by the workflow, I can also provide it through the component combination method (even in serviceinterface of the service layer), which is indeed at the development level. But if the business changes frequently, do I still have time (development and testing time) to write another composite business component? The workflow is easy, but the business logic is modified between the drag and drop operations (of course, this is also one of the reasons for the introduction of BPEL ). Of course, the premise for reflecting this advantage is that the business components designed and developed at the beginning are short enough.
Small (moderate granularity), easy to combine (interface granularity ). In addition, it can easily communicate message data through business rules (different protocols ),
Routing, transmission, etc.

Of course, I have read another article that seems to be"Articles from the same mom":
Entity Framework in Layered Architecture

The structure is as follows:

Simple but clear, isn't it? It also provides the corresponding instance code, which can easily let us know how to develop software of this architecture.

After talking about the above, some people will say that there is an ESB in osoa (if you don't understand ESB, you must treat SOA as a SB), but Microsoft does not seem to have such a document, however, after careful analysis, it is not difficult to find that there is still an ESB shadow. For example, the three basic elements in cross-cutting in the figure: security, communication, and operation management are what ESB emphasizes.

In addition, serviceinterface focuses on service component release (WSDL, UDDI, etc.), registration, deployment, and other related content. Message routing and transaction communication are also implemented through WCF, so this is invisible (because it has become a basic function of WCF ). Therefore, it can be considered as follows:

The result of the "Golden combination" of WCF and workflow can be viewed as a simplified version of the ESB function.

Of course, the role that WCF plays here is decisive. We only need to bind keywords with different attributes and configure the communication nodes in the config of the server and client based on our own design ideas. Of course, it has been said that BizTalk can also be considered a heavyweight implementation version of ESB. But if I don't know about this server, I can't say anything more.
Of course, there are some Open-Source ESB projects on codeplex, such as ESB. NET and impleservicebus (nservicebus Lite version only provides message queue implementation functions.

According to the content above, we can see that Microsoft wants to"Take your own path and let osoa talk about it!". There must be development languages, tools, frameworks, technologies, and other resources in hand. Why should we be subject to human resources? It is better to do what we want, this is also the idea it expresses in the "SOA in the real world" text.

========================================================== ========================================

Compared with Microsoft's architecture diagram, the architecture diagram of osoa needs to be more complex, at least with more layers. Of course, in Microsoft's architecture, the functions and architecture implemented by these layers are merged into the business layer (see the preceding section ). In all fairness, the osoa diagram is the clearest and clear SOA architecture roadmap I have seen, and its layered structure also takes into account EAI factors.

The first is the unique layer of SOA (silver-white graphic area ):

Service infrastructure layer:Infrastructure Service Layer
This layer is mainly non-operational. These services are basic services and do not contain any business logic. Pure Data Reading services are also basic services. They only use access to the underlying data storage layer as a service. This layer can also be called a functional service layer. Basic services depend on the current enterprise data layer and enterprise business layer.

 
Business Service Layer:Business Service Layer
It can be considered that every step in the business process is a service, that is, a service. The granularity of a service depends on the business activities that the service needs to implement. The business service layer depends on the current enterprise data layer and enterprise business layer. This layer and the service composition layer below can be similar to the Business Component function in the business layer of the Microsoft architecture above.

Service combination:Service Composition Layer
The service that implements the combined business activities (as mentioned above) is called a Service combination. Composite business activities constitute an abstraction layer that hides detailed internal business activities. In addition, it is easier to add new services without making any changes to the existing interfaces. This layer depends on the business service layer and basic service layer. During design and deployment, program assembly can be used to create a composite service. During the design, the Assembly needs to write the calling sequence of the business service (or basic service. This implementation method is called program Assembly during design. During deployment, the program Assembly determines the order through configuration, that is, the call order is achieved through the appropriate configuration language. This method requires the support of the underlying software.

Process Orchestration layer:Orchestration Layer
The Process Orchestration service contains all business processes. A language such as the Business Process Execution Language (BPEL) is used to implement the Process Orchestration service. The Process Orchestration service consists of the required business services, service groups, and basic services. This layer can also be called the business process layer. This layer is similar to the business workflow function in Microsoft architecture.

Service Registration:Service Registry
The service registry record information about available services. Service Registration Information does not have to be limited to the Uniform Description and discovery and Integration Protocol (UDDI) or Java Naming and Discovery (JNDI) interface standard. It can be stored in any form of convenient service searching. The registration information includes detailed information about Process Orchestration service, composite service, business service, and basic service. This layer is the current business directory of the enterprise. Microsoft WCF provides this function.

Message transmission layer:Messaging
The message transmission layer includes business message interaction in the service layer. These messages are responsible for message transmission in the message layer. The definition of these messages is also part of this layer. The message transmission layer also provides message system support for message transmission between other layers. The message system facilitates interaction between service layers. For example, an enterprise service bus can be considered as a service message system. Microsoft WCF provides similar functions.

Service Management:Service Management

The service management and monitoring system is part of the service management layer. The monitoring system can provide useful service-related information, such as usage, processing capability, and other performance-related information. These systems can be used to extract real-time information related to key business performance indicators. Service management tools are also part of this layer, including security auxiliary management tools, load balancing tools, and other tools related to service management. This layer can also be called the SOA management layer. The business activity monitoring tool can provide support related to this layer.

In addition to the special layer of SOA above, it is the usual layering Method for application development:

Enterprise data layer: Data Layer
The enterprise data layer is the data repository of an enterprise. All the data required for a successful business operation is part of this logical layer. The data includes database information, file systems, hierarchical directories, heritage storage systems, and other storage media. This layer is the data layer in the traditional multi-layer architecture.

Enterprise Business Layer: Business Layer
The business layer consists of the business applications (and logic) of the enterprise. It includes applications (and logic) that begin with Java platforms of. NET and Enterprise Edition, or various other technologies ). The logic of the routine is also included in this layer. Simply put, this layer is the backbone of the current business of the enterprise and the business layer in the traditional multi-layer architecture.

Enterprise front-end application/channel: Presentation Layer
Front-end applications and channels of all businesses are part of this layer, including the entire desktop and Web Front-end that relies on enterprise backbone systems. Business channels include external B2B interface systems, such as transaction systems and address validation systems. This layer forms the presentation layer in the traditional multi-layer architecture.

Through the architecture diagram of osoa, we can easily see Where an enterprise or company wants to integrate services or develop SOA application software. For example, for business integration, the data layer, business layer, and performance layer are our existing IT software assets, and we need to be between the presentation layer and business layer, add the code that uses the SOA design architecture. If we develop a new SOA system, we only need to follow this architecture, and in the future, when the system is integrated with other external systems, it is easy to perform secondary development as long as the code in the SOA special layer is added or modified (of course, the business layer Enterprise Business Layer Code may also be modified ).

"Of course, this figure can also help determine the gaps between the current environment and the target SOA facility, and serve as a reference for developing reusable SOA frameworks, map the product environment to the logical structure to effectively determine the SOA-related products required by the project. "

Speaking of this, there are still a lot of things I haven't mentioned, such as the question of developing business components, what is the form of BPEL, etc. Let's talk about it later.

Well, I have made some subjective "nonsense" and hope I have not understood these figures and related concepts. If you have different opinions, you are welcome to discuss them in your reply. YesSOAThis topic has a wide coverage, many new terms, and is closely related to the technical fields.