|
|
WLI is an enterprise class product, which can be used to implement process-driven Service Oriented Architecture (SOA) applications. Figure 3-1 shows the BEA reference architecture for service oriented applications.
It is recommended that you use BEA reference architecture for service oriented applications for a WLI application.
The reference architecture is generic and can be implemented with WLI standalone or with a combination of several products. The main components of the reference architecture are as follows:
The types of shared services are as follows:
The steps involved in modeling business processes and services are:
You can define a good business process by:
It is important to understand the main objectives behind the decision to automate a business process. A business process is defined to:
A few examples of process objectives are:
KPIs are the key indicators that provide the visibility for process performance. A few sample process KPIs are:
Identify process actors or participants before you define the process. In addition to human actors and applications, data sources and partners can also serve as actors or participants in a business process.
Public and private processes have a special significance in the B2B domain. A public process is one that is visible to the external user. A private process is one that performs a task that is invisible to the external user within the application in the background. The private process is linked to the public process. When a public process is used as a front end for a private process, you can modify the private process without disturbing your public process clients.
It is a good practice to keep your public process modular. Public processes have higher requirements in terms of security, scalability and availability. Public processes always have special requirements for messaging, protocols, and standards, which need to be identified in advance. Figure 3-2 illustrates a public and private process pattern.
One way to integrate public and private processes is to use loosely coupled publish and subscribe architecture between these processes using the message broker component of WLI.
Another alternative to integrate public and private processes, is to have a process control between public and private processes, and use Java Web Services (JWS) as the front end for your public processes. Process Control (PC) is a better option if your public and private processes are in the same domain. See the Communication Between JPDs section for more details.
Many business processes, especially in the B2B domain, are conversational in nature. For example, a request quote service, where an agreement on the quoted price is achieved after several rounds of message exchange. An initiator uses an initiator process to initiate a business conversation. Participant processes respond to the request from an initiator process. An initiator process:
It is a good practice to define small and modular processes. A modular process meets a specific business need. Modular process definition results in the reuse of business processes. It is easier to maintain many modular processes than a few long processes.
You can get the best results from Business Process Management (BPM) when you enable end-to-end cross-functional processes, to realize a specific business objective.
A few examples of end-to-end, cross-functional processes are as follows:
The ideal way to enable end-to-end processes is using loosely coupled integration between a number of modular business processes.
It is always a good practice to separate your core production processes from your monitoring processes. Production processes have higher scalability, performance, and availability requirements than monitoring processes. An example of a core production process is the order fulfillment process. An example of monitoring processes are audit, compliance, and KPI calculation processes.
You can have loosely coupled integration between production and monitoring processes using publish and subscribe architecture with Message Broker. For more information, see Design Loosely Coupled Services.
| Note: | It is a good practice to capture monitoring data from a production process and publish it to specific channels, which the monitoring process can then subscribe to. Subsequently, a monitoring process can process the monitoring data as per business needs. |
The steps that you need to follow when you design and develop services are:
Table 3-1 lists the services that can be broadly classified into categories.
The first step in service design is to identify the candidate services. You can identify business services based upon business events. Table 3-2 contains a few examples of business events and related services.
If you identify a service with its related business event, you have event-driven services, which can be easily orchestrated into long running business processes.
Once you have identified a service, the next step is to define a service contract. The service contract specifies the functions that a service provides in a format that the service consumer easily understands. A service contract defines how a service can be used and specifies the Quality of Service (QoS) parameters for a service. However, a service contract does not contain any implementation level details.
After defining the service contract, the next most important step is to define service messages. A service receives an input message from service consumer and may or may not return a message to the consumer. Define an appropriate service message schema for each service message.
The next step is to define pre and post conditions for each service. Pre-condition represents the condition which should be satisfied, before a service is invoked. The service consumer has to ensure that the service is invoked, only when the pre-condition is satisfied. The service provider has to ensure that post conditions are satisfied after the service invocation is completed. If you develop your services using this method, you can perform better exception management for services.
You need to decide whether the service is invoked in a synchronous or asynchronous mode. Small and data oriented services such as obtaining a customer address, can be designed in a synchronous mode. Long running services that require state management, should be designed as asynchronous services. Asynchronous services are more loosely coupled and scalable compared to synchronous services.
Services should be more course-grained in comparison to API calls. You should decide on the actual granularity based upon your specific situation. A service call involves a round trip on the network. For performance reasons, you should try to minimize round trips on the network. In case you have too many fine-grained services, it is good practice to create a course-grained service by performing a light weight orchestration of the fine-grained services. Subsequently, you can expose the course-grained services to the user.
Services are required to meet minimum quality requirements in terms of availability and performance. Service providers are required to have a Service Level Agreement (SLA) with service consumers. You should understand and specify QoS requirements well in advance.
One way to improve your QoS is to design your service as idempotent. Idempotent services do not change the state of the system, even if the service is invoked by the same input message several times. With idempotent services, you can easily use standards such as web service reliable messaging, which can re-transmit a message in case of failure. All read only services are idempotent.
However, even write services can be designed as idempotent. This design ensures that your services are more reliable and improves QoS. For example, when a service receives an invoice from a supplier, the invoice amount should be added to the total accounts receivable amount. In such a scenario, you can first assign a unique number to the invoice in the database and then increase the account payable amount. If the same message is sent again, the uniqueness constraint of the invoice number throws a database exception and discards the duplicate message.
If you design your service with a proxy service as the front end, you can obtain several advantages using a proxy service as your main service. A proxy service can be used for authentication, enrichment, transformation, and versioning. The use of proxy services establishes a loose coupling between service providers and consumers.
You should identify business functions that are reusable across different domains or departments. Such functions should be prime candidates for being exposed as standard based services.
Services should be designed as loosely coupled. There should be minimum coupling between service consumers and service providers. The best practices to design loosely coupled services are as follows:
In the case of document-oriented services, the service consumer interacts with the service by sending documents that are meant to be processed as complete entities. These documents are written in XML, and defined in a commonly agreed upon schema between the service provider and consumer. For example, a document-oriented service is a purchase order processing service which receives a purchase order (in XML form), processes it, and returns a purchase order confirmation (XML document) to the client. JPDs are designed to be document-oriented. A JPD uses a document and processes it as an entity.
|
