3.3 Designing the Project in the Application Scope

You complete the design process within the application scope. Here you create technical designs for each of the constructs (that is, business flows, ESBs, services, and so on.), discovered and defined in the project scope. You will decompose these constructs into finer-grained constructs, until the design is such that you can determine how best to use the products within Oracle SOA Suite to create runtime executables.

3.3.1 Designing a Process Flow

You can now add implementation details for process flows, using the process flow definitions created in Section 3.2.5, "Defining the Project".

To design a process flow:

Using the use case analysis and the business interaction diagram, design the activities for each step within each scope of a flow.

For example, based on the definition created in Section 3.2.5, "Defining the Project", you might start by designing each scope within a flow. You might then begin to add all activities that need to be completed for that scope, in order to move on to the next scope. Types of activities include:
- Assign: Copies data from one XML variable to another
- Invoke: Sends information, typically a request, to a web service, which is identified by its partner link, and specifies an operation for the web service to perform
- Partner Link: Characterizes the conversational relationship between two services by defining the roles played by each service in the conversation and specifying the port type provided by each service
- Receive: Waits for a message from the client or a callback response message from an asynchronous web service
- Reply: Sends a message in response to an invocation
For example, Figure 3-8 shows the activities for the CreditValidation scope, which include:
- InitializeRequest: Copies the credit card type and number from the customer data and assigns the values to variables.
- InvokeCreditService: Invokes the CreditValidatingService web service with a synchronous call that includes the credit card number and type. The service replies with either a valid or not valid response.
- Generic switch activity: An expression in the switch task states that if the service returns a response stating that the card is not valid, an error must be thrown. The switch contains the following two activities:
  - AssignFault: Assigns the value "Credit Problem" to the status variable.
  - ThrowCreditFault: Invokes the OrderBookingFault scope.
Figure 3-8 The Credit Validation Scope

For each activity (including the scope activities), define the following:

Activity name: Name of the activity.
Business process: The process flow to which the activity belongs.
Activity description: An overview of the functionality the activity provides.
Activity type: Web service, WSDL EJB Binding, Java code, Transformation, Assignment, and so on.
Activity details: Detailed description of the functionality provided by the activity.
Transformation details (when applicable): Data mapping details. See step 3 for more information.
Parameters: Process parameters modified or used by this activity.
Exceptions: Any faults that can be generated by the activity. Include exception handling logic.

Table 3-2 shows the definition for the activity that invokes the CreditValidating service to verify a customer's credit card.

Table 3-2 InvokeCreditService Activity Design Description

Item	Description
Activity Name	`InvokeCreditService`
Business Process	`SOAOrderBooking`
Activity Description	Invokes the `Credit` service to verify a customer's credit card
Activity Type	Web service
Activity Details	Synchronously invokes the `Credit` service and sends credit card type and number. Waits for a response that contains either an `valid=true` or `valid=false` message.
Transformation Details	None
Parameters	`ccType`, `ccNum`
Exceptions	The `Credit` service may not be available, or may not send a response. If unable to connect to the service, throw a `serviceNotAvailable` exception. Need to set a time-out that will be used to determine when to throw a `noResponse` exception. If the credit card is not valid, throw a fault that will set the order status to `canceled`. Because there are other places in the flow where an order should be set to canceled, this should be its own subflow that can then be reused.

Provide details of any needed document data transformation.

Typically, data transformation converts inbound data to variables previously defined for the process, or it converts a variable to outbound data structures required by the destination system. These variables represent canonical business objects. For example, the TransformOrder activity in the SOAOrderBooking flow transforms order information received from the ESB (inputVariable variable) to the orderRequest variable, which will be used to persist order information into the database. You create a data transformation specification to provide detailed node-to-node mappings, as shown in Table 3-3:

Table 3-3 Data Transformation Mapping Requirements

Item	Description
Source Node Name	Node name in source object.
Source Node Path	Path to node within source object.
Source Node Description	Description of the node.
Source Data Format Definition	Data type. For example, `char`, `integer`, `date`/`time`, `binary` `encoded`. Also note the maximum length.
Destination Node Name	Node name in the destination object.
Destination Node Path	Path to the node within the destination object.
Destination Node Description	Description of the node.
Destination Data Format Definition	Data type. For example, `char`, `integer`, `date`/`time`, `binary` `encoded`. Also note the maximum length.
Mapping Type	Straight: No data conversion. Derived: Derived from multiple inbound nodes. Complex: Complex mapping logic; database/table lookups.
Mapping Details	Detailed description of mapping logic.

If the activity invokes an external service, you should note the following for that that trading partner:
- Exchange protocols
- Document protocols
- Message types
- Constants for selected protocols
- Endpoints (for example, https, email, ftp)
- Design for SLA failures
- Contact information
If the process flow will be invoked as a web service, determine any authentication or authorization needs for the flow.

For example, you may want to restrict access to a flow based on user type, or you may need to encrypt data.

3.3.2 Designing Services

To create a technical design for a service, you start with the service definition created in Section 3.2.5, "Defining the Project", and then add detailed technical elements.

To design a service:

For each defined service, create a technical design that details the following items:
- Message formats: XML definitions for inbound and outbound objects.
- Business process rules: Component design to meet business process rules.
- Data sources: Detailed sequence diagrams for interacting with application APIs, EJB methods, Java class methods, and so o.
- Process Security: Configuration details for service security, for example, AppService JAAS configuration or WS-Security usage.
- Exception handling: Detailed error processing options and components necessary for error handling. Possible design options include error trapping, editing, and replay capabilities and detailed service fault definitions.
- Human Workflow: Design of the human workflow system and interaction with business process (if applicable). Includes user interface design and page flows.
Assign design patterns to each of the defined services, using their classifications created in Section 3.2.5, "Defining the Project" as a guide.

By assigning design patterns to particular classifications, you ensure that coding best-practices are adhered to throughout the system.

For example, note the classifications of the following services:
- Order: Data functionality
- Customer: Wrapper on an information system invoked synchronously
- ApproveOrder: Human workflow invoked asynchronously
Figure 3-9 shows how these categorizations can lead to assigning designing patterns (shown in red). All other services falling into the same categorizations will be assigned the same design patterns, and will therefore follow set standards and guidelines for those patterns.

Figure 3-9 Service Categorization Leads to Pattern Assignments

Examples of integration design patterns include:
- Facade (also known as Wrapper)
- VETRO (Value-base, Enrich, Transform, Route, Operation)
- EAI
- Human Workflow
- Hybrid (a mix of automatic and human workflow)
- Service Broker
- Rules
- Invocation
Design the service's interface.

This design can follow any standard component design process. However, you should review designs to ensure that dependencies between services are minimal, and that any dependencies are written in the contract (the interface), and not the component itself. This interface is what will become the web service used by the system.

For example, the CreditValidationService requires information that is supplied by the Customer service. Instead of interacting with the Customer service directly, activities are added to the flow to access the needed data and store it in variables. The CreditValidationService then uses those variable values to perform the validation. In the future, either of these loosely coupled service implementations can change without affecting the interaction between them.
Ensure that all original business and operational requirements are met by the service.

For example, if the Order Booking SOBA has a specific transactional requirement, then every service endpoint that is part of that process must meet that requirement. If they cannot, then certain compensation patterns may be applied to provide the needed transactional integrity.

3.3.3 Creating a Physical Design

Now that you have determined exactly what needs to be created, you can determine how to implement each of the flows, ESBs, services, and service components using Oracle SOA Suite.

To create a physical design:

Map each construct from the designs to a product in Oracle SOA Suite that can be used to develop the construct. This suite provides a complete set of service infrastructure components for creating, deploying, and managing SOA-compliant applications and processes.

Oracle SOA Suite offers the following applications to help you in implementing an SOA system:
- Oracle JDeveloper: Provides an ISE (integrated service environment) to complement its IDE functionality. Visual and declarative tooling for BPEL design, ESB system design, and XSLT mapping are an integral part of JDeveloper. JDeveloper also supports the complete development life cycle with integrated features for modeling, coding, debugging, testing, and tuning applications.
  
  For information about using JDeveloper to create EJB service components, see Chapter 4, "Building and Using Application Services". For information about using JDeveloper to create and manage web services, see Chapter 5, "Building Web Services". For information about developing a web client using JDeveloper, see Chapter 9, "Developing a Web Application in an SOA System". JDeveloper is also used to design and develop the ESB and BPL flow. See the following points for more information.
- Oracle Business Rules: Provides the infrastructure for the development and deployment of business rules. Oracle Business Rules consists of a Rule Authoring Tool for defining rules, an SDK that provides rules access and update for embedded programs, and a Rules engine that executes the rules. For more information about creating and deploying rules using Oracle Business Rules, see Chapter 8, "Creating and Using Rules for a Decision Service".
- Oracle Enterprise Service Bus: Moves data among multiple endpoints, both within and outside of an enterprise. Oracle Enterprise Service Bus uses open standards to connect, transform, and route business documents as XML messages among disparate applications. You design an Oracle ESB using the ESB Designer within JDeveloper. For more information about creating ESB systems, see Chapter 6, "Using Oracle Enterprise Service Bus".
- Oracle BPEL Process Manager: Offers a comprehensive and easy-to-use infrastructure for creating, deploying and managing BPEL business processes. You develop BPEL process flows using the BPEL Designer within JDeveloper. For more information about creating process flows, see Chapter 7, "Using Oracle BPEL Process Manager".
- Oracle Web Services Manager: Allows you to centrally define policies that govern web services operations (such as access policy, logging policy, and load balancing), and then wrap these policies around web services without requiring modification to those services. For more information about creating policies, see Chapter 10, "Securing the System".
Based on the chosen tools, and the assigned design patterns, you can now develop best practices and standards for implementation.

In an SOA system, it is important that naming conventions be defined for all project components, and that they be tailored to the different products used for implementation. For example, service names, service operation names, BPEL process names, and BPEL activity names, should all be standardized.

Coding standards for an SOA system should be addressed for each of the employed design patterns. Some examples include:
- Common WSDL design standards, such as standard fault replies for synchronous web services and business processes.
- Common error handling approach
- Common logging approach
Create a deployment topology.

This topology maps each application component to the system architecture. It should identify the specific software, servers, server configurations, and io subsystem configuration. Figure 3-10 shows an example of a deployment topology for a BPEL process flow.

Figure 3-10 Deployment Topology for a Process Flow