GooBiz

Identity : Using Business Services with the personalisation choices of the end-users

Intent :

Allowing actors of the application system to invoke business services depending on their application choices.

 

Solution : This pattern is situated in the logical continuity of the pattern PTAL presented above. As a first step, it aims at describing business use cases according to behaviours described within corresponding business services. In a second step, it allows to consider application level choices of the actors of the IT system while they invoke these business behaviours.  Finally, the pattern explains how to plug-in application choices of the actors within the business service components of the Goal-Driven SOA Framework (GD-SOA).

 

 

Explanation : In order to allow actors of the application system layer to use business behaviours depending on their application choices, this pattern distinguishes two types of services :

 

Business Services correspond to business processes or to functions that can be mutualised between business processes. A business service captures a set of requirements that belong to one of the goal units of the business system. For example, in the case of a commercial websale system Register Visitor and Review Visitor Registration,... may be discerned as business services on the basis of related business processes.

 

Application Services reflect system behaviours that are related to the choices of the actors of the application system while realizing business responsibilities that are assigned to them. For instance, while participating to the realization of the business service Register Visitor, an internet visitor may wish to look at the available promotions or to look for products depending on his/her own interests.

 

To explain how to integrate application choices of the users while using business use cases, let's consider the example below. A business actor uses a business use case component to invoke behaviours encapsulated in a business service component. An application system actor has different possibilities to realise these business behaviours through its application use case component. These possibilities are discussed on the basis of the example below where the business use case Enter Visitor is described first, then application choices of the end users are considered while using these business behaviors.

 

 

 

Figure 1 : Behaviours stored in business service components are invoked by the actors of the application layer depending on their choices

 

Explanation Step 1  : Describe actor / system interactions of the Use Case considered for convenience as being part of the business layer

Basically, by separating business behaviours from actor / system interactions, according to the Pattern for Identifiable Service Specifications (PISS), the description of the use case UC-Register-Visitor below focuses only on actor / system interactions required for the registration process of the visitor. 

 

Summary Description of the Use Case Register_Visitor : The use case begins when an internet visitor asks the system for his/her registration. The use case is ended when the system confirms that a notification will be sent to the visitor. A notification contains information about the registration process of the visitor and other relevant information like the bonus affectation and the lottery results.

 

ACTOR	SYSTEM
1-Visitor activates the UC for his/her registration.	2-System sends the menu of choices to the user
3-User makes his/her selection for the "Registration".	4-System asks the user to fill the "Entry" form
5-User enters fields (name, .., e-mail,) and submits the form.	6-System checks for mandatory fields, thanks user for his/ her entry then sends the questionnaire to the user.
7-User completes the questionnaire and submits.	8-System checks the result. It stores fields in the database, affects bonus and realizes lottery. Then it finishes the transaction with a message of courtesy and informs the user by sending a notification.

 

6.a : If mandatory fields are incomplete, the system asks the user to complete them.

7.a : If user leaves the questionnaire, the systems aborts the use case.

8.a : If user leaves while filling the questionnaire, then system terminates the transaction.  

 

Actors of the application layer may wish to use these behaviours defined as being part of the business layer depending on their application choices. This is what is focused in the next step of the solution proposed by this pattern.

 

 

Explanation Step 2  : Consider application choices of actors while using behaviors defined at the business layer

Actors of the application system may wish to use behaviors defined in business processes using one of the scenarios given below. Thus, an actor may require from an application use case to invoke :

• Scenario 1- One or more business processes of his/her choices without any additional application process ,
• Scenario 2 - An application process before or after using a business process ,
• Scenario 3 - An application process during the execution of a business process.

In scenario 1, the application use case of the actor invokes behaviors defined in the corresponding business use case(s).

In scenario 2, it invokes additional behaviors from application services before or after invoking those from business use case(s).

Finally, in scenario 3, the application use case and service specialise respectively behaviors defined in the business use case and service according to constraints of pre-condition and post-condition that are to be respected.

 

The figure below gives an example that illustrates rules to apply for realising a business service according to application choices of the application system actors (scenario 3). This example deals precisely with the Entry process of the user (actions 4, 5, 6, 6.a and 7.a described in the above business use case description). System responses described in the system column appear in the component named BUC_Visitor [Entry].

Notice : Expressions X and Y respectively used for the use case and service components in the figure may have different values.

 

Figure 2  :  Use cases and services of the application layer specialize corresponding components of the  business layer in respect to their pre-conditions and post-conditions

 

In order to check with the actors of the application layer different scenarios that allow them to invoke business behaviors with their choices, application use case and service components are integrated into the business architecture. The figure below shows an example of such an integration according to the scenario 3.

 

Figure 3  : An example to the specialisation of business service components in respect to their pre-conditions and post-conditions

 

Strengths of the pattern PUBS-AL : The pattern PUBS-BAL describes how actors of the application layer may invoke behaviours stored within business services depending on their application choices (throughout application use cases). In this sense, it allows application users to personalize behaviours described within business services and use them in respect to constraints expressed at the business layer.

 

Relationship : This pattern requires a previous application of the pattern PTAL (Traceable Abstraction Layers) in order to obtain service behaviours that are to be customized according to the personalisation choices of the end users of the application system. Its relationships with these patterns of the GD-SOA Framework are illustrated below.

 

 

Figure 4 : Relationships between the pattern PUBS-AL and other patterns for the Goal-Driven SOA Framework : Click on the referenced pattern icon to visualise its detailed description.