Service-based modeling and architecture

Preface

This article discusses the important parts of service-based modeling and architecture, as well as the key activities required for analysis and design to build a Service-Oriented Architecture (SOA. The author emphasizes selection, identification, formulation and implementation
ServiceThe technologies required, their
Process and combinationAnd enterprise level that implements and ensures the quality of service required by SOA
Components.

Introduction

Contents
There were many rumors about the time presented by Service-oriented ubuntures (SOA) and its Web Service implementation --
Some are based on facts, but some are not based on facts. Analysts have predicted that Bo scholars have claimed that the professor has lectured that the company has rushed to sell their products as SOA Products
-- Frequent loss of SOA is not the key point of a product. IT is a bridge between business and IT. IT relies on business by using a series of design principles, models, and technologies.
Service.

ZDNet recently reported that "Gartner predicts that at least 2008 of enterprises will use SOA as the" Guiding Principles "for creating demanding applications and processes in 60% ".

There is a great demand for developing and implementing SOA. Therefore, if SOA is not only related to products and standards that help implement it (such as through Web Services), what additional elements do you need to implement SOA?
Service-based modelingOther behaviors and components are required, which do not exist in traditional Object-based analysis and design (OOAD. "
Service-based analysis and design elements "This article describes some initial causes and explains why you need more content than OOAD. It also describes why business process management or enterprise architecture (EA) and OOAD are not an appropriate means of managing analysis and design. Similarly, the name in IBM Redbook is"
Mode: Service-Oriented Architecture and Web Services.

However, you also need to pay attention to some additional important considerations. First, the current OOAD method does not identify three important elements of SOA:
Service,
Stream, And implement the Service
Components. You also need to be able to clearly identify, develop and implement the technologies and processes required for services, their processes and combinations, and enterprise-level components that implement and ensure the quality of services required.

The
Second, we need to replace examples to better differentiate SOA.
The two key roles have different requirements: service providers and service consumers. Third, an application built for an enterprise or business line must now be promoted to a supply chain and
Public to partners who may combine, federate, and encapsulate applications into a new application. This is the concept of service ecosystem or service value network.

This
Is only a small improvement from "distributed objects. It is about the value created through the network: for example, when a partner uses Amazon.com and Google
The combination of search and eBay
Services are combined to build their own hybrid solutions. Or when travel agencies go deep into the air ticket booking system and coordinate with car rental companies and hotels, update their records and send travel plans
To your electronic files. No matter what kind of application, if you want to successfully create SOA, you need more than good tools and standards. You need some standard steps to support your SOA
Life cycle: A technology used to analyze, design, and implement services, processes, and components. Therefore, for anyone interested in enterprise application development, understanding the detailed steps in service-based modeling and architecture is
Very important.

Before I describe these steps in detail, we should first understand what you are going to do:
What is SOA and what does it look like?In
After defining the concepts and ideas behind SOA, I will describe the SOA layer and how you record key architecture decisions in each layer. These layers help you build a blueprint for SOA.
SOA is exactly what you need to implement SOA services, process and component integration, as well as projects, business lines, enterprise-level achievements, and value chains in the same series.

Service-Oriented Architecture: Conceptual Model

This
The concept is based on an architectural style that defines an interaction model between three main participants: service providers, publish service descriptions, and implement services and service consumers, you can use a uniform resource identifier.
(URI) to directly use the service description, you can also find the service description in the Service Registration Center and bind and call the service. The service agent provides and maintains the Service Registration Center. However, there is no general public registration
Heart.

Figure 1 is a meta model that shows these relationships.

Figure 1: Conceptual Model of SOA architecture style

Architecture Style and Principle

The architectural style defining SOA describes a series of patterns and guidelines to create
Loose coupling and business dependencyBecause of the separation of descriptions, implementations, and bindings, the Service provides unprecedented flexibility for new business indications and opportunities.

SOA
IT is an enterprise-level IT architecture used to connect resources as needed. In SOA
Resources are available to participants in the value network, enterprise, and business line (typically, they span multiple applications within an enterprise or between multiple enterprises ). IT consists of a series of business-dependent IT
Service composition. These services meet the business processes and objectives of the Organization. You can design these services into integrated applications and call them through standard protocols, as shown in figure 2 below.

A service is a software resource (discoverable) with specific service descriptions ). Service consumers can search, bind, and call service descriptions. The service provider implements the service description function and provides the required service quality to the service consumer. Theoretically, services should be centrally managed by published policies, and dynamic services are supported.
You can configure the architecture style.

Figure 2: Attributes of SOA

Flexible businesses can be achieved through flexible IT systems, mainly through interfaces, implementations and the separation of binding (Protocols) provided by SOA. Based on new business needs, flexible businesses can be postponed at a given point in time.
Select
Service Provider, (Functional and non-functional (such as performance, security, and scalability) requirements ).

You can use
Irregular Implementation ModeCome
Reuse this service. The irregular implementation references the architecture style capability to apply the modes and roles associated with the participants in the interaction model by means of merging. You can apply it at the layer of the architecture, or
It is applied across multiple layers of the enterprise architecture. Between projects, it can be integrated and conceptually upgraded between business units and business partners within the value chain.

Context

In this article, I have introduced high-level behavior for identification, designation, and implementation, and some service-based modeling components. Service-based modeling is a service-based analysis and design (SOAD) process to model, analyze, design and produce SOA that relies on business analysis, processes, and objectives.

First, I will take a look at what you want to build, that is, SOA and Its layer. Next, I will describe how to build SOA by discussing the main activities and technologies required to create SOA.

As an example, we assume that you are developing a project with the goal of porting some banking lines with self-service account systems to SOA.

To port to SOA, you need additional elements that exceed service modeling. They include:

• Adopt and mature models. In terms of SOA and Web Service adoption, is your enterprise at that mature relative level? Each of the different levels used is unique to its own requirements.
• Evaluation. Do you have some leaders? Are you already engaged in Web Services? To what extent is the architecture as a result good? Should you continue in the same direction? Will this measure Enterprise SOA? Have you considered all the things you should consider?
• Strategy and planning activities. How do you plan to migrate to SOA? What are the steps, tools, methods, technologies, standards, and training you need to consider? What is your road map and vision? How do you achieve your goal? What is a plan?
• Management method. Should existing APIs and capabilities become services? If not, which one meets the conditions? Each service should be created for the purpose of bringing value to the business in some way. How do you manage these processes without interrupting them?
• Implement best practices. What is a reliable and tested way to achieve security, ensure performance, comply with interoperability standards, and design changes?

In addition to the identification, formulation, and Implementation described in this article, the service-based modeling method also includes the technologies required to support the deployment, monitoring, management, and control of the complete SOA lifecycle.

Upper
About porting to SOA
And discussions about additional activities in the future should get their own articles, which I will be exposed to in subsequent columns in this series. Now, let's assume that you have defined a scope for the project and decided where to concentrate
Party A: You have defined a focus to convert existing systems or services to a series of new systems and services. Now you can start to build your service-based architecture based on service modeling.

An architecture template of SOA

An abstract point of view in SOA describes it as a partial layered architecture of service synthesis combined with business processes.
Figure 3 shows this type of architecture.

Server
The relationship between the service and the formation is that enterprise-level components (enterprise-level or business-line components) implement the service and are responsible for providing their functions and maintaining their service quality. By combining these public services
To support the business process flow. Integrated architecture by using Enterprise Service
Bus (ESB) supports routing, mediation, and conversion of these services, components, and processes. To meet service quality and non-functional requirements, you must monitor and manage deployed services.

Figure 3: SOA Layer

For each layer, you must make design and architecture decisions. Therefore, to help describe your SOA with files, you may create a document consisting of the corresponding parts of each layer.

Here is the template designed for your SOA architecture document:

1. Scope <which field of the architecture is applicable to the enterprise?>
2. Operating system layer
1. Packaged application
2. Custom Application
3. Architecture Decision-Making
3. Enterprise Component layer
1. Functions supported by enterprise components
2. <This enterprise component supports business areas, goals, and processes>
3. Control Decision-Making
1. <As the internal enterprise component of the client organization, select the standards of something>
4. Architecture Decision-Making
4. Service Layer
1. Service Category Table
2. Architecture Decision-Making
5. Business Process and compositing Layer
1. The business process can be presented as a Dance Arrangement (choreographies)
2. Architecture Decision-Making
1. <Which process needs to be arranged in the Dance Arrangement and which one is embedded in the application?>
6. Access or performance Layer
1. <Demonstrate the meaning of Web Services and SOA in this layer, even if necessary. For example, you can call the Web Service's portlet at the user interface level and its functional meaning at this layer.>
7. Integration Layer
1. <Includes ESB factors>
1. <How can we ensure system-level consistency (SLA) and Quality of Service (QoS) of the client that uses the service?>
2. Security Questions and decisions
3. Performance problems and decisions
4. Limitations and decisions of technologies and standards
5. Service Monitoring and Management
1. Description and decision-making

Now, let's describe each layer and the synthesis between each layer more carefully.

Layer 1: operating system layer.This layer contains existing user-defined applications, also known
LegacySystem, including existing CRM and ERP packaging applications, and
OlderObject-based system implementation and business intelligence applications. The SOA composite layer architecture can leverage existing systems and integrate them with service-based integration technologies.

Layer 2: enterprise component layer.This layer consists of enterprise components responsible for implementing functions and maintaining public service QoS. These special components are a collection of managed and controlled enterprise assets supported by enterprises and business units.
Like corporate assets, they are responsible for SLAs consistency through architecture best practices applications. In most cases, this layer uses container-based technologies, such as application servers that implement components, Server Load balancer, high availability, and workload management.

Layer 3: service layer.Services selected to support and make public are at this layer. They can be
FoundOr
Directly static binding, then called, or, if possible, orchestrate to the merging service. This service exposure layer also provides access to enterprise-wide components, specific components of business units, and in some cases, specific items
The mechanism set up by the project, and their interface subsets are embodied in the form of service descriptions. Therefore, enterprise components use the functions provided by their interfaces to provide service implementation at runtime. Interfaces at this layer are exposed as a service.
Description. They are publicly available for use in this layer. They can exist independently or serve as a synthesis service.

Layer 4: Business Process merging or orchestration layer.Layer 3
The Synthesis and orchestration of the public services are defined in this layer. Through coordination and orchestration, the service is bound into a process and serves as a separate application. These applications support Special Use Cases
And business process. Here, a visual process synthesis tool, such as IBM WebSphere Business Integration Modeler or
Websphere Application Developer Integration Edition can be used to design Application processes.

Layer 5: access or presentation layer.Although this layer often
Beyond the scope of discussions around SOA, it becomes more and more meaningful. Here I describe it because the standards are getting more and more concentrated, for example, for Remote Portlets
Version 2.0 Web services and other technologies that pursue the use of Web
Service. You can use it as a layer for future solutions. Note that the following two points are very important: SOA
Separates user interfaces from components. Ultimately, you need to provide end-to-end solutions from access routes to services or compositing services.

Layer 6: Integration (ESB ).This layer enables service integration. By introducing a series of reliable performance sets, such as intelligent routing, protocol mediation, and other conversion mechanisms, it is often described as ESB (see
References ). Web Services Description Language (WSDL) is bound, which contains the address for providing the service. On the other hand, ESB provides a location Independence Mechanism for integration.

Layer 7: QoS.This
Layer 1 provides the capability to monitor, manage, and maintain QoS, such as security, performance, and availability. This is a process that uses the sense-and-respond mechanism and monitors SOA.
Background processing processes by application health tools, including all important standards for WS-Management and other related protocols, and for SOA
Standard of service quality.

Steps for service-based modeling and architecture

This section describes how to use legacy investments
UnionTop-down, business-driven and bottom-up means.

Service-based modeling provides the basis for defining SOA through modeling, analysis, design techniques, and activities. It helps by defining elements at each layer of SOA and making strict architectural decisions at each layer. This is achieved through top-down joint service identification, business-driven methods, and identification of legacy assets and system-guided services.

In this way, high-level business process functions are more specific to large-granularity services. Small-granularity services-these can help implement high-level services-by checking legacy functionality and deciding how to create adapters and wrappers, you can also combine legacy systems to identify the expected functions that are frequently called in the system.

Finally, use
For service modeling, you can use
Cross-SectionHand
Segment to reduce the absolute number of services that may have been identified. A wise method should be to first follow the top-down mode, then model the target service, and finally the legacy of existing assets.
Leave analysis. Message: The faster you define a project scope to a manageable and implemented set, you can achieve value more quickly by focusing on key services to publish the service descriptions that constitute the basic SOA.

This combination of functional business needs and existing investment and utilization in legacy systems provides effective solutions for organizations that want to quickly win and transplant them to a modern SOA. Service-based integration of software applications makes it possible.

Service-based Integration is an evolution of Enterprise Application Integration (EAI). In EAI, all connections are replaced by the location-transparent ESB concept based on standard links, it also provides a series of flexible routing, mediation, and conversion capabilities.

Service-based modeling: Service Analysis and Design

So far, I have described the SOA setup phase. I also demonstrated that to build SOA, you need to make key architecture decisions at each layer of your SOA, and your design must reflect a series of business-dependent services and decisions on how they can be integrated into applications through orchestration.

Different from objects, you need to consider two points of view in SOA; they are service consumers and service providers. Currently, service proxies are not mainstream and will be involved in the subsequent sections.

SOA design policies do not start from "bottom up". This is a common issue for Web Services. You must remember that SOA is more strategic and business-dependent. Web services are the ingenious Implementation of SOA. Many key activities and decisions not only affect the integrated architecture, but also the enterprise and application architecture. They contain two
The consumer and provider activities described in Figure 4.

Figure 4: service-based modeling activities

Figure 4
Shows the activities managed by each role of the provider and consumer. Note that the provider's activity is the parent set of the consumer activity (for example, the provider also participates in service identification and classification ). In many cases
The difference comes from the fact that consumers specify the service they want, often search for it, and once they are confident that it matches the service specifications they are looking for, it is provided by the service provider, they will
Bind and call services. Providers need to publish the services they want to support in turn; that is, in terms of functions, more importantly, the QoS required by consumers
. This implicit contract between the consumer and the provider may mature into a clear contract in terms of SLA; it is automatically or through the business and legal area.

The activities described above can be described as flowing in service-based modeling and architecture methods, as shown below:
Figure 5.

Figure 5: service-based modeling and architecture

Service-based modeling and architecture process consists of three main steps: Service, component, and process (typically, service orchestration) Identification, designation, and implementation.

Service Authentication

This process is composed of a combination of top-down, bottom-up, and middle-out technologies for domain decomposition, existing asset analysis, and target service modeling. In
In the top-down viewThe Business Use Case blueprint provides business service specifications. This top-down process serves
Domain DecompositionThe domain decomposition is composed of the functional areas and subsystems of the business domain, including the process or process into a process, self-process, and high-level business case. In many cases, these use cases are good candidates for public business services on the Enterprise edge, or used across the business line within the enterprise border.

In the process
Bottom-upOr
Existing System AnalysisThe existing system is analyzed and selected as a viable candidate to provide a low-consumption solution for the underlying service functional implementation that supports business processes. In this process, you have analyzed and used APIs, transactions, and modules from legacy and packaged applications. In some cases, componentization of legacy systems is required to re-modularize existing assets to support service functions.

Center outward ViewBy
Target service modelingTo verify and discover other services that are not captured in top-down or bottom-up service identification methods. It links services to targets and subtargets, key performance indicators, and scales.

Service classification and Classification

This
Activities started at the specified time. It is very important to classify a service into a service level, reflecting the compound or irregular nature of the service: the service can also be composed of a well-defined set up and service.
It determines the combination and hierarchy, as well as the collaborative construction of layered dependent services. Similarly, it helps reduce the value-added service syndrome, where more and more small-granularity services are defined, designed, and deployed, but are missing
Lack of control leads to major performance, scalability, and management problems. More importantly, value-added services fail to provide services. These services are very useful for businesses.

Subsystem analysis

This
Activities to obtain the subsystems found in the above domain decomposition process, and specify the dependencies and processes between subsystems. It also identifies use cases in the domain decomposition process as public services on subsystem interfaces. Subsystem score
Analysis includes creating an object model to show internal working methods, as well as the public services included, and implementing their subsystem design. At this time, the design structure of the "subsystem" will implement the construction of large-granularity components.
.

Specify component

In the following main activities, the details of the components that implement the service will be specified:

• Data
• Rules
• Service
• Configuration Overview
• Change

Message and time settings and management definitions appear in this step.

Service allocation

Service allocation includes the sub-systems that have been assigned services to the current authentication. These subsystems have enterprise components that implement the functions they publish. You often make it simple to assume that subsystems have one-to-one relationships with enterprise components.
Structured ComponentsWhen you use the mode to construct an enterprise component, it will appear in the following forms:

• Intermediary
• Facade
• Rule object
• Configuration Overview
• Factory

Service allocation is also composed of service assignment and component implementation in the SOA layer. Allocation of components and services to the SOA layer is a key task and requires documents and resolutions for key architecture decisions. These decisions are not only related to the application architecture, it is also related to the technical operation architecture designed at runtime to support SOA implementation.

Service implementation

This
Steps indicate that the software implementing the given service must be selected or customized. Other available options include the use of Web
Services to integrate, convert, subscribe, and outsource different functions. In this step, you decide which legacy system module is used to implement the given service and which service will be built from the foundation. Other service implementation decisions are different
Business functions include security, management, and monitoring of services.

In fact, projects tend to use any number of corresponding efforts to meet the closed opportunity window. Therefore, we recommend that you manage three streams in parallel.

Top-down domain decomposition (Process Modeling and decomposition, change-based analysis, policy and business rule analysis, and domain-specific behavior modeling (using syntax and charts )) it is a parallel control of analysis of existing legacy assets that are candidates for componentization (modularization) and service publication. In order to obtain the business intent behind the project and make the service work closely with the business intent, the target service modeling can be controlled.

Conclusion

Ben
In this article, I started with the basic knowledge of service architecture, its layer, and architecture decision-making. Next, I used a method to describe the service-based modeling activities, as well
The importance of the activity (the Service proxy will be involved in later articles ). This method provides detailed guidance on analysis and design activities for determining the three basic aspects based on the Service Architecture: services, processes and
The component that implements the service. I also described a template that you can use to make decisions on your architecture at each layer of SOA.

As I mentioned, it is very important to combine top-down, bottom-up, cross-part, and Target Model Analysis Methods for service identification. Next, I will focus on the main activities of service designation and implementation.

In this series of next articles, I will apply this method to the empty domain of account management and use examples to describe each step. In addition to identification, designation, and implementation, I will also discuss other activities based on service modeling techniques, including the deployment, monitoring, management, and control of the complete SOA lifecycle.