Human Workflow -- Business Processes -- Service Component Architecture -- SOA -- EHR

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 }

SOA, Web Services, BPEL, Human Workflow, User Interaction and Healthcare Systems

Lack of integration among legacy healthcare systems and applications means a continued reliance on manual processes that can introduce high risk errors into critical medical data. And isolated systems can compromise a provider's ability to follow an individual patient's care seamlessly from intake to treatment to aftercare.

While healthcare providers recognize that integration can help them achieve better service levels, many have been reluctant to proceed because of the critical nature of healthcare systems. But the approach to integration need not be a radical one of system rip and replace, nor does it have to precede through the development of system-by-system integration solutions.

Service Oriented Architecture (SOA) is a standards-based approach to integrating IT resources that can enable you to leverage existing assets, while at the same time building an infrastructure that can rapidly respond to new organizational challenges and deliver new dynamic applications. The SOA approach can help free application functionality from its underlying IT architecture and make existing and new services available for consumption over the network.

To derive a new value from existing services and go beyond simple point-to-point integration, you will need to combine and orchestrate these services in a business process. You will want to connect them in a coordinated manner, for example, have the result(s) from one service be the input to another service and have branching logic based on the outcome. Of course, you can use Java, C#, or another programming environment to call the services and manage the processes and data, but there is an easier, declarative way.

BPEL

An important standard in the SOA world is BPEL, or Business Process Execution Language, which serves as the glue to tie SOA-based services (Web services) together into business processes -- at least the portions that can be automated. The resulting BPEL process can itself be exposed as a Web service, and therefore, be included in other business processes.

The BPEL standard says nothing about how people interact with it, but BPEL in the Oracle Inc. BPEL Process Manager (to be discussed in my next post) includes a Human Workflow component (shown in the figure below) that provides support for human interaction with processes.



BPEL and User Interaction

I began an introduction to BPEL and human workflow towards the bottom of my December 14 post. Click here for a good deal more on this topic.

Humans can be involved in business processes as a special kind of implementation of an activity. To facilitate this, a new BPEL activity type called human task is required. From the point of view of the BPEL business process, a human task is a basic activity, which is not implemented by a piece of software, but realized by an action performed by a human being. In the drag-and-drop design pallet shown in the figure above, the actor of a human activity can be introduced into a BPEL process by using your mouse. A human activity can be associated with different groups of people, one for each generic human role.

People dealing with business processes do so by using a user interface. When human activities are used, the input data and output data must be rendered in a way that the user can interpret. More on this in upcoming posts.

Human resolution or disambiguation -- Integrating human workflow in BPEL processes -- Errors in statistical matching of attributes to an individual

To locate health records, statistical matching attempts to string together enough identifying information about an individual to substitute for a unique personal identifier. It involves matching attributes, such as last name, first name, birth date, address or zip code, and gender, and it may use medical-record numbers and all or part of the Social Security number.

The problem with personal attribute keys such as name and address is that they are usually not unique to the individual, change over time, and are often entered into different systems in different formats. And data-entry errors, such as misspellings, add to the difficulties with this type of key. Repeated collection, distribution, storage, and use of these data also represent an important identity-theft risk.

Statistical matching can attempt to correct for some of these changes and errors: The most straightforward process is to tag all of the near matches for human resolution, or disambiguation. Such disambiguation imposes significant costs and operational inefficiencies, particularly if the physician must resolve the ambiguities. Advanced approaches “score” matches on “closeness” to the input set. Those with a high score may be accepted as a match. However, all such efforts are subject to the probabilistic errors inherent in statistical matching systems.

As discussed in earlier posts, there are two types of errors - false positives, in which two different persons’ records are declared to be a match, which can lead to such errors as the wrong patient’s health data being obtained; and false negatives, in which two records for the same person are thought to relate to different people, leading to such consequences as some of the patient’s data being excluded. Both of these errors can lead to serious medical errors, waste (e.g., repeats of tests or the wrong tests), and considerable deviation from the promises of continuity and quality of care postulated for a connected digital health care system.

Disambiguation is a process through which multiple potential identification matches are further parsed until the patient can be matched with his or her data with sufficient certainty to allow for the delivery of a health service with reasonable confidence. The complexity of disambiguation varies according to factors such as the number of potential matches and the type of information available for further analyses. When sufficient digital data are not available to further differentiate potential matches, automated disambiguation may not be possible and may require human involvement. This last case will be the focus of the rest of this post and my next post.

Disambiguation entails implementing significant new workflows and may require substantial time and resources. When human involvement is required, many of the potential benefits of automation are lost. For example, at the point of care, disambiguation is often done by asking the patient further questions regarding personal characteristics and/or health care history. In some situation, disambiguation may not be possible, as when the patient is not present and information needed to further facilitate matching may not be accessible.

I will show how one vendor, Oracle, implements human tasks that can provide workflows such as those identified above. However, these Oracle services can be accessed by applications created with development tools from other vendors (my discussion will use Microsoft Visual Studio).

Introduction to BPEL and Human Workflow

Business Process Execution Language (BPEL), one of the key technologies for Service Oriented Architecture (SOA), has become the accepted mechanism for defining and executing business processes in a common vendor-neutral way. Apropos of this discussion, business processes often require human interactions as well.

User Interaction in Business Processes

BPEL business processes are defined as collections of activities that invoke services. BPEL doesn't make a distinction between services provided by applications and other interactions, such as human interactions. And that's important since real-world business processes often integrate not only systems and services but also users. User interactions in business processes can be simple, such as approving certain tasks or decisions, or complex, such as delegation, renewal, escalation, nomination, or chained execution . . . and matching an ID with an individual.

Task approval is the simplest and probably the most common user interaction. In a business process for opening a new account, a user interaction might be required to decide whether the user is allowed to open the account. If the situation is more complex, a business process might require several users to make approvals, either in sequence or in parallel. In sequential scenarios, the next user often wants to see the decision made by the previous user. Sometimes, particularly in parallel user interactions, users aren't allowed to see the other users' decisions. This improves the decision potential. Sometimes one user doesn't even know which other users are involved - or whether any other users are involved at all.

A common scenario for involving more than one user is workflow with escalation. Escalation is typically used in situations where an activity doesn't fulfill a time constraint. In such a case, a notification is sent to one or more users. Escalations can be chained, going first to the first-line employees and advancing to senior staff if the activity isn't fulfilled.

Sometimes it's difficult or impossible to define in advance which user should perform an interaction. In this case, a supervisor might manually nominate the task to other employees; the nomination can also be made by a group of users or by a decision-support system.

In other scenarios, a business process may require a single user to perform several steps that can be defined in advance or during the execution of the process instance. Even more complex processes might require that one workflow is continued with another workflow.

User interactions aren't limited to approvals; they can also include data entries or process management issues, such as process initiation, suspension, and exception management. This is particularly true in long-running business processes, where, for example, user exception handling can prevent costly process termination and related compensation for those activities that have already been successfully completed.

As a best practice for human workflows, it's usually not wise to associate human interactions directly with specific users; it's better to connect tasks to roles and then associate those roles with individual users. This gives business processes greater flexibility, letting any user with a certain role interact with the process and enabling changes to users and roles to be made dynamically.

BPEL and User Interaction

So far we've seen that user interaction in business processes can get quite complex. Several vendors today have created workflow services that leverage the rich BPEL support for asynchronous services. In this fashion, people and manual tasks become just another asynchronous service from the perspective of the orchestrating process and the BPEL processes stay 100% standard.

In my next post, I’ll talk about some of the specifics of how you might implement a BPEL process that includes human workflow/tasks for disambiguation using tools such as Oracles JDeveloper and Microsoft Visual Studio. The next two figures are meant to give you a preview of that discussion.

{ click the figures for a larger view }


Click here for more on Microsoft Visual Studio 2010

Click here for more on Oracle BPEL and Human Workflow

Ontology-Based Software Application Development -- Java and .NET

Consider the following scenario: A programmer needs to read data from a database via the JDBC interface. The system administrator of the organization provides user name and password, which obviously need to be used in the process. Then, the programmer

1. Searches the entire API for a method call (or calls), which takes a database user name as an input parameter.

2. Has to understand how various API calls should be sequenced in order to go from the connection information all the way to actually receiving data from the database.

If the APIs are not semantically rich (i.e., they contain only syntactic information, which the programmers have to read and interpret), understanding, learning and using an API can be a very time consuming task.

For a discussion of how the application of ideas from the areas of "Knowledge Management" and "Knowledge Representation" -- The enrichment of purely syntactic information of APIs with semantic information -- will allow the computer to perform certain tasks that normally the human programmer has to perform, see

http://www.aifb.uni-karlsruhe.de/WBS/aeb/smartapi/smartapi.pdf

A similar semantification of Web services (Ontology-enabled Services) is being widely discussed and implemented today.




See, for example,

http://www.cs.vu.nl/~maksym/pap/Onto-SOA-WAI.pdf

and

http://www.computer.org/portal/web/csdl/doi/10.1109/AICT-ICIW.2006.141

A number of my earlier post have been about Protégé , the popular ontology development tool, and OWL, one of the main ontology languages. To continue that discussion, see

http://www.sandsoft.com/edoc2004/KnublauchMDSW2004.pdf

which discusses a realistic application scenario -- some initial thoughts on a software architecture and a development methodology for Web services and agents for the Semantic Web. Their architecture is driven by formal domain models (ontologies).

Central to their design is Jena, a Java framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL, SPARQL and includes a rule-based inference engine.

Jena is open source and grown out of work with the HP Labs Semantic Web Programme.

For more on Jena, see

http://jena.sourceforge.net/documentation.html

Jena is a programming toolkit that uses the Java programming language. While there are a few command-line tools to help you perform some key tasks using Jena, mostly you use Jena by writing Java programs.

But, .NET developers have similar resources. See, for example

http://www.ic.uff.br/~esteban/files/sbgames09_Alex.pdf

for a development environment using Microsoft Visual Studio, the base language C#, and the graphical library XNA. Protégé has been used for designing the ontology, and the application uses the OwlDotNetApi library.

This 2009 work demonstrates a step-by-step implementation, from the definition of an ontological knowledge base to the implementation of the main classes of a strategy game. It aims at serving as a basic reference for developers interested in starting .NET development of ontology-based applications.

Electronic Health Records (EHR) – Semantic Interoperability – Part 2

Before discussing the connection(s) between electronic health records (EHR) and semantic interoperability directly, I’d like to spend a little time talking about Semantic Web interoperability (not necessarily the same thing as the interoperability of present and future EHS systems).

In general, semantics is the study of meaning. Semantic Web (also called Web 3.0) technologies help separate meanings from data, document content, or application code, using technologies based on open standards. If a computer understands the semantics of a document, it doesn't just interpret the series of characters that make up that document: it understands the document's meaning. See my July 20 post for a brief introduction to this material.



Benefits of the Semantic Web to the World Wide Web

The World Wide Web is the biggest repository of information ever created, with growing contents in various languages and fields of knowledge. Search engines might help you find content containing specific words, but that content might not be exactly what you want. What is lacking? The search is based on the contents of pages and not the semantic meaning of the page's contents or information about the page.

Once the Semantic Web exists, it can provide the ability to tag all content on the Web, describe what each piece of information is about and give semantic meaning to the content item. Thus, search engines become more effective than they are now, and users can find the precise information they are hunting. Organizations that provide various services can tag those services with meaning (service-oriented architectures -- SOA -- are discussed in my June 20 post and mentioned again below, this time in the context of semantics); using Web-based software agents, you can dynamically find these services on the fly and use them to your benefit or in collaboration with other services (See http://www.oracle.com/technology/pub/articles/matjaz_bpel1.html for a discussion of the orchestration and choreography of Web services).

Ontologies

The use of words to refer to concepts (the meanings of the words used) is very sensitive to the context and the purpose of these words.

An ontology is a formal representation of a set of concepts within a domain and the relationships between those concepts. It may be used to reason about the properties of that domain, and may be used to define the domain. The word “reason” is an important part of this story and will come up again in a later post, when I talk about Protégé, a free, open source ontology editor and knowledge-base framework.

A domain ontology (or domain-specific ontology) models a specific domain, or part of the world (e.g., healthcare, banking or politics). It represents the particular meanings of terms as they apply to that domain. For example the word card has many different meanings. An ontology about the domain of poker would model the "playing card" meaning of the word, while an ontology about the domain of computer hardware would model the "video card" meaning.

For each domain of human knowledge, an ontology must be constructed, partly by hand and partly with the aid of dialog-driven ontology construction tools (to be discussed in an upcoming post).

Ontologies are not knowledge nor are they information. They are meta-information. In other words, ontologies are information about information. In the context of the Semantic Web, they encode, using an ontology language (to be discussed in an upcoming post), the relationships between the various terms within the information. Those relationships, which may be thought of as the axioms (basic assumptions), together with the rules governing the inference process, both enable as well as constrain the interpretation (and well-formed use) of those terms by the Info Agents (to be discussed in an upcoming post) to reason new conclusions based on existing information, i.e. to think. In other words, theorems (formal deductive propositions that are provable based on the axioms and the rules of inference) may be generated by the software, thus allowing formal deductive reasoning at the machine level. And given that an ontology, as described here, is a statement of Logic Theory, two or more independent Info Agents processing the same domain-specific ontology will be able to collaborate and deduce an answer to a query, without being driven by the same software.

When an organization adapts an ontology-driven approach, it can capture and represent its total knowledge in a language-neutral form and deploy the knowledge in a central repository that provides the same semantic meaning across applications.

Semantics are the future of service-oriented integration

To properly model and manage a service-oriented architecture (SOA), enterprise architects must maintain active representations of the services available to the enterprise. Specifically, to discover and organize their services, the architects must use best practices that model and assemble services using metadata, encapsulate business logic in metadata for dynamic binding, and manage with metadata. Ontologies provide a very powerful and flexible way to aggregate, visualize, and normalize this service metadata layer.

Note: When delivering services as part of a service inventory, there is a constant risk that services will be created with overlapping functional boundaries, making it difficult to enable wide-spread reuse. Normalization addresses this problem. When services are delivered with complementary and well-aligned boundaries, normalization across the inventory is attained. Note also how the quantity of required services is reduced.

Semantic technologies provide an abstraction layer above existing IT technologies, one that enables the bridging and interconnection of data, content, and processes across business and IT silos.

For advanced IT readers

For a rather technical discussions of this topic, see the video Artificial Neural Network based Techniques for Semantic Data Interoperability below and parts of my article Using Neural Networks and OLAP Tools to Make Business Decisions to which there is a link in the bibliography at the very bottom of this blog.



To be continued …

Electronic Health Records (EHR) - Semantic Interoperability - Part 1

To press a suit means one thing to a tailor and another thing to a lawyer.

A free radical means one thing to a chemist but meant another thing to members of the House Un-American Activities Committee (HUAC) during the 1950’s.

And, medication for pain and pain medication don’t always mean the same thing. The controversy surrounding the recent death of Michael Jackson illustrates this last point.

In the examples above, as in clinical terminology, words can take on different meanings depending on factors like time or place (i.e., context).

Furthermore, clinicians and organizations use different clinical terms that mean the same thing. For example, the terms heart attack, myocardial infarction, and MI may mean the same thing to a cardiologist, but, to a computer, they are all different. There is a need to exchange clinical information consistently between different health care providers, care settings, researchers and others (semantic interoperability), and because medical information is recorded differently from place to place (on paper or electronically), a comprehensive, unified medical terminology system is needed as part of the information infrastructure.

Interoperability

Interoperability is the ability of two parties, either human or machine, to exchange data or information.

First, syntactic interoperability guarantees the exchange of the structure of the data, but carries no assurance that the meaning will be interpreted identically by all parties. Web pages built with HTML or XML are good examples of machine-to-machine syntactic interoperability because a properly structured page can be read by any machine with a Web browser. The meaning of the page to a particular machine may vary substantially; however, this is not usually considered a problem because the semantics of a page are meant to be interpreted by human viewers.

Next, human or semantic interoperability guarantees that the meaning of a structure is unambiguously exchanged between humans. Documents such as progress notes, referrals, consults, and others achieve semantic interoperability at a clinician-to-clinician level by relying on common medical vocabularies.

Finally, computable semantic interoperability requires that the meaning of data be unambiguously exchanged from machine to machine (as shown in the figure below). This does not necessarily mean that all machines need to process the received data the same way, but rather that each machine will make its processing decisions based on the same meaning.



Words and Meanings

The meanings of words change, sometimes rapidly. But a formal language such as used in an ontology -- a rigorous and exhaustive organization of some knowledge domain that is usually hierarchical and contains all the relevant entities and their relations -- can encode the meanings (semantics) of concepts in a form that does not change. In order to determine what is the meaning of a particular word (or term in a database, for example), it is necessary to label each fixed concept representation in an ontology with the word(s) or term(s) that may refer to that concept.

When multiple words refer to the same (fixed) concept, in language this is called synonymy; when one word is used to refer to more than one concept, that is called ambiguity. Ambiguity and synonymy are among the factors that make computer understanding of language very difficult. The use of words to refer to concepts (the meanings of the words used) is very sensitive to the context and the purpose of any use for many human-readable terms.

The use of ontologies in supporting semantic interoperability is to provide a fixed set of concepts whose meanings and relations are stable and can be agreed to by users. When a word used in some interoperability context changes its meaning, then to preserve interoperability it is necessary to change the pointer to the ontology element(s) that specifies the meaning of that word.

There are a number of tools for the programmatic handling (i.e., creating, querying, etc.) of ontologies. The visual representation of ontologies is an important contribution of these tools.



IBM Integrated ontology Development Toolkit (formerly named IBM Semantics Toolkit) is one of many toolkits designed for storage, manipulation, query, and inference of ontologies and corresponding instances.

An upcoming post will discuss the role and value of semantic technology in service-oriented architectures (SOA).

Technical Interoperability of Disparate Systems - An Electronic Health Record (EHR)-Centric System Implemented with a Service-Oriented Architecture

The independent organizations (a.k.a. silos) shown in Figure 1 typically implement their business processes on different computer systems (Unix, Windows, mainframes), on different platforms (J2EE, .NET) and with different vocabularies. Yet, they all need to communicate in a way that serves, in this case, a trauma victim at the time of his or her emergency, researchers who will later study cohorts of this trauma victim, and sundry others (most of whom are not shown in the simplified model).

This post will discuss an Electronic Health Record (EHR)-centric system implemented with a Service-Oriented Architecture (SOA) -- the business industry’s de facto standard for interoperability. The functions of this system are data collection, management and distribution for both the immediate situation and long term health care experiences.

I’ll address some of the challenges (and opportunities) of technical interoperability, holding off ‘til later posts any discussion of semantic interoperability.

Note: This rather lengthy post is not and is not meant to be a palimpsest on SOA. But, I have included a number of references (links to references) for anyone looking for a more detailed account of this topic.

Figure 1

Figure 2 shows a traditional implementation of the system shown in the use case drawn in Figure 1. When a change -- virtually any change -- is made in one part of this interconnected system, the overall system usually stops working, until system-wide adjustments are made. In short, the figure below shows a system that’s “hard wired.”

Note: For simplicity, these figures and this discussion omit a number of real-world details: for example, the voice communication often employed by police and EMS teams.

Figure 2

To remedy this problem, a new architecture, that of Service-Oriented Architecture (SOA), was devised. An SOA implementation of the system shown in the use case is outlined in Figure 3. At first glance, the SOA-based system might seem more complicated than the system shown in Figure 2. But, as the following discussion will attempt to show, it isn’t.

Figure 3

Note: The major part of this post will be based on a Web services implementation of SOA. However, before concluding this post, I’ll address the oft-heard view that SOA is now “dead.” SOA is indeed alive and kicking in many organizations.

The system in Figure 2, if fleshed out, would move toward becoming the fully connected system shown below (in practice, very few systems are fully connected). In such a system of computer applications, when one node is changed, all other nodes that connect to it would need a new interface to the changed node.

As shown, in a fully connected network with n nodes, there are n x (n-1) / 2 direct paths. That means 15 connections for 6 nodes, 45 connections for 10 nodes, etc.

In contrast, each node in the system in Figure 3 has only one connection – that to a bus, as represented in the figure below.



Service-Oriented Architecture

SOA relies on services exposing their functionality via interfaces that other applications and services can read to understand how to utilize those services.

This style of architecture promotes reuse at the macro (service) level rather than micro (classes) level. It can also simplify interconnection to – and usage of – existing IT (legacy) assets.

Designers can implement SOA using a wide range of technologies, including SOAP, REST, DCOM, CORBA, or Web Services. (I gave a brief overview of DCOM, CORBA and Web Services in my June 16 post and will discuss REST below.) The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.

Albeit in the distant past, I’ve used the Oracle SOA Suite to federate a unified system out of the disparate systems shown in the figures.

This suite, which includes JDeveloper, a robust Java IDE, is by no means the only solution; there are others, both proprietary and open source! For example,

Proprietary: http://i.zdnet.com/whitepapers/cape_clear_Principles_of_BPEL.pdf

Open source: http://orchestra.ow2.org/xwiki/bin/view/Main/

However, the Oracle SOA Suite is a complete set of service infrastructure components for creating, deploying, and managing services. It enables services to be created, managed, and orchestrated into composite applications and business processes. Additionally, you can adopt it incrementally on a project by project basis and still benefit from the common security, management, deployment architecture, and development tools that you get out of the box.

This Suite is a standards-based technology suite that consists of the following:

* Oracle BPEL Process Manager to orchestrate services into business processes
* ESB to connect existing IT systems and business partners as a set of services
* Oracle Business Rules for dynamic decisions at run time that can be managed by business users or business analysts
* Oracle Application Server Integration Business Activity Monitoring to monitor services and disparate events and provide real-time visibility into the state of the enterprise, business processes, people, and systems.
* Oracle Web Services Manager to secure and manage authentication, authorization, and encryption policies on services that is separate from your service logic
* UDDI registry to discover and manage the life cycle of Web services.
* Oracle Application Server that provides a complete Java 2, Enterprise Edition (J2EE) environment for your J2EE applications.

For an overview of the soon-to-be-released Version 11, see

http://www.oracle.com/technology/products/ias/bpel/techpreview/2008-05-01-whats-new-in-oracle-soa-suite-tp4.pdf

Business Process Execution Language (BPEL)

One of the key standards accelerating the adoption of SOA is Business Process Execution Language (BPEL) for Web Services. BPEL enables organizations to automate their business processes by orchestrating services (thus enabling developers to build end-to-end business processes spanning applications, systems, and people in a standard way). Existing functionality is exposed as services. New applications are composed using services. Services are reused across different applications. Services everywhere! For an account of Orchestration versus Choreography, see

http://www.oracle.com/technology/pub/articles/matjaz_bpel1.html

BPEL has emerged as the standard for process orchestration enabling you to build end-to-end business processes spanning applications, systems, and people in a standard way.

In the next figure, I show two pallets of drag-and-drop components available in version 10.3 of the SOA Suite for the development of a BPEL process. Version 11 will be availability shortly.

Introduction to the JDeveloper BPEL Designer

http://download-west.oracle.com/docs/cd/B31017_01/core.1013/b28938/design.htm#CHDIJCGH

Enterprise Service Bus

An Enterprise Service Bus (ESB) is an architectural pattern, not a software product. Different software products can form an ESB. In some cases, companies use multiple products in different areas, leveraging specific functionality to meet their unique requirements. These different products can be federated together as the realization of the ESB pattern.

In the next figure, I show two pallets of drag-and-drop components available in version 10.3 of the SOA Suite for the development of an ESB. As I mentioned earlier, Version 11 will be availability shortly.

Introduction to the JDeveloper ESB Designer

http://download-west.oracle.com/docs/cd/B31017_01/core.1013/b28938/design.htm#CHDIBCCC

Figure 3 introduced Business Activity Monitoring (BAM) and Business Rules to the architecture

Business Activity Monitoring – BAM satisfies a growing need to enable health care executives, and more specifically operations managers, to improve their decision-making processes by first getting a real time view of the business events occurring in their enterprise, and second using the derived intelligence to analyze and improve the efficiency of their business processes.

Understanding Business Activity Monitoring in Oracle SOA Suite
http://www.packtpub.com/article/business-activity-monitoring-in-oracle-soa-suite

Business Rules – Business Rules is one of the newer technologies (typically run from an application server) and is designed to make applications more agile. A business analyst can change business policies expressed as rules quickly and safely with little or no assistance from a programmer

Using Business Rules to Define Decision Points in Oracle SOA Suite

Part 1. http://www.packtpub.com/article/business-rules-define-decision-points-oracle-soa-suite-part1

Part 2. http://www.packtpub.com/article/business-rules-define-decision-points-oracle-soa-suite-part2

For detailed coverage of the Oracle Service Bus, BPEL Process Manager, Web Service Manager, Rules, Human Workflow, and Business Activity Monitoring. See

Oracle SOA Suite Developer's Guide
http://www.packtpub.com/developers-guide-for-oracle-soa-suite-10gr3/book

and

Getting Started With Oracle SOA Suite 11g R1 – A Hands-On Tutorial
http://www.packtpub.com/getting-started-with-oracle-soa-suite-11g-r1/book

When designing an SOA solution, it's not always clear whether you should use a Web services BPEL process or an ESB mediation flow (or both).

http://www.ibm.com/developerworks/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html

Building Event-Driven Architecture with an Enterprise Service Bus

http://www.oracle.com/technology/pub/articles/jellema-esb.html

Software frameworks

You should keep in mind that interoperability issues between platforms can arise when switching from one protocol to another and one software framework to another. Some examples include SOAP, REST, the .Net Framework, Enterprise Java Beans (EJB), and Java Messaging Service (JMS).

.Net Web services running over HTTP can be called in three different ways: HTTP GET operation, HTTP POST operation, and SOAP. The GET and POST operations are useful if you need to call a Web Service quickly and no SOAP client is readily available. You can use REST to perform GET, POST, PUT, and DELETE operations over the HTTP in a Perl script. In this script, you can specify SQL queries and simple message queues.

For a discussion of SOAP/REST in the .NET (Visual Studio 2008 SP1) ecosystem, see

http://www.pluralsight.com/community/blogs/scottallen/archive/2008/08/11/visual-studio-sp1-and-the-metification-of-rest.aspx

and

http://msdn.microsoft.com/en-us/library/dd203052.aspx

Often, services within an organization’s firewall are REST-based, while 3rd party partners use a mix of SOAP and HTTPS protocols to access their public services. By using REST for internal services, organizations are avoiding some of the overhead that the WS-* standards introduce.

If the SOAP client is available, here's how to make a simple choice between REST and SOAP. If the application is resource-based, choose REST. If the application is activity-based, opt for SOAP. Under REST, a client might request that several operations be performed on a series of resources over the HTTP. For SOAP-based requests, only one invoke operation is needed for each activity-oriented service that a client might request be performed.

REST requests do not depend on WSDL as SOAP requests do. Yet, REST and SOAP can co-exist as requests from a composite Web service application to an external Web service.

When to use REST based web services?

http://oracled.wordpress.com/2009/03/11/when-to-use-rest-based-web-services/

When Web services are outside the control of the organization (as in the figures at the top of this post), you need to ensure that they can interoperate externally with one another with respect to shared semantics and contractual obligations. Semantic misunderstandings and contractual loopholes contribute to interoperability problems between external enterprise Web services. Future posts will focus on these aspects of interoperability.

For presentations that includes the pros and cons of different protocols (SOAP and HTTP) and software frameworks (.NET and J2EE), see

http://www.esri.com/events/devsummit/pdfs/keynote_chappell.pdf

and

http://www.esri.com/events/devsummit/sessions/keynote.html

The oft-heard view that SOA is now “dead”

Once thought to be the savior of IT, SOA instead turned into a great failed experiment -- at least for many organizations. SOA was supposed to reduce costs and increase agility on a massive scale. In many situations, however, SOA has failed to deliver its promised benefits.

Yet, although SOA is understandably purported to be dead by many, the requirement for a service-oriented architecture is stronger than ever.

Adopting SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.

The latest shiny new technology will not make things better. Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make a spectacular commitment to change.

Note: As of 2008, increasing numbers of third-party software companies offer software services for a fee. In the future, SOA systems may consist of such third-party services combined with others created in-house.

More on this can be found in “WOA: Putting the Web Back in Web Services.”

http://blogs.gartner.com/nick_gall/2008/11/19/woa-putting-the-web-back-in-web-services/

Also, here’s a link to one of my earlier articles on SOA

“The Economic, Cultural and Governance Issues of SOA”

http://www.cioupdate.com/reports/article.php/11050_3652091_1/The-Economic-Cultural-and-Governance-Issues-of-SOA.htm

Electronic Health Records (EHR) – Interoperability of Disparate Systems – Technical

As the title suggests, this post, the first in a series of continuations of my June 13 post, is about the technical aspects of interoperability. For your convenience, I’ve copied the figure below from the earlier post.




The word "interoperability" means different things to different people. To DBAs, for example, the ability of SQL Server, Oracle and DB2 to recognize each other’s commands is a sign of the interoperability of these databases. In the current post, however, I'll focus primarily on a distributed computing model that is capable of cross-platform and cross-programming language interoperability, Web services. In the process, I'll compare Web services with a couple of its predecessors, CORBA and DCOM, which are still being used widely.

Why CORBA and DCOM success is limited

Although CORBA and DCOM have been implemented on various platforms, the reality is that any solution built on these protocols will be dependent on a single vendor's implementation. Thus, if one were to develop a DCOM application, all participating nodes in the distributed application would have to be running a flavor of Windows. In the case of CORBA, every node in the application environment would need to run the same ORB product. Now there are cases where CORBA ORBs from different vendors do interoperate. However, that interoperability generally does not extend into higher-level services such as security and transaction management. Furthermore, any vendor specific optimizations would be lost in this situation.

Both these protocols depend on a closely administered environment. The odds of two random computers being able to successfully make DCOM or IIOP calls out of the box are fairly low. In addition, programmers must deal with protocol unique message format rules for data alignment and data types. DCOM and CORBA are both reasonable protocols for server-to-server communications. However, both they have severe weaknesses for client-to-server communications, especially when the client machines are scattered across the Internet.

CORBA overview

Common Object Requesting Broker Architecture (CORBA) provides standards-based infrastructure for interactions between distributed objects. It allows software components running on dissimilar hardware, hosted on different operating systems, and programmed in different programming languages to communicate, collaborate, and perform productive work over a network.

A CORBA system accomplishes this magical task by confining the interaction between objects to well-defined interfaces. To use the service of a distributed object, you must interact with it through the interface. How the interface is implemented -- or even where it is implemented -- is not known and doesn't have to be known by the client. The figure below illustrates the workings of a typical CORBA system.

Object interactions in CORBA




Achieving location transparency

In this figure, the client code makes use of a server object through its interface. In fact, the interface is implemented by a stub object that is local to the client. As far as the client can tell, it's only interacting with the local stub object. Under the hood, the stub object implements the same interface as the remote server object. When the client invokes methods on the interface, the stub object forwards the call to a CORBA component called the Object Request Broker (ORB). The calling code in the client does not have to know that the call is actually going through a stub.

DCOM overview

Distributed Component Object Model (DCOM) is a Microsoft proprietary technology for software components distributed across several networked computers to communicate with each other. However, it has been deprecated in favor of the Microsoft .NET Framework, which includes support for Web services.

Internet poses problems for CORBA and DCOM

DCOM was a major competitor to CORBA. Proponents of both of these technologies saw them as one day becoming the model for code and service-reuse over the Internet. However, the difficulties involved in getting either of these technologies to work over Internet firewalls, and on unknown and insecure machines, meant that normal HTTP requests in combination with web browsers won out over both of them.

Web services overview

Web services specifications such as SOAP, WSDL, and the WS-* family are currently the leading distributed computing standards for interfacing, interoperability, and quality of service policies. Web services are often called "CORBA for the Web" because of their many derivative concepts and ideas.

There are several ways to think about Web services when building applications. At the most basic level it is an advanced communications protocol family allowing applications to talk to each other. This level has progressed quite significantly over the past few years with many tools (e.g., Oracle’s JDeveloper and Microsoft's Visual Studio) that allow software developers to write interacting Web services and build complex applications. This level is often characterized by direct one-on-one interactions between services or relatively few services interacting with each other.

SOA overview

However, just using Web services as a communications protocol belies its true power, that of the service-oriented architecture (SOA). The SOA describes an entire system of services dynamically looking around for each other, getting together to perform some application, and recombining in many ways. This model encourages the reuse of technology and software that evolves the way applications are designed, developed and put to use. It brings the world of distributed computing to a closer reality. At this level software developers need to think of the SOA model and design their distributed application across the model. This level is characterized by the use of technologies to allow distributed communications of services such as the use of an Enterprise Service Bus (ESB), which is a common distribution network for services to work with. More on ESB in an upcoming post.

Finally, the highest level is to look at this SOA model and the many component services as building blocks that can be assembled in whole sections into full applications instead of the traditional method of writing line after line of code. By examining the connecting interfaces, we can build whole applications without ever really writing code. For that matter direct code may even get in the way since the services may be written in numerous different languages and platforms. The blocks can be put together into a workflow of operations that define how the application performs, and other tools can be used to monitor the effectives of the workflow at each service or group of services. At this level, developers can put away the use of regular programming languages and work in a Model-Driven Architecture that helps them to build applications more accurately to a design. More on workflow in an upcoming post.