New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Introducing Business Entities and the Business Entity Definition Language
Posted by Boris Lublinsky on Apr 28, 2010
In a new article, Data4BPM, IBM’s Prabir Nandi, Dieter König, Simon Moser, Richard Hull, Vlad Klicnik, Shane Claussen, Matthias Kloppmann and John Vergo introduce the concept of business entities as a means of representing the business view of data. They propose two new standards, the Business Entity Definition Language (BEDL) and BPEL4Data for the holistic design and execution of process with Business Entities.
According to the authors:
In most business process management tool suites, data is treated mostly as an afterthought. Activities and their flows are the main abstractions and the data manipulated by the processes is essentially hidden in process variables. The presentation and aggregation of data is handled outside of the process definition, and implemented through generic service calls. This process-only approach ignores the important data perspective during business operation analysis, often obscures key aspects of the operations, and can lead to costly re-factoring throughout the solution lifecycle.
In their article they promote making data entities first class citizens of the process design and introduce Business Entities as:
... key business-relevant dynamic conceptual objects that are created, evolved, and (typically) archived as they pass through the operations of an enterprise. A Business Entity includes both an information model for data about the business objects during their lifetime, and a lifecycle model, which describes the possible ways and timings that tasks can be invoked and performed on these objects.
The article proposes a Business Entity Definition Language (BEDL) which defines the BEDL meta-model and syntax, discussing possible runtime architecture to support BEDL specifications. It also presents an overview of BPEL4Data - an approach for extending the BPEL standard to support explicit interoperation with BEDL components.
The proposed BEDL is based on the notion of Business Entity (BE) that has four main components: information model, lifecycle model, access policies and notifications. The information model of BE types is specified as a family of attribute/value pairs, where an XML schema is associated with each attribute that governs the structure of the corresponding values. Not all attributes have to be present in BE all the time. The lifecycle model for BE is specified as a finite state machine. The lifecycle specification itself does not provide detail on the activities that might be performed while a given BE instance is in a given state, nor the activities that might be performed as part of transitioning a BE instance from one state to another. They are typically expressed using BPEL which is used to supplement BE definition. BE access policies are focusing on two main: CRUD defining policies for modification of BE’s information model (or parts of this model), and Executions, defining policies for lifecycle model transitions. The last part of a BE specifications are notifications which define BE activities (changes) that might be of interest to external parties, for example, other processes.
A software component supporting BEDL provides an interface that enables external components to invoke the following capabilities:
- Requesting BE types metadata- a query interface allowing to obtain the schemas of the BE types that it is supporting.
- Accessing a Business Entity instance’s data - a CRUD interface allowing to manipulate BE’s attributes. This interface is a subject to CRUD permissions.
- Querying on BE instances - a query interface allowing to get the references to all BE instances that satisfy a query.
- Executing state transitions of a BE - a control interface instructing BE to move to a different state. This interface also includes the creation of BE instances. State transition is subject to the BE lifecycle and Execution permissions.
- Locking/unlocking (parts of) a BE instance - an interface supporting concurrency control for BE instances.
- Subscribing to data or state changes of a class of BE instances - an interface enabling to subscribe to notifications about BE’s data and state changes. This interface is subject to CRUD permissions, while an attempt is made to read BE’s changes.
The article also provides an example,of designing of a Courier Shipment BE type.
Article authors envision a specialized BE runtime, responsible for managing instances associated with multiple BE types. They discuss two flavors of such runtime:
- In the "green field" case BE runtime manages the actual BE instance data (including both attribute values and instance state) in a specialized data store - BE content store. The BE runtime, in this case, is responsible for enforcing data access policies and and sending notifications to BE subscribers.
- In the "brown field" case, it is assumed that most of the BE data is already being stored by legacy applications. In this case, instead of replicating the data, the BE runtime can be augmented with a persistent store that holds data that can be used to link or connect the BE information view of data with the legacy application view of the data.
Although BE runtime has provisions for manipulating BE data and state it does not provide any support for defining execution of state transition.It instead relies on external process, for example,BPEL/BPMN -based process, a two-tiered Web application, an off-the-shelf packaged application or a Master Data Management (MDM) maintenance workflow or a XPDL-based application.
The article outlines the following advantages of using BEs:
- Customer satisfaction
- The BE approach complements the traditional top-down, process-centric way of decomposing business operation domains... for business processes with a large end-to-end scope, starting the design activity with a few key Business Entities provides an insight and clarity very early that is rarely achieved with the complexity of a multi-level process decomposition...
- The BE approach enables substantially improved communication across different silos of an enterprise, because in many cases a BE type spans multiple silos, and provides a common vocabulary for the stakeholders of those different silos.
Simplicity, flexibility and time to value - Using the BE approach, one can capture the key entities, their states and tasks that change states rather quickly even for a large complicated system...
- The approach forces a simple (but complete) start and then a spiral evolution of the design as all requirements are modeled incrementally but always stay consistent and coherent.
- Business Entity lifecycle states represent process milestones and a reflection of business objectives.
- As more requirements are modeled up-front, there is less re-factorization and ripple downstream. This results in fewer change requests late in the solution development lifecycle, and in the deployment and maintenance lifecycle.
- Processes are factored around the entity life cycles. This increases the scope for reuse of the process definitions. It also leads to agility in design, as changes can be localized in process fragments without affecting other parts of design.
Cost reduction
Data modeling is definitely an important part of process definition, but typically it is used on the enterprise semantic data model level. Whether extending its notion to BE, as defined in the article, will really makes process design and implementation better still remains to be seen.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
Hmmmm I like the idea...
by
Mark Levison
Posted
Domain Driven Design
by
Greg Matthews
Posted
OutSystems BPM relies on data
by
Gonçalo Borrêga
Posted
Re: OutSystems BPM relies on data
by
peter lin
Posted
Re-inventing the wheel
by
George Ludgate
Posted
I like it
by
Peter Rajsky
Posted
Process Data Models - not's your father's data models
by
John Reynolds
Posted
-
...but shouldn't be a rule that you can design something like this after you've find three versions in the wild (i.e. same as Design Patterns). It sounds a lot like they had a good idea and wrote a language to describe it.
Sadly being IBM they will probably spawn an industry.
Cheers
Mark Levison
Agile Pain Relief Consulting -
Is this just Domain Driven Design?
-
Hi,
Last year at OutSystems we've implemented a great BPM engine and modeling framework on top of the Model driven framework we already have. We immediately noticed that the most pragmatic approach was to make data relevant, mainly because you cannot just decouple the implementation of a business process from the data it handles.
As such, a process is just in the same abstraction level of an entity, a User interface or a service that we expose to external applications. By doing this we found a huge increase in terms of implementation productivity (because you just stop relying on meaningful data dictionairies that we keep on requiring) but also in terms of process visibility, where we can discuss the data model together with the business entity model. The layer of business entities is something that the business is able to understand. So we reach an abstraction layer that is both able to be transformed to a real implementation as well as seen on a conceptual/analysis/process level.
If they get this to be a formal language the semantics of the whole process will be much enriched and, as we've noticed in our own experience, implementation can easily be derived from it.
BTW, you can download one free version of OutSystems' Agile Platform, which allows you to experiment how BPM processes aware of Business Entities can really improve you implementation capabilities as well as process expression.
Cheers,
Gonçalo Borrêga
Delivery Manager at OutSystems -
From a business rule perspective (aka BRMS), that's been done for over a decade now. It's just that BPM is finally maturing and catching up.
-
I agree with Mark Levinson. If you read the paper you will see that they propose to move the work of the business layer into the process layer and leave the business layer to be an intelligent database with a CRUD-like interface. No-one these days should be doing JUST a process analysis in the same way that today no-one does JUST a data model then starts coding. Process analysis MUST be done hand in hand with a traditional OO analysis (giving both state and behavior models). The move to SOA is then trivial with apps calling operations on services and BPEL doing its thing (which you could code by hand if you wanted to). Their approach will not speed up service delivery nor improve maintenance nor any other qaulity I see. I think they are off down a dark alley.
George -
I think it is useful idea to formalize BE lifecycle model during process design, but more focus shall be on design-time "services" in BEDL (e.g. to connect BE lifecycle model and process view and validate consistency of these views).
-
We've been giving this a great deal of thought lately..
thoughtfulprogrammer.blogspot.com/2009/11/tips-...
7 comments
Watch Thread Reply