Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Sofea in a soa ecosystem v0 4

1.750 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Sofea in a soa ecosystem v0 4

  1. 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  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  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. 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 users 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 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 clear­cut decision to approve or reject the loan. If the result is clear­cut, 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 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.