The immediate goal of this blog is to suggest a solution for the building of state-of-the-art electronic healthcare record (EHR) systems suitable for both organizations that have already invested in a computerized infrastructure and those that have not. There are many vendors proving tools for such endeavors. Here, I have chosen one of the market leaders - Oracle - to illustrate a solution. Since the Oracle tools that I show below are standards based, the concepts will carry over to the tools provided by many of the other vendors. I'll discuss the design of a system that automates business processes when that makes sense, hands off tasks to humans where they can do the job better (according to some criterion) and that can interoperate with heterogeneous systems (local and remote) efficiently and securely. While the language that I use will sometimes be that found in the EHR literature, the solutions discussed will be widely applicable. Please note: This post is still presented in draft form.
Service Component Architecture within SOA Composite Applications
Service Component Architecture (SCA) provides a model for assembling distributed groups of service components into an application, enabling you to describe the details of a service and how services and service components interact. Composite applications are used to group service components and wires are used to connect service components. SCA helps to remove middleware concerns from the programming code by applying infrastructure declaratively to composites, including security and transactions.
An SOA composite is an assembly of services, service components, and references designed and deployed in a single application. Wiring between the services, service components, and references enable message communication. The details for a composite are stored in the composite.xml file.
Services (shown at left in figure below), such as a web services or JCA adapters, providing an entry point to the SOA composite application.
References (shown at right in figure below) send messages to external services in the outside world, such as web services and JCA adapters.
The figure below provides an example of a composite that includes an inbound service binding component, a BPEL process service component, a business rules service component, and two outbound reference binding components.
You can invoke other deployed SOA composite applications from your SOA composite application. The other applications must be deployed.
The component palette shown to the right in figure below provides the various resources that you can use in a SOA composite. It contains the following service components and adapters:
Service components
Displays the BPEL Process, business rule, human task, and mediator service that can be dragged and dropped into the designer.
Service adapters
Displays the JCA adapter (AQ, file, FTP, Database, JMS, MQ, Oracle Applications, Oracle BAM, and EJB Service), B2B binding component, SDO binding component, and web service binding component that can be dragged into the left or right swimlanes.
You add a service binding component to act as the entry point (ep) to the SOA composite application from the outside world.
You can also automatically create a service binding component by selecting "Expose as a SOAP Service" when you create a service component.
However, you cannot invoke a representational state transfer (REST) service from the SOA Composite Editor.
Activities (in the figure below) are the building blocks of a BPEL process service component. Oracle BPEL Designer includes a set of activities that you drag into a BPEL process service component. You then double-click an activity to define its attributes (property values). Activities enable you to perform specific tasks within a BPEL process service component.
A partner link (in the figure below) enables you to define the external services with which the BPEL process service component is to interact. You can define partner links as services or references (for example, through a JCA adapter) in the SOA Composite Editor or within a BPEL process service component in Oracle BPEL Designer.
The method by which you create partner links within the BPEL process in Oracle BPEL Designer impacts how the partner link displays (above) in the SOA Composite Editor. The WSDL file can be on the local operating system or hosted remotely (in which case you need a URL for the WSDL).
Adapters enable you to integrate the BPEL process service component (and, therefore, the SOA composite application as a whole) with access to file systems, FTP servers, database tables, database queues, sockets, Java Message Services (JMS), MQ, and Oracle E-Business Suite.
You can configure BPEL process monitors in Oracle BPEL Designer by selecting Monitor from the dropdown list above the Designer window. BPEL process monitors can send data to Oracle BAM for analysis and graphical display through the Oracle BAM adapter (shown in the Service Adapters section at the right of the figure below).
Oracle User Messaging Service
Oracle User Messaging Service provides a common service responsible for sending out messages from applications to devices. It also routes incoming messages from devices to applications.
You can easily send outgoing notifications from a BPEL process flow or invoke outgoing and incoming messages for tasks assigned to users from a human task.
{ Click on any of these images for a larger view }
