SOFEA screen flow, services, processes and workflow

[prasadgc]

Hi all,

I've just completed an admittedly cluttered diagram after a quick
discussion with Peter Svensson:

http://groups.google.com/group/sofea/web/Workflow-Screenflow%20v0_1.pdf

Hopefully, this will illustrate the SOFEA approach to UI design. The
basic concept is the business process. 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. WSDL 2.0 can describe REST services but not
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.

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 this view of the world, the business process is supreme. The
services are derived from 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 only
visual coherence but consumes services and processes (composite
services). Hence the name Service-Oriented Front-End Architecture
(SOFEA).

I hope this diagram makes things a bit clearer. It's based on a well-
understood loan application scenario. A bank customer applies for a
loan at the bank's website. The application is lodged and the customer
is given a reference number to check back later. The screen flow is
fairly simple. An automated credit check is kicked off. The credit
rating that comes back may not result in a clearcut decision to
approve or reject the loan. If the result is clearcut, the
application's status can be automatically set, otherwise it has to
wait for a manual decision.

Entirely asynchronously, loan officers may 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 will know). The screen
flow is again very simple.

So we have in effect two SOFEA apps. The customers may use a browser-
based SOFEA app that manages two different screen flows (application
lodgement and checking). The loan officer may use either a rich client
or a thin client. SOFEA is agnostic to the technology.

Regards,
Ganesh

[prasadgc]

A newer version:

http://groups.google.com/group/sofea/web/Workflow-Screenflow%20v0_2.pdf

Regards,
Ganesh

[Justin Meyer]

Looks very good.

Though I think I might be misunderstanding your diagram, but wouldn't you not want the client submitting the approval post requests?  Users could approve their own requests.

It seems like you would want it to create the first request to create the application, but the server should be connecting to all the services, not the client.  This might not be how you've drawn it up, but it wasn't exactly clear.  It might be worth while to divide the page between what is on the client and what is on the server.

Good work,

Justin

--
Justin Meyer

Jupiter IT Solutions
847-924-6039
justin...@gmail.com
AOL: jusbarmey

[prasadgc]

Justin,

On your first question, I haven't shown the authentication and
authorisation aspects of the solution. Some checks should definitely
exist to ensure that customers don't approve their own applications!

On the second question, only the screen flow and controller live on
the client. Everything else lives on various servers. The model of
SOFEA is that the client directly consumes services without going
through a web server. The Controller manages the Data Interchange
between the client and the various services as well as the
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. Perhaps I should add another
server icon in there to make that explicit.

Regards,
Ganesh

> justinbme...@gmail.com
> AOL: jusbarmey

[Justin Meyer]

Appologies in advance if my reply is terse. I am on my phone. You work
is great!

Even authenticated and authorizatized, a user should not be able to
make the put approved request from the client.

I was pretty sure you intended those requests were coming from the
client. I was confused because I am not sure they should.

To make the client server distinction very clear you might bisect the
diagram in 2 with a faint line.

Sent from my iPhone

[prasadgc]

Thanks for the great feedback, Justin. I've incorporated it into the
next version of the diagram:

http://sofea.googlegroups.com/web/SOFEA+in+a+SOA+Ecosystem+v0_3.pdf

I hope this addresses most concerns. I agree this is a simplistic
example that tries to illustrate a number of concepts, so some
elements of practicality (e.g., security) have had to be sacrificed.
I've mentioned that in the document so people don't reject the whole
SOFEA concept just because this particular example isn't complete
enough.

Regards,
Ganesh

On Oct 2, 1:05 pm, Justin Meyer <justinbme...@gmail.com> wrote:
> Appologies in advance if my reply is terse. I am on my phone. You work  
> is great!
>
> Even authenticated and authorizatized, a user should not be able to  
> make the put approved request from the client.
>
> I was pretty sure you intended those requests were coming from the  
> client. I was confused because I am not sure they should.
>
> To make the client server distinction very clear you might bisect the  
> diagram in 2 with a faint line.
>
> Sent from my iPhone
>

[prasadgc]

Aaaarrgh! There's always one more bug! Forgot to show that the "Bank
Home Page" and "Home Page" are the same :-(.

Here it is:

http://groups.google.com/group/sofea/web/SOFEA%20in%20a%20SOA%20Ecosystem%20v0_4.pdf

Regards,
Ganesh