Building SOA portfolio Business Services, part 1th: Developing SOA portfolio applications to support business services

Introduction

Composite applications provide the ability to integrate existing service-oriented architecture (Service-oriented-architecture, SOA) services and/or create new services that can be combined in different ways. The key to composite applications is to use SCA to create reusable software assets as SOA service implementations. We use WebSphere Process Server, WebSphere Portal, WebSphere Service Registry and Repository, WebSphere Enterprise bus, WEBSPH Ere Portlet Factory and WebSphere application Server and their corresponding development tools developed a sample portfolio application for the financial sector. The selected scenario provides examples that illustrate the implementation of the different features required to develop efficient composite applications. We'll start with these sample scenarios to illustrate the benefits and challenges of combining applications. Finally, we will analyze the technical features in IBM products and how they can be used to develop composite applications.

In this article, we first define a composite application, a change point, a role, a use case, a run-time environment, and a list of business intentions that need to be implemented in order to create a composite application that supports business services.

Subsequent articles in this series will analyze several related issues in more detail, including multiple leasing (multi-tenancy) Design patterns, application selectors and business rules for dynamic, publishing services, self-help patterns and assets, configurable user interfaces using dynamic configuration files, automatic build and deployment, using CEI develops measurable applications and other similar topics.

What is a composite application?

The SOA composite application is defined as "a set of dynamic service components that address specific business issues or tasks." Composite applications often provide a set of services that may belong to other composite applications. A business service is a service that the business unit chooses to expose at its boundaries and connects to its customers, partners, or other business units through an interface. Business services implement meaningful business processes or tasks. A composite application consists of one or more components or component aggregations, where each component or component aggregation exposes a service interface. Composite applications provide support for business services.

Figure 1. A composite application for retail bank loan issuance

As shown in Figure 1, composite applications orchestrate a range of configurable services. For example, in this example, the rectangle corresponds to the business component that exposes the business service, such as Validate. The red line indicates the sequence of calls that a particular use case of a composite application follows. Along the red line, the loan application will be accepted in turn, generating a credit record and then verifying, analyzing and providing the loan. After the loan is approved, it must be initialized, configured, settled, and recorded. Finally, a dialogue will be initiated to communicate with the customer.

In this context, the Services Component Architecture (Service Component Architecture,sca) is a service-oriented component model. It provides coverage for stateless session EJBS, Web services, traditional Java objects (Plain old Java object,pojo), Web services Orchestration Execution languages (ws-business process Execution Language, WS-BPE L the abstraction of processes, database access, Enterprise information systems (Enterprise information System,eis) Access and other service implementations, as shown in Figure 2 below. SCA separates business logic from infrastructure logic, so programmers can focus on business issues.

Figure 2. SCA Implementation Type

Change Point

The point of change is to determine where the changes may occur and where they should be externalized. Service components with built-in change points allow users to configure these services to meet different requirements. You can add extensibility mechanisms to the UI, service component interfaces, service components themselves, and the data model to implement configurable applications.

It is very necessary to compare the configuration to the customization. Being configurable provides us with the ability to adapt components to different requirements without changing the code base (writing code). The configuration is built into services (Switch, Dial, and lever) and can be invoked by users of the application. In contrast, customization requires the development of additional code (using the programming language) to extend and change software components to support specific "custom" behavior.

We can classify these changes into three broad categories: User interface, business logic, and persistence.

User interface (UI)

The change point in the user interface allows the user to change the appearance of the UI and its semantic content (data fields) through configuration. Examples of configuration change points in the user interface are:

Reinvent the site's brand with a customer-specific logo and logo. For example, suppose there are two banks, bank A and bank B. Both have their own logos or brands and want the site to reflect this.

Change the label and text displayed in the user interface to make it appropriate and familiar to the employees and customers who use it. For example, a bank can use the term preferred account as the label for the input field, while the other bank can use the term Advantage account.

Change the input fields that are exposed to the user. A bank can allow a user to enter a standby cell phone number, while another bank may not be allowed to provide this information.

Change the endpoint of a user-invoked SOA service. Different credit checking services may be used depending on the geographical location of the country, so the endpoint can be externalized to allow configuration.