Ce diaporama a bien été signalé.
14 nov. 2012
A diagram that shows how SOFEA applications fit into a SOA environment
Capture Perform Perform Convey Business Process Loan Credit Decisioning Application (maps to Workflow) Application Check Status (Selfservice) 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”WSBPEL process orexposed as a SOAP PUT 200 OK status=”rejected”) GET PUTservice 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 reallife 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.
This diagram illustrates the SOFEA approach to UI design. The basic concept is that of the Business Process. We need to proceed topdown 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 WSBPEL. (WSBPEL 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 wellscripted 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 users frontend application. The frontend 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 ServiceOriented FrontEnd Architecture (SOFEA). This diagram shows a simplified version of a wellunderstood loan processing scenario. A customer applies for a loan at a banks 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 clearcut decision to approve or reject the loan. If the result is clearcut, the applications 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. Thats their screen flow. Again asynchronously, customers check back at the banks 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 predetermined, 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 (ServiceOriented Architecture) based ecosystem. Bank customers may use a browserbased 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 serverside. 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 WSBPEL 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.