A diagram that shows how SOFEA applications fit into a SOA environment

1. Capture Perform Perform Convey
Business Process
Loan Credit Decisioning Application
(maps to Workflow)
Application Check Status (Self­service)
Automated Manual
Customer
SOAP service Customer
Loan Officer
SOFEA Client Bank Home Page
SOFEA Bank Home Page
Client Credit rating
Screen
Screen service
Edit flow
flow Application Screen
Application Received, check application Application
List (Inbox) flow
Form back later, SOFEA Status
reference=1234
SOFEA Controller
Client
SOAP:
submitApplication CreditRatingResponse Process Choreography SOFEA Controller
getCreditRating SOFEA Controller
(ApplicationRequest) (CreditRatingRequest) (loose interplay)
ApplicationResponse Clearcut? No
GET 200 OK
status=”borderline” GET
Process Orchestration
Yes PUT
(tight coordination)
(status=”accepted”
WS­BPEL process or
exposed as a SOAP PUT 200 OK status=”rejected”) GET
PUT
service to the client 200 OK + (status=”borderline”) + List 200 OK +
(status=”accepted”
http://.../applications/1234 or 200 OK + Application
200 OK
POST status=”rejected”) 200 OK Application details
details
http://.../applications/1234 http://.../applications http://.../applications/1234 http://.../applications/1234 http://.../applications/1234
http:/.../applications http://.../applications/1234
UPDATE apps
REST SET
services status='accepted' |
'rejected'
WHERE id='1234' UPDATE apps SET SELECT FROM apps
SELECT FROM apps
status='borderline' WHERE WHERE id='1234' SELECT FROM apps
WHERE id='1234' status='borderline'
The SOFEA Model UPDATE apps
SET status='accepted' | 'rejected'
WHERE id='1234'
INSERT INTO apps
Workflow, Screen flow, Process VALUES WHERE id='1234'
('1234',..., 'pending')
Orchestration and Process This is a minimal example to illustrate concepts. A real­life
application will be more robustly engineered. E.g., The design will
Choreography prevent customers from approving their own applications.
Copyright © 2008 Ganesh Prasad.Verbatim copying and distribution are allowed, provided this notice is retained.

2. 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.
Copyright © 2008 Ganesh Prasad.Verbatim copying and distribution are allowed, provided this notice is retained.