Copyright © 2008 Ganesh Prasad.Verbatim copying and distribution are allowed, provided this notice is retained.

The SOFEA ModelWorkflow, Screen flow, Process 

Orchestration and Process Choreography

CaptureLoan

Application

PerformCreditCheck

ConveyApplication

Status (Self­service)

Received, check back later,

reference=1234

ApplicationForm

Bank Home Page

Manual

Screen flow

POST

200 OK +http://.../applications/1234

INSERT INTO appsVALUES

('1234',..., 'pending')

getCreditRating(CreditRatingRequest)

CreditRatingResponse

UPDATE appsSET 

status='accepted' | 'rejected'

WHERE id='1234' UPDATE apps SETstatus='borderline' WHERE id='1234'

ApplicationList (Inbox)

Editapplication

Screen flow

GETstatus=”borderline”

200 OK+ List

ApplicationStatus

Bank Home Page

Screen flow

PUT(status=”accepted”

orstatus=”rejected”)

PUT(status=”borderline”)

SOAP service

GET

200 OK + Application

details

GET200 OK + 

Applicationdetails

http:/.../applications http://.../applications/1234

200 OK200 OK

http://.../applications/1234

Clearcut?

Yes

NoApplicationResponse

SOAP:submitApplication

(ApplicationRequest)

http://.../applications http://.../applications/1234 http://.../applications/1234http://.../applications/1234

200 OK

PUT(status=”accepted”

orstatus=”rejected”)

SELECT FROM apps WHERE

status='borderline'

SELECT FROM apps WHERE id='1234'

UPDATE appsSET status='accepted' | 'rejected'

WHERE id='1234'

SELECT FROM apps WHERE id='1234'

CustomerCustomer

Loan Officer

Process Orchestration(tight coordination)

REST services

Business Process(maps to Workflow)

Automated

PerformDecisioning

SOFEA Controller

SOFEA ControllerSOFEA Controller

Process Choreography(loose interplay)

This  is  a  minimal  example  to  illustrate  concepts.  A  real­life application will  be more  robustly  engineered. E.g., The design will prevent customers from approving their own applications.

WS­BPEL process exposed as a SOAP service to the client

Credit rating service

SOFEA Client

SOFEA Client

SOFEA Client

Copyright © 2008 Ganesh Prasad.Verbatim copying and distribution are allowed, provided this notice is retained.

This diagram illustrates the SOFEA approach to UI design. 

The basic concept is that of the Business Process. We need to proceed top­down from this level. The Business Process does not map to anything visual, so it may be rather abstract to web designers who are used to designing applications by working through screen flows. 

Some steps of the business process can be managed in an automated fashion. This is called Process Orchestration and is typically implemented using WS­BPEL. (WS­BPEL can orchestrate both SOAP and REST services provided the REST services expose WSDL interfaces. REST services can be described by WSDL 2.0, but not by earlier versions.) 

Workflow is different from either screen flow or process orchestration. Workflow generally covers the whole logical business process. Along the way, both human interaction and machine interaction can occur. Parts of the workflow may be automatically orchestrated. Other parts may be choreographed, as when different actors play autonomous, yet well­scripted parts. Choreography is a looser interaction than Orchestration. The logic is spread over several nodes rather than controlled at one node.

Screen flow is local to each user's front­end application. The front­end apps seen by users (each with their individual screen flows) are like flies sitting on a huge process buffalo. They are not the main act at all, though they may seem to be from a purely visual perspective. 

In the SOFEA view of the world, the business process is supreme. The service steps are part of the business process and are a level below in importance. The UI is the last layer in this ecosystem by way of importance, although it is layered right on top. It provides visual coherence to a human user and participates in the overall business process by interacting with services (including the composite services represented by orchestrated processes). Hence the name Service­Oriented Front­End Architecture (SOFEA). 

This diagram shows a simplified version of a well­understood loan processing scenario. A customer applies for a loan at a bank's website. The application is lodged and the customer is given a reference number to check back later. The screen flow is thus quite simple. Process orchestration begins by kicking off an automated credit check. The credit rating that comes back may not result in a clear­cut decision to approve or reject the loan. If the result is clear­cut, the application's status can be automatically set, otherwise it must wait for a manual decision. 

Entirely asynchronously, loan officers periodically check a backlog of pending applications that could not be automatically decisioned. They see a list of such applications, select individual applications from the list and either approve or reject them. Then they go back to viewing the list to select other applications. That's their screen flow. 

Again asynchronously, customers check back at the bank's website using the reference number they have been given. Once the decision has been made (either automatically or manually), they can see the result. The screen flow is again very simple. 

The interaction between customers and loan officers is not orchestrated  by a centralised entity but loosely choreographed. Their roles mesh in ways that are not pre­determined, yet yield meaningful outcomes.

We have in effect one business process or workflow, one orchestrated process exposed in turn as a SOAP service,  three choreographed interactions, a number of SOAP and REST services and two SOFEA apps. That is how SOFEA clients fit into a SOA (Service­Oriented Architecture) based ecosystem. Bank customers may use a browser­based SOFEA app that manages two different screen flows (application lodgement and status checking). Loan officers may use either a rich client or a thin client managing a single screen flow. SOFEA is agnostic to the actual technology used, and can speak to both REST and SOAP services. Although not obvious in this example, Data Interchange should be in XML to ensure data integrity and seamless integration between the Presentation and Business Logic tiers.

This is a simplified illustration. There are gaping security loopholes here. For example, there is nothing that prevents customers from approving their own applications. In a real application, additional safeguards would be built into the design to prevent such obvious issues.

In terms of client/server partitioning, only the screen flow and controller live on the client. Business logic is entirely server­side. The Controller manages the Data Interchange between the client and the various services and also manages Presentation Flow (screen flow). The REST services that manage the application resources live on one server. The SOAP service that provides the credit rating lives on another server. The BPEL process that manages  the initial process orchestration  lives on a third server and exposes a SOAP interface of  its own. Three different server models have been shown to represent the REST services, SOAP service and WS­BPEL process. The third aspect of SOFEA (Application Download) is not shown in this diagram.