Case processing is a complex business process in general, and especially in complex enterprises such as social programs and insurance claims. There are many exception paths through the process, and even the so-called " happy path " through the process is long and complicated. Opportunities abound in the case processing business process for automation and service oriented design and development. The team that worked on this project adapted a business process model created in WebSphere Business Modeler for the purpose of demonstrating how SOA provides added value over traditional programming methods in implementing the business process.
Prior to undertaking this challenge, the development team had no previous experience with the SOA architectural style nor the SOA programming model. The architects arranged education in the tools used (WID, WPS, WESB) and spent time educating the developers on the SOA style and programming model. In the end, the development team became adept in the concepts and able to design and develop independently.
The result of this challenge is described below. The team created a set of reusable services in the Service Component Architecture (SCA) and three business processes in the Business Process Execution Language (BPEL), along with an underlying data structure and a rich web interface to present the user experience and demonstrate the technical concepts. this article will describe the key elements of the design of the application and the resulting development of the processes and services, and finally discuss the deployment and testing of the application.
In this development effort, we set out to develop and demonstrate a variety of key service oriented concepts. these concepts relate directly to what is needed in typical business processes, which is what the goal of SOA is, to provide an IT solution that aligns to business process.
The list below describes these fundamental concepts.
- Service Orientation: Positions services as IT assets that are expected to provide repeated value over time, exceeding initial development costs.
- Automated Process Flow: Coordinates the actions of people and service components to ensure that all cases go through a uniform sequence of processing steps. The automated process reacts to events, and determines when it is ready to progress to the next processing step
- Service-Based Activities: The automated process flow contains steps that are carried out by service components. The flow invokes service operations, passing information available at a specific point in the process. Service operations can perform actions or return information that the process propagates forward in the automated flow.
- Human-Directed Activities: The automated process flow contains steps that require the attention and action of a person. The person is informed of the pending action through a workload dashboard maintained in the systems user interface. At a minimum, the person indicates the result of the action through the systems user interface, allowing the process flow to continue.
- Time-Driven Activities: Within the automated process flow, some activities must occur at specific points in time. A process flow can start at a specified time, or be suspended for a specified time. Time-driven activities can be executed once or executed repeatedly according to a schedule.
- Informational Alerts: The automated process flow can detect conditions that are important to users of the system. At those points, the flow can generate informational alerts directed to one or more system users. These alerts are displayed on the users dashboard.
- Externalized Business Rules: Process flow is directed by applying business rules at decision points. The rules can be updated while the system is in operation, through a dedicated administrative interface.
Designing the Application
This section details the many considerations during the desing of the application.
Use Case Design Pattern
Defining the usage of a system is a key first step in the design and development process. this is true in any architecture or programming style, end espcially pertinent to SOA design and development. In the proof of concept, the design process started with defining a set of use cases that embodied the goals that the PoC set out to achieve. more precisely, the use cases were chosen to support the SOA concepts that were being demonstrated through the proof of concept.
To facilitate the development of the application components, services, and processes, and to document the use cases a template was constucted and used to describe each use case. These were created as Word documents and had the following primary parts.
Figure 1. Use Case
The use case document has several important characteristics. the Use Case document describes who or what (actors) is involved in a particluar usage of the system, and what those actors do in that usage scenario. this usage is captured in the main flow of the use case, as well as in alternate flows (not shown) that might occur if certain conditions are met or certains errors occur. The Use Case fully describes one use of the system, and the collection of use cases fully describes all uses of the system. with these in hand, the designers and developers of the system can completely decribe, at a technical level, the data, behaviors, and characteristics of the system.
For a complete template of the use case document refer to the downloads section of this article.
The table below describes the use cases that were defined for the PoC
|Use Case Name||Description|
|Display Examiners Dashboard||A disability examiners dashboard is a display that keeps the examiner informed of the state of their overall workload, actions that they need to perform, and events that are relevant to the cases they are working. The dashboard is the examiners starting point for accessing the cases they are working, performing and completing assigned actions, and viewing extended information about events. This use case describes how the examiner displays the dashboard and the information that the dashboard displays.|
|Display Case Information||The Case Information Display gives the examiner detailed information about a particular case and access to all of the functionality needed to examine, analyze, update, and manage activity related to the case throughout the determination process.|
|Assign Case to Primary Examiner||Every case in the system is assigned to a disability examiner who is responsible for developing the case and managing it through the determination process. This use case describes how an examiner becomes the primary examiner for a disability case|
|Submit Case to System||This use case describes how a disability case enters the system. The primary actor is an external system that has gathered enough information about a case to submit it to the system to complete the determination|
|Solicit Electronic Evidence Document||A disability examiner begins the process to obtain electronic evidence documents that support case allegations from the sources identified in the case. The system sends notices to the selected providers. If a provider does not respond within a specified number of days, the system reminds the disability examiner to perform follow-up actions.|
|Submit Electronic Evidence Document||After receiving a solicitation for an electronic case evidence document (UC005), the evidence provider supplies a document through an intermediate staging system. The staging system notifies the case system of the submission and the submission is added to a case"s evidence collection. The primary examiner is alerted.|
|Transfer Examiner"s Workload||System recognizes that work is performed by workers that belong to organizations, which are arranged in a hierarchy. An organization may optionally be associated with a workplace, which defines its geographical location. This use case describes how an examiner"s work assignments can be transferred to another examiner within the same organization.|
|Transfer Organization"s Workload||This use case describes how responsibility for work in the system can be transferred from one organization to another organization. This capability would be needed, for example, if a natural or man-made emergency prevented an organization from performing work. Transferring workload from an organization removes work assignments for workers in that organization and assigns that work to workers in other organizations.|
|Request Assistance Document||During case analysis, the examiner requests assistance on the case. The system selects the user to provide the assistance based on a set of business rules.|
|Provide Assistance Document||After receiving an assistance request document, the assistance provider supplies an annotation through an annotations submission page. The system notifies the primary examiner who initiated the assistance request and the annotation is added to a case"s annotation collection.|
Service Component design
Service implementations that adhere to a well-defined internal architecture are easier to design, build, maintain, and extend over their service lifetimes. The PoC team spent much of its start-up time considering the patterns to be used during application and service construction. Since the team was small, it was possible to agree on conventions that would be used in all software produced during the project. This was an advantage for our project. All of our services used similar structures and conventions. However, such uniformity is not absolutely required for SOA to work. Different development organizations can fashion their work according to the conventions they develop. As long as service interfaces are well-defined and effectively implemented, an enterprise can use a variety of techniques to build the software.
In the design phase of the project, the team met daily to work through the business processes and the use cases to determine the services required. the diagram below depicts the services and their relationships in a typical uses/is used by UML diagram. The table below lists the services that were identified and the basic functionality of each. This served as a starting point for the detailed specification of the services. later in the article we present an sample of the service specification template that was used in the project to describe the services in sufficient detail for a developer to build the service. Given the small size of the team, the same people specifying the services were building them. However the team was vigilent in employing best practices in documenting the service specifications, a practice that should be used in any size team.
Figure 2. Service Model
|Alert Service||An alert is a notification of a business event. An alert contains information about the event along with context information that can be used to initiate specific action based on reception of the alert.|
|Business Event Audit Service||Registers, records, and retrieves significant business events, implementing the concept of an audit trail. Event types are identified by a name, whose format is unspecified by the service, but are suggested to follow the rules for unique domain names.|
|Document Service||Responsible for performing operations to store and retrieve electronic documents from a document management repository. This general service is used by the Case Documentation Service to store documents specifically related to cases.|
|Organization Service||Manages models that reflect enterprise organizational relationships and membership of workers to organizational units. Every worker belongs to exactly one organization. Every organization belongs to exactly one parent organization. Organizations may optionally be associated with Workplaces, which define their geographical locations.|
|Text Communication Service||The Text Communication Service is responsible for maintaining a library of message templates, generating and transmitting messages derived from those templates, adding customized information at named insertion points. The service handles Email and SMS Text communication.|
|Work Assignment Service||Implements the concept of work assignment, in which types of assignments can be dynamically defined, and instantiated along with context information relevant to the assignment type. Assignments may be bound to any named entity, including, but not limited to users of a system. Supports transfer of assignment and maintaining assignment histories.|
|Vendor Service||Vendor is a general term applied to any external business that can act as a source of case documentation. This service maintains a registry of case documentation vendors, including their business names, contact information, and interaction preferences.|
|Case Information Service||Maintains basic information about cases in the system. The service manages the claim, claimant, and contact information related to a case. The service uses a unique key to retrieve all the case related information.|
|Case Processing Service||A composite service responsible for performing operations that maintain relationships between cases and other parts of the business domain according to business rules. Operations include selecting a worker for case assignment based on case, organization, and worker attributes. Other operations include transferring a case, and summarizing the case workloads loads of organizations.|
|Evidence Service||Maintains the relationship between cases and their supporting documentation.|
|Case Assistance Service||A service dedicated to coordinating the actions of many workers who may be assigned to perform tasks related to a case.|
Each service in an SOA must have a speciication. in this project, the team described the functionality of the services through a service specification document. an exerpt from a service specification document is shown below.
Figure 3. Service Specification (1)
Figure 4. Service Specification (2)
The important elements of the service specification are desribed below
- Service Operation. Fully describes the functions that will be exposed as service operations by the service through it's WSDL. an operation has input parameters, return values, and possible faults that can be handled by the service and passed to the consumer.
- Data Types. Services expose operations on data. the data types description in the service specification defines the expected type and organization of the incoming and returning data. This is critical to the consumer of the service to ensure proper invocation of the service operation and a proper understanding of the data the service operates on and returns.
For a complete template of the service specification document refer to the downloads section of this article.
Data modeling without considering service boundaries often results in a model that is optimized for a single application, but lacking the flexibility to support loosely-coupled, reusable services. The PoC team found a better approach was to use application requirements to create a service model that includes support for flexible namespaces, supplemental object attributes, and other customization features. At that point, it was possible to create smaller, simpler data models for each of the services needed to support the application.
Figure 5. Data Services
Dynamic Registration of Service objects
To be useful in wide range of applications, a service must not require development or configuration effort to accommodate a new usage. The services specified during the project upheld this principle. The team considered how to introduce variations of durable service-managed object types to support different uses by the case system and potentially other applications. One approach to building an extendable service might be to statically configure it with the attributes of the object types, using XML or similar means. The team rejected this approach as incompatible with a successful service-oriented architecture. New applications would require developer effort to define new object types in the service to support each new application. Instead, all services developed for the project allow new object types to be dynamically registered with the service using operations in the service interface. This approach allows new applications to provision themselves with customized object types supported by the service. This provisioning could be implemented through an administrative user interface built for the service, or directly in the client application code. The PoC project used both approaches.
The following is a representation of the software configuration constructed in the project. the software components are arranged and interconnected in such a way as to provide separation of concerns and a modular design that is consistent with modern MVC patterns and the SOA architectural style.
Figure 6. Software Architecture
Building the Application
Working from the design of the application, the team parceled out construction tasks that flowed logically from the modular design of the application. SOA provides the ability to divide the work along service component boundaries with associated development tasks as shown in the diagram below. In this article, we will not discuss database implementation or UI implementation. The focus of the article is on the service component and BPEL implementations. Suffice to say that a signficant effort is also required to implement the presentation layer and associated controller logic, as well as a well defined data access layer. In this project, we used the Struts framework and Ajax in the user interface layer, and Hibernate in the data access layer. for more information about these, contact the authors and also refer to the resources section of this article.
The following sections will describe important elements in the development of the SOA application using the Service Component Architecture and the BPEL, using the WebSphere Integration Developer software.
The sequence diagram depicts the order of operations in the process and which component handles the operation request. a sequence diagram is very useful as a design tool for orchestrating the business process.
Figure 7. Sequence Diagram of Evidence Request Process
Service Interface (WSDL)
Each service in the application is defined by its Web Services Definition Language (WSDL) file. In our example, the WSDL, and XML file, is displayed and modified in the WebSphere Integration Developer WSDL editor. The service operations and input/output types are described in the WSDL such that consumers know precisely what the service offers for operations and what it expects for parameters and what it returns for results. The figure below shows the WSDL for one service in the application.
Figure 8. WSDL of Evidence Process
A good illustration of the work performed by the project is the Evidence Solicitation business process. The project built a BPEL component responsible for obtaining electronic evidence documents.
When a case is submitted to the system, it contains a list of potential documents along with their providers (vendors that are currently holding the documents). The document providers are visible to the examiner in the case information display. When an examiner decides that a document is needed to supplement basic case information, the examiner starts the solicitation process.
The process receives an evidence item which contains the case identifier, the type of evidence needed, and the vendor from which to obtain it. The process sends a communication to the vendor that contains information that the vendor can use to locate the desired document, and a coded URL that can be used to upload a copy of the document to a secure document repository, where it can be made part of the case information. This communication could potentially take many forms, including fax or postal mail. For the projects purposes, however, email communication offered the most straightforward communication channel to implement.
After sending the initial communication, the process monitors the progress of the request. If the requested document does not appear in the repository after a pre-set number of days, the process sends a followup alert to the examiner. This alert contains customized context information about the request that the display application uses to present information about the current state of the request. At that point, the examiner can decide the next course of action. The process accepts three event messages; cancel request, continue (keep waiting), and continue with communication (send another communication to the provider and keep waiting).
When the vendor submits the document to the repository, the process updates the case to indicate that the document is available, and sends a evidence submitted alert to the examiner. At that point, the process is complete. The examiner can now view the submitted evidence document.
Figure 9. Evidence Request Process in BPEL
The BPEL process shown above is a snippet of a much larger and robust BPEL process definition. To see the complete BPEL process, refer to the download section and locate the BPEL process image download link.
The project implemented the process as a BPEL component in its own SCA module. The first step was to define the WSDL interface to the process, which describes the operations or events that the process supports. The startRequest operation starts the process. The cancelRequest, continueRequest, and continueRequestWithCommunication operations define event messages that allow the examiner to control the execution of the process. The submitEvidenceDocument operation signals that the requested document has been submitted. Finally, the captureCurrentState operation allows clients to display progress information.
Figure 10. WID Assembly Diagram of Evidence Request Process
The assembly diagram shows that the process depended on a significant number of the services built for the project. These appear as imports on the right side of the diagram.
Deploying the Application
The following is the architecture of the PoC as it was deployed. This was a proof of concept demonstration, and as such the deployment architecture was not intended to be highly scalable or fault tolerant. We chose to deploy services across a heterogenous hardware and operating system landscape to demonstrate virtualization in an SOA and to some degree for convenience in the demonstration. A production level architecture would likely look much different, and the reader should be aware that the limited scope of this project dictated the deployment architecture.
Figure 11. Deployment Architecture
The deployment architecture has several key features that were important to the demonstration of the concepts in the Proof of Concept.
- Intranet and Internet presence. the evidence provider is outsite the firewall, manifested by a user on the internet using gmail. the intent was to demonstrate that a heterogeneity of participants in the process is possible.
- Service Virtualization. a key feature of SOA is the ability to reference and invoke services from multiple endpoints. the configuration of the endpoints allows for virtualization of the services as required. in the demonstration, the team switched from a centrally located email service to a remote service endpoint at will.
- Data Federation. data from heterogeneous sources is federated and exposed to the application layer through data services. data services handle all CRUD operations on the data.
- Horizontal Scaling and fault tolerance. the software stack is deployed in a clustered environment with 2-way WAS cluster. this is expandable to n-way cluster.
There are a number of ways to package an application to run in the WebSphere Application Server, and in the WebSphere Process Server. One approach is to create one single, large deployment unit with all services and associated code. This has the disadvantage of lacking modularity, but has the advantage of ease of deployment.
In this project, we elected to create deployment units (EAR files) for each service component, and an EAR file for the web interface. this allowed us to deploy (or redeploy) services as we needed without needing to deploy the entire application. this proved to be a benefit in development as it was often necessary to make changes to just one service component and redeploy that component. having each service in its own deployment package made the process quicker and the development and testing more efficient.
The picture below shows the WebSphere Application Server with all of the service components installed and running as independant enterprise applications.
Figure 12. Deployment Units
Implementing a business process in SOA using BPEL and the SCA can be a challenge for those new to the concepts. The team involved in this project learned through experience how to take a business process and implement the process in BPEL, invoking services in the SCA architecture. Through this experience the team developed best practices and learned some of the pitfalls to avoid.
This paper summarized the design and development of a project using business process execution and the Service Component Architecture, utilizing the WebSphere family of tools. We have learned that the SOA architectural style and programming model provides significant advantage in realizing a business process in software. The Business Process Execution Language and the development and runtime support of SOA tools provides a robust environment in which to implement long running business processes and maintain state within those processes over long periods of time. Service Component Architecture has been shown through this experience to provide the necessary abstraction away from service implementation details to increase productivity in the development teams and enable reuse and composition of services, a vital advantage to the SOA architectural style.
For More Information
To learn more about the project and request sample code, contact the authors.
|Samples from the article||SOAInActionBPELSCA.zip||300KB|
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Learn more about Hibernate.
- Read further about Struts and the MVC model.
- Learn about Service Component Architecture programming model in this DeveloperWorks Article.