SOA Modeling: Part 1 service Synthesis

This article is 4th of the five articles in this series. It covers how to assemble and Connect service providers created in "Part 1 service implementation" and design their interactions, provide a complete solution for business needs. The most fruitful merging element will be a service participant who is responsible for combining the services provided by the invoicer, productions, and shipper merging elements to provide service capabilities for processing the order. This article also shows how this service participant meets initial business needs.

About this series

In the first three articles in this series (see "more in this series" in the upper-left corner "), we outline a way to identify services that are connected to business needs. First, we need to capture the business objectives necessary for implementing business tasks. Then, model the business operations and processes necessary to meet these objectives. Then, we use the business process as a contract that helps us identify the necessary services and potential links between them. Then, we completed the specifications of the identified service.

In Part 1 of the 1st articles in this series, we study how to maximize the potential of SOA solutions by identifying services related to the business. We design a service topology based on business requirements, and connect services that reflect the demand contract that must be achieved by services with service solutions.

In part 2 of article 2nd, We have modeled the details of the Service Specification. The Service Specification defines what potential consumers of a service need to know so that they can decide whether they are interested in using the service and how to use it. It also specifies everything that the service provider must know so that they can successfully execute the service.

In Part 1 service implementation, we model the implementation of service specifications that serve as results in service providers: invoice, productions, and shipper. Each merging element provides services and functions in accordance with service specifications. Each provided service operation has a method to describe how the service is actually executed. The method can be any UML behavior, including activity, interaction, statemachine, or opaquebehavior. This is determined by the modeler.

The last article in this series, "SOA Modeling: Part 1 service implementation", uses the IBM Rational Software Architect UML-to-SOA conversion feature to create a Web Service implementation, it can be used directly in IBM WebSphere integration developer to implement, test, and configure a complete solution.

Content of this article

In this article, we will combine the service providers created in article 3rd and use their functions as another service provider. That is to say, we will create a new service from the compositing elements of other services. This technology can be used recursively at any time, crossing any attention set and any abstraction layer. However, there may be many constraints on the architecture, focuses on service operation granularity, security, and execution, data exchange volume, and write-level communication protocols and binding issues that may constrain the composition of services. These issues determine the architecture of the solution and are not covered in the scope of these articles in this series. See design an SOA solution using a reference architecture for more details on this important topic.

Like all the articles in this series, we will use existing IBM Rational and IBM WebSphere tools to build solutions and link them together, this allows us to verify that the solution meets our needs and manages changes more effectively. Table 1 summarizes all the processes used in our development examples and the tools we use.

Table 1. Development Process roles, tasks, and tools

Role	Task	Tools
Business Executive Officer	Communicate business objectives	IBM Rational requisitepro
Business Analyst	Analyze business needs	IBM Websphere Business Modeler
Software Architect	Design the architecture of the Solution	IBM Rational Software Architect
Web Service developers	Execute this solution	IBM Rational application developer and WebSphere integration developer

Service Implementation Review

We will first review the service providers executed in the previous article. Figure 1 shows the invoicer service provider.

Figure 1. invoicer service provider

The invoicer service provider provides the invoicingprotocol for calculating the initial cost of the order, and then redefined the price when the shipping information is known. The total price of a purchase order depends on where the product is produced and where it is shipped. The initial cost calculation may be used to verify that the consumer has sufficient credit or still wants to order the product. It is best to complete this test before ordering.

Figure 2 shows the productions service provider.

Figure 2. Production Service Topology

The productions service provider provides the scheduling service to determine where the product is produced and when it is produced. This information can be used to create a shipping schedule, which is used when processing the order.

Figure 3 shows the shipper service provider.

Figure 3. Shipper service provider

The shipper service provider provides the shippingservice service, which ships the product to the consumer to complete the order. This service requires the scheduleprocessing interface to request the consumer to complete the processing.

Service Synthesis

Now, all services are provided by some providers, and we are ready to use these providers together to meet initial business needs. This collection is used to synthesize and design services based on business needs, providing a method for the purchasing service. We will createOrderprocessorMerging elements to provide a purchase service for processing the order. This service provider requires the service to be defined by the invoicingservice, scheduling, and shippingservice service specifications. We will create an orderprocessing merging element, which includes examples of invoicer, productions, and shipper merging elements and orderprocessor merging elements to process the order.

Order processor service provider

The order processing service is specified by the Purchasing Service specification (see Figure 4). This Specification includes the following features (or operations ):

+ processPurchaseOrder (customerInfor : Customer, purchaseOrder : PurchaseOrder) : Invoice

This service will be provided by the orderprocessor service provider. Orderprocessor is a merging element that provides a service by connecting other service providers (designed according to the requirement contract. That is to say, some aspects of the provided service method are designed to use other service providers in some way. This merging element provides the purchasing interface through its purchase service port. All consumer interfaces use this port to separate consumer clients from the interaction between consumer elements and other service consumers or providers. This limits the coupling in the model and can be easily changed as the market and service consumers and providers change.

Figure 4. Purchasing Service Specifications

The organizations of orderprocessor merging elements are displayed in the project explorer view shown in Figure 5.

Figure 5. Order management business function area (Package)

The orderprocessor service provider is included inorg::ordermanagementPackage, which is used to organize services related to order management. The purchase management package also contains related service interfaces, service consumers, and service providers.

The orderprocessor chart shown in Figure 6 provides an external view of the orderprocessor service provider and the services they provide and require. (The required service is sometimes calledRequestTo distinguish the functions .) The external or "black box" view is displayed to the consumer of the service provider. The internal structure of the compositing elements shown later provides an internal or "white box" view that supports the execution of the design structure of the compositing elements.

Figure 6. orderprocessor service provider

An external view is not a rule separated from execution; it is only a view that combines certain elements. If the architect or developer wants to completely separate the specification of the service provider from its possible execution,SpecificationsMerging elements. A standard merging element defines a contract between a service consumer and a service provider, which weakens them from the execution of a specific provider. Normative synthesis elements can be identified by many specific synthesis elements, which provide services in a way that identifies contracts and provide acceptable quality of services. See "SOA Modeling: Part 2 service specifications" for more details.

The orderprocessor service provider elements are simple and stable. In this example, architects and developers decide not to use the service specifications. As a result, any service consumer that uses the orderprocessor merging element will be associated with this specific execution. Whether this is a full design depends on how many services will be used, and how much change they will take over time. Only the Solution Architect can determine the degree of coupling that a specific system can tolerate.

The orderprocessor merging element also has the service port that reflects the request provided by other service providers (goods pricing, schedule, and shipping. These service providers provide services whose orderprocessor merging elements are used to perform service operations they provide.

Each service interaction failover point involves a simple protocol that affects the provided and requested interfaces. For example, the invoicing interface is required to start the price calculator and send the shipping price. However, it may take some time to calculate the shipping price. Therefore, orderprocessor provides the invoiceprocessing interface through its billing port, so that the billing service provider can send a invoice when it is ready.

Potential Coupling Problems Note that there is a potential design problem in this example, which may lead to unexpected coupling. How the ordering service provider interacts with the prices of captured goods in the same business process (activity), just like the rules that interact with the production schedule and shipping service providers. This makes it difficult to reuse goods pricing, timelines, and shipping services without replicating interaction protocols. This coupling is often caused by the direct execution of service operations in the business process. The Business Process Model focuses on the steps required for an activity to complete a specific business target, such as effective order processing. They do not need to focus on how to copy those steps to increase cohesion, reduce coupling, make reuse easier, minimize distributed communication, process network security, and manage the integrity of persistent data. These are the concerns of IT solutions and must be addressed using software architecture and practical and proven design patterns. The Service Contract provides a way to capture business needs in a form, and allows service providers that replicate the architecture to meet business needs and handle it solution concerns. The link between the architecture solution and business requirements is implemented through the contract. It binds all parts of the service provider with their roles in the service contract. In this example, we will not further solve these design problems, but we will show how to link the service solution to the business requirements it has completed.

Order processor execution Design Model

We have now completed the architecture of the service model and captured it in the external view of the service provider. The next step is to provideprocessPurchaseOrderService operations provide a method. This method must follow any completed service contract or implemented Service specification, and also the service specifications that have been defined for those operations.

Internal Structure

The orderprocessor service provider provides a simple Service Specification purchasing through its purchase service port. This Service Specification specifies a simple operation processpurchaseorder. The service provider must provide some methods for all service operations it provides. In this example, we use activity as the processpurchaseorder service operation method. The details are displayed in the internal structure of the orderprocessor merging element that provides the service. The internal structure of orderprocessor is captured in charts, interfaces, classes, and activities, as shown in the project explorer view in 7 and the composite structure chart in figure 8.

Figure 7. orderprocessor Service Provider Organization

The project explorer view displays the list of each part of the orderprocessor provider and the methods (Actions) of each provided operation ). The Convention used in this example is to use a class chart with the same name as the compositing element and display its external view in the package containing the compositing element. This is the chart shown in Figure 6 and Figure 7. Composite charts with the same name as the compositing element and included in the compositing element provide an internal view of the service provider structure. This chart is directly located under the orderprocessor service provider in figure 7. These conventions better coordinate the external and internal views of service participants, and study charts as carefully as the compositing elements.

The orderprocessor composite structure chart 8 provides an overall view of the internal structure of a service provider. It once again shows all the parts (ports and attributes) of the compositing static structure of the compositing element ).

Figure 8: Internal Structure of orderprocessor service provider

The internal view of orderprocessor merging elements is simple. It is composed of the Service ports used for the provided and requested interfaces, and many other attributes that maintain the status of the service provider. The property ID is used to identify the instance of the service provider. This attribute will be used to dynamically associate consumer and provider interactions. AttributescheduleAndshippingInfoIs the information used in the execution of the processpurchaseorder service operation.

Service operation method provided

Each service operation provided by the service provider must be implemented in either of the following two ways:

• Behavior (activity, interaction, statemachine, or opaquebehavior) is the operation method;
• The accepteventaction (asynchronous call) or acceptcallaction (synchronous request or reply call) in an activity of a merging element ).

This allows a single activity to have more than one concurrent entry point, and it complies with Multiple receiving activities in Business Process Execution Language (BPEL. These accepteventactions are usually used to process call back signals and return information from other asynchronous calloperationactions.

 

The orderprocessor merging element contains two service implementation styles. The processpurchaseorder operation has a method activity with the same name. As shown in Figure 9, this activity is an activity owned by the service provider that provides service operations.

Figure 9: Operation implementation of the processpurchaseorder Service

This chart is very consistent with the Websphere Business Modeler chart for the same behavior. Invoiceprocessing and scheduleprocessing service operations are implemented through the process of processinvoice and processschedule to receive event actions. Note that the corresponding operation in the interface is indicatedTriggerAction, which indicates the ability to respond to acceptcallactions (similar to receiving and accepteventactions, where the trigger is a signalevent ). KeywordsTriggerIt is not part of UML 2. It is only used to emphasize how these operations are implemented.

Note:
These operations will not be received unless the processpurchaseorder activity is running and the control process has reached two Receiving call actions. This indicates that the execution of an operation can determine when other operations will be responded.

Implement Service Contract

The orderprocessor merging element has been completed. But there are two other things not done:

1. First, we need to combine orderprocessor service providers with business processes that model their needs.
2. Secondly, we need to create a sub-system to connect the service provider that can provide the interface required by orderprocessor with the appropriate service port.

This will lead to a configurable sub-system that can run. This section deals with issues linking SOA solutions and business needs. The next section describes the configurable subsystems.

 

Terms IBM software services profileService collaborationIt is described as "a group of services act together in an agreed manner according to certain process specifications ". This is essentially a contract that specifies how a group of services are connected and designed to achieve certain goals, such as how another service is executed or how certain business goals are implemented. Service collaboration can also be used to formally describe the needs to be met. The integration between the Websphere Business Modeler Business Process Model and the Rational Software Architect UML modeling is designed as development collaboration, just like the role center method that describes the requirement. When it is enabled in Rational Software Architect, it regards the Websphere Business Modeler Business Process as a collaboration. TermsService collaboration,Service demand contractAndBusiness Service demand contractBoth represent similar meanings, and use collaboration to describe the needs of a group of commonly used services. These different terms only focus on the specific use of collaboration in the context.

The operations in this section do not change how the orderprocessor merging elements are transformed into an SOA execution. Linking a merging element to a service contract only describes how the merging element meets the requirements specified by those contracts. This does not affect the execution of the service provider or how it will be transformed into an SOA solution. However, joining is much more complex than dependency. It specifically shows the roles of each part of the service provider in the service demand contract, and the constraints of merging elements to complete the business. This provides richer traceability, support for fine-grained change management, and the ability to use model verification solutions to meet their needs.

Figure 10 a service contract is used to show the requirements of the orderprocessor service provider, which provides a role center view of the business process created by the Business Analyst. A collaborative use is added to the orderprocessor service provider, indicating the service contract it has completed.

Figure 10: Implementing a service contract

Figure 10 is calledContractIs an instance of the purchase order process service collaboration shown in Figure 11. This specifies that the orderprocessor service provider needs to complete the purchase order process business. Role binding indicates which part of the service provider plays a role in the service contract. For example, the billing port plays the billing role, and the purchase port plays the orderprocessor role.

Binding these roles is irrelevant to the service channel connector described in the next section. The service channel connector is used to connect consumer requests and provider services in the subsystem. Role binding specifies the role that this Part plays in the service contract. Role binding can be both strict and loose.StrictContract completion means that each part must be of the same type as the role they are bound.LooseContract completion means that each part will assume those roles as required by the architect, but model verification does not verify the role and some functions. That is to say, it may be because the business service contract is incomplete or there is only rough information about the business needs.

Figure 11: service requirements contract

It shows how the SOA solution fulfills business requirements and requires additional work to specify contract and role binding, but it provides a favorable condition for managing changes. Model queries may be used to determine which service provider meets the business requirements. Any change in requirements may lead to a change in one of the roles in service collaboration. As a result, The Modeler can directly locate the parts that assume those roles and decide how the service specifications representing those roles that may need to be changed can handle the changes in requirements. Model verification can also be used to determine whether certain roles are changed, and all roles that play this role in SOA solutions are no longer capable of executing the role. This is much more powerful than the old dependency implemented by the use case that does not support semantics or loose semantics. This is the type of connector between verifiable SOA solutions and business needs (ensure that the solution is business-related, meets the needs, and is an agile solution ), to adapt to changes.

Assemble the orderprocessing Subsystem

In our SOA solution, the last thing we need to do is to create an orderprocessing subsystem, which uses the service provider that we have been executing to assemble each part into a configurable solution.

As shown in subsystem 12, it reflects a configurable merging element that connects orderprocessor service providers with other service providers that provide the services they need. This subsystem is a set of merging elements that provide all the necessary information for configuring and running the orderprocessor service.

Figure 12: Assemble parts into a configurable Subsystem

The orderprocessing subsystem includes instances of orderprocessor, invoicer, productions, and shipper service provider merging elements. The product pricing service of the seller's merging elements is connected with the product pricing service of the invoicer merging elements. This is an effective connection, because the service specification of the goods pricing service of orderprocessor merging elements is the deformation of the invoicer provider's goods pricing service. The orderprocessor merging elements require the invoicing interface, which is provided by the invoicer service provider. It also provides the invoiceprocessing interface for invoicer to receive updated product prices.

ConnectionA Service (an instance of a Service Specification) means that the participant agrees to interact with each other in accordance with the Service Specification. That is, they agree to abide by the required agreement. The Service Specification defines the role played by the connected participants in the Protocol. The service channel connector between the orderprocessor consumer's Goods valuation port and the Goods valuation port of the Goods valuation provider has a contract (behavior), which is the invoicingservice behavior of the invoicingservice Service Specification. The connector name is set as the contract name according to the Conventions. Any interaction through this connector is required to comply with the contract or agreement. These connectors form the dependencies Used in the service architecture.

Note that there is no contract between the producer and the seller. This is because there is no protocol in the scheduling service interface, so the connector does not need to be contracted.

Other consumers and providers are connected in a similar way. The connected Service provides different binding styles. The service channel between service endpoints can specify the Binding style actually used.

The orderprocessing subsystem is now complete and ready for configuration. It has specified all required instances for the service provider to fully execute the processpurchaseorder service. After it is configured, other service consumers can bind to the purchase service of orderprocessor merging elements of the seller and call this service operation.

Summary and prospects for the next step

So far, we have completed the identification, specification, and implementation required for services, consumers, and providers to achieve their business goals. The result is a design model of a completely Technical Architecture Service solution.

To actually run this solution, we need to create a platform that is consistent with the captured Architecture Design in the same service model. We can use this model as a wizard to manually create this solution. However, this is complex, error-prone, time-consuming, and requires a high level of developers to ensure that the architecture decisions can be correctly executed. Of course, you can manually create a solution and use this model as a wizard. However, a complete, formal, and verified model gives us the opportunity to model-driven development (MDD) and create a backbone solution from the model, complete the detailed Encoding in the programming environment of a specific platform. This is exactly the next article, the last article in this series: "SOA Modeling: Part 5 Service Execution. In that article, we used the Rational Software Architect UML-to-SOA conversion feature, create a complete Web service solution that can be executed, tested, and configured directly in WebSphere integration developer.