26 April 07 - 15:01SOA and Service Identification
Tags: business_process, component, enterprise_architecture, service_oriented_architecture, soa
Systems developed using the principles of a Service-Oriented Architecture can deliver an organization a decent improvement in flexibility, or if you like, agility. This increase of flexibility is obtained by reusing so-called services. By separating the implementation of orchestration and services, the resulting system can easily be changed by orchestrating the services in another way or by just using other services in a certain orchestration. In an ideal situation the services don't need to change. The question is now: how can we identify these services in such a way that we get the flexibility we need without losing performance or introducing a new governance problem?
read more
- Enterprise architecture -
-
§ ¶
11 April 07 - 12:39SOA and Human Interaction
Tags: bpm, business_process, human_interaction, orchestration, service_oriented_architecture, soa, standard, web_service
Automated business processes are an integral part of a SOA. In practice many of these processes require user interaction. The interaction scenario's can be very simple, like manual approval. However, more complicated scenario's like entering data, assignment of tasks to other users and managing long-running processes can appear. An example of a process involving human interaction is given in [1]:
"Imagine a bank's personal loan process. This process is made available on the internet site of the bank using a web interface. Customers can use this interface to enter the data for their loan approval request and to start the approval process. The process performs some checks, and eventually informs the customer whether his or her personal loan request has been approved or rejected. Processing is often automatic and does not require any human involvement. However, there are cases that require bank staff to be involved. An example of such a case is if the online check of a customer's creditworthiness returns an ambiguous result. In this case, instead of declining the request automatically, a bank clerk could check the request and determine whether to approve or decline it. Another example would be if a request exceeds the amount of money that can be approved automatically. In this case, a manual approval step is required, in which a member of the "approvers" group either approves or declines the request."
Nowadays most of this kind of automated processes is based on web services. But how can the given example process be orchestrated using web services? The de facto standard for web services orchestration seems to be BPEL [2]. This standard, however, doesn't specifically cover user interactions. This leaves us with the question: what is the right way to include human interaction in a BPEL process?
read more
- Enterprise architecture -
-
§ ¶
