The anatomy of business logic
During TechEd Europe 2004 there will be plenty of guidance by eminent people like Pat Helland, Don Box, Arvindra Sehmi, Clemens Vasters and many others on service orientation and supporting infrastructure that is (coming) out (WSE, Shadowfax, FABRIQ, Indigo).
The majority of this guidance is likely to focus on the technical side of SO: how to glue together heterogeneous software into larger solutions using standard messaging protocols and standard metadata formats for service interfaces (WSDL) and policies (WS-Policy).
In a three-tier application (presentation, business logic and data access) the responsibilities of the presentation and data access layers are clear. The presentation layer bridges the gap between humans and the software that is supposed to help them to their job. The data access layer ensures we can store and retrieve data from arbitrary data stores, hiding implementation details such as query language and stored procedure usage. But what does the business logic layer do? And how should we partition this layer into separate components?
The software development and design guidance I have encountered in this area has not been very satisfactory so far. Over the past four years my belief has grown that in general the understanding of the business logic layer - the very heart of our business applications - is pretty poor within software development land. However, during the same period I have been inspired by a number of people who promote a "business process oriented" approach to software development.
Typically business process logic tries to obtain information from multiple sources (users and systems inside and outside of the organisation) with the final objective to commit a business transaction. An order process for example obtains customer details and confirmation that the financial status of the client is acceptable. Only when all the required information has been gathered the order will be accepted and actually exist in the eyes of the selling organisation. Up until the acceptance of the order, any collected data is work-in-progress data which has no real meaning to the selling organisation except to those directly involved in the process of evaluating the order. Once the work-in-progress data is deemed complete, the last action of the business process logic is to mark this information as a fact for the whole organisation: the final business transaction turns work-in-progress data into business information.
While the work-in-progress data is not complete the business process logic determines who is to provide which information at any given point in time. If the information is to obtained from a person the process logic may prompt the relevant person(s) to provide the required input (ideally using some form of human notification service that abstracts the process logic from presentation channel issues), but in the end it will have to wait possibly a long time for it to be served. If the required information can be provided by software the process logic can invoke the relevant systems, but still may have to wait a long time.
Because business process logic may have to run and maintain work-in-progress data (business process state) state for a long time, it makes sense to implement this logic in a stateless fashion and store this data in a central database. Because the semantics of business process state differs from the semantics of data that is managed by the data-centric business logic, it makes sense as well to keep the two types of data separate. Mixing the two is likely to cause trouble sooner or later, as you mix data that makes sense to the whole organisation (long-lasting facts that are managed by data-centric business logic) with data that only makes sense to the participants in a particular business process instance (temporary work-in-progress data managed by process-centric business logic).
For the decomposition of process-centric business logic into business process services (process-centric) I have trouble finding rules of similar clarity in current software development literature and methodologies. My main inspiration in this area currently comes from work done at the University of Delft by Jan Dietz c.s. on modeling the structure of and business processes in organisations from a communication perspective. Though the presentation of Dietz' methodology (DEMO - Dynamic Essential Modeling of Organisations)- still is rather academic, it defines very clearly a number of concepts and patterns that help understand and decompose business processes. As such it provides a good starting point for designing business processes services that must support/implement these business processes.
The majority of this guidance is likely to focus on the technical side of SO: how to glue together heterogeneous software into larger solutions using standard messaging protocols and standard metadata formats for service interfaces (WSDL) and policies (WS-Policy).
What happens in the business logic layer?
Guidance on the business side of SO tends to be lacking. People tend to agree that services should offer a coarse-grained interface to business logic, but that's about as good as it gets. What does coarse-grained mean? How are we to discover these coarse-grained chunks of logic during the analysis and design phase of a development project? These questions resemble the ones that come up when defining the architecture for a layered component-based application.In a three-tier application (presentation, business logic and data access) the responsibilities of the presentation and data access layers are clear. The presentation layer bridges the gap between humans and the software that is supposed to help them to their job. The data access layer ensures we can store and retrieve data from arbitrary data stores, hiding implementation details such as query language and stored procedure usage. But what does the business logic layer do? And how should we partition this layer into separate components?
The software development and design guidance I have encountered in this area has not been very satisfactory so far. Over the past four years my belief has grown that in general the understanding of the business logic layer - the very heart of our business applications - is pretty poor within software development land. However, during the same period I have been inspired by a number of people who promote a "business process oriented" approach to software development.
Separating data- and process-centric business logic
In a business process oriented approach business logic is separated into process-centric logic and data-centric logic. The data-centric logic ensures that data can be stored, retrieved and transformed without violating its meaning (semantics). The process-oriented logic coordinates who (both persons and software) can perform which activities when.Typically business process logic tries to obtain information from multiple sources (users and systems inside and outside of the organisation) with the final objective to commit a business transaction. An order process for example obtains customer details and confirmation that the financial status of the client is acceptable. Only when all the required information has been gathered the order will be accepted and actually exist in the eyes of the selling organisation. Up until the acceptance of the order, any collected data is work-in-progress data which has no real meaning to the selling organisation except to those directly involved in the process of evaluating the order. Once the work-in-progress data is deemed complete, the last action of the business process logic is to mark this information as a fact for the whole organisation: the final business transaction turns work-in-progress data into business information.
While the work-in-progress data is not complete the business process logic determines who is to provide which information at any given point in time. If the information is to obtained from a person the process logic may prompt the relevant person(s) to provide the required input (ideally using some form of human notification service that abstracts the process logic from presentation channel issues), but in the end it will have to wait possibly a long time for it to be served. If the required information can be provided by software the process logic can invoke the relevant systems, but still may have to wait a long time.
Because business process logic may have to run and maintain work-in-progress data (business process state) state for a long time, it makes sense to implement this logic in a stateless fashion and store this data in a central database. Because the semantics of business process state differs from the semantics of data that is managed by the data-centric business logic, it makes sense as well to keep the two types of data separate. Mixing the two is likely to cause trouble sooner or later, as you mix data that makes sense to the whole organisation (long-lasting facts that are managed by data-centric business logic) with data that only makes sense to the participants in a particular business process instance (temporary work-in-progress data managed by process-centric business logic).
Identifying data- and process-centic business services
In a service-oriented world (as well as in a component-based world) we have to partition data- and process-centric business logic into business process and business information services with minimal mutual dependencies. Of course this raises once more the question of which partitioning rules to use. For business information services (data-centric) it is possible to use a high-level business object or entity model and apply clustering rules such as described by John Cheesman and John Daniels in their book UML Components (recommended reading, a thin book with challenging, to the point guidance on designing component-based software).For the decomposition of process-centric business logic into business process services (process-centric) I have trouble finding rules of similar clarity in current software development literature and methodologies. My main inspiration in this area currently comes from work done at the University of Delft by Jan Dietz c.s. on modeling the structure of and business processes in organisations from a communication perspective. Though the presentation of Dietz' methodology (DEMO - Dynamic Essential Modeling of Organisations)- still is rather academic, it defines very clearly a number of concepts and patterns that help understand and decompose business processes. As such it provides a good starting point for designing business processes services that must support/implement these business processes.
0 Comments:
Post a Comment
<< Home