Title Image

Don Xml's Grok This

The home of Don Demsak
Welcome to Don Xml's Grok This Sign in | Help
in Search

This Blog

Syndication

Site Sponsors

DonXml's All Things Techie

Migrating from Table Models to Domain Models via OCL

I’ve been dwelling on this idea of trying to use some variation of the Object Constraint Language within .Net, and I think I’m finally at the point where I can try to discuss it in a coherent manner.  OCL is used to describe the constraints on objects within UML, but I’d like to enhance it be used in more than UML.

One of the things I seem to find myself doing time and time again, when building multi-tier applications, is using the Data Mapper Pattern (see Martin Fowler’s PoEAA book) to map my data (retrieved from some data source using a Data Access Layer) to my Domain Model (the Line of Business Layer), but that requires quite a bit of code.  .Net does not have a tool to help in situations where the business logic is complex enough to warrant a Domain Model approach.  Instead it uses the Table Model, via Strongly Typed Datasets.  With Strongly Typed Datasets you can take an XML Schema and transform the data structure into classes.  But this approach does not work well for more complex systems, since the generated classes contain only the behaviors required to maintain the data structure.  There is no way to add business rules (aka constraints or behaviors) to the generated classes.

So, I got to thinking that the thing which was missing in the Strongly Typed Dataset approach was the business rules, and that most of the business rules can be defined using OCL.  There seems to also be a similar problem in XML Schema, where in that language they would also like to add something more than just the structure of the data.  Daniel Cazzulino has done a bunch of stuff with Schematron for .Net, and seems to be another (partial) solution to the problem.  If we can create another namespace (let’s call it eXtensible Constraint Language for now), for use within XML-Schema, then we could add the extra business rules to the schema, and be able to create a version of Strongly Typed Datasets, but one that includes these business rules.  Then as a developer, I would have the choice of using either the Table Model, or when things are a bit more complex, the Domain Model, and have tools to make coding for either model easier.

The one final thing that I see is missing is when a constraint is not met.  Currently, when validating an XML document to a Schema you will generate schema exceptions.  But in the case of constraints, I’d like to be able to do one better, and bind each constraint to exception.  But I don’t want just a list of canned exceptions, but to be able to create my own.  So we would need another language (lets call it eXentsible Exception Language) that can be used to describe the Exceptions, and the hierarchies.  Then you can bind a XCL to a XEL, and when you generate the enhanced Strongly Typed Dataset, you will get the constraints and the exceptions.  The bonus is that you can also translate the Schemas embedded with XCL and XEL to some very good system documentation, and/or generate the Schemas from UML.

Does anyone know if someone is working on something like this?  Is this something other developers are interested in, or is it just something that intrigues me?

DonXML Demsak

Published Thursday, January 15, 2004 12:39 PM by donxml
Filed under: ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

TrackBack said:

January 15, 2004 12:41 PM

Udi Dahan - The Software Simplist said:

The idea is sound, however, business rules cannot be defined in schema. Rules such as "only a bank manager can authorize a loan above X" are context dependant. For this reason, I try to make the following separation:

Validation within the class, Business Rules as a service. Validation meaning things like string length, number range/accuracy, etc. Business Rules covers everything else that has to do with the problem domain like "an order can belong to 2 customers if they are married" or other such stuff.

I think it will be a long, LONG time before technology alone ( with the help of various three letter acronyms - TLA's ) will be able to tackle these real-world issues.
January 15, 2004 2:52 PM

Maxim V. Karpov said:

I do not think Dataset object is good for what you express here. It was orginally designed to support Data Transfer Object Pattern; therefore, It is not truly Business Entity rather representation of Data Strcucture in Table manner.
Some of the business rules can be express through Attribute programming. Business Objects are still business objects.

Good post, Maxim

www.ipattern.com do you?
January 15, 2004 7:14 PM

Simon Smith said:

You look to be heading towards the 'translationist' camp, whereby UML models are translated directly into executables. This comes out of the Shlaer-Mellor methodology - worth a look at if you're heading that way.
Personally, I don't see OCL as being capable of expressing business rules in the detail required to make complete translation to a dataset-type object.
January 16, 2004 3:22 AM

TrackBack said:

January 19, 2004 8:25 AM

Daniel Cazzulino said:

I believe an XPath-based language such as Schematron is good enough to express almost every business rule.
Udi Dahan example, "only a bank manager can authorize a loan above X", could be expressed as follows:
<assert test="sec:principal-role('BankManager') and po:Loan/@Amount < 1000">
Only a BankManager can place a loan of more than $1000.
</assert>

Note that XPath extensibility allows for more domain-specific extensions to be active, which can even check against databases, etc. For example, something like this:

<assert test="crm:customer-id(po:CustomerId)" />

in this case, the application would map the "crm" prefix to the business objects that contain the logic, and register the "customer-id" extension function to ensure the Id is a valid one. This way, you can change business rules based on a (well documented) set of extensions, and you can let managers handle them, instead of programmers.
These schemas are easy enough for an advanced user to edit.
In Schematron.NET, I'm implementing quite a few extensions, including XSLT-specific ones, and adding the full EXSLT implemented by Dare Obasanjo. It's not impossible to think about a set of domain-specific standard specs (like EXSLT itself) that would aid in business rules expression.

January 19, 2004 8:25 AM

TrackBack said:

January 19, 2004 8:27 AM

TrackBack said:

Xpath business rules rule
January 21, 2004 6:25 AM

Steven Livingstone said:

The whole Schema to Exception mapping was something I looked at in my last project. I decided you could also used the Xml Schema annotation element and annotate each element with a mapping to each exception (using appinfo) and some marked up content.

When a Xml Schema exception is raised, at the moment you could just query for the equivalent exception in your mapped world. Ideally this would be build into the framework and so when you ask for the "Message" in the Schema Exception, you get a lot more than in currently available.

I'll hunt around and see if i can find what I scribbled down at the time.

Interesting post.

http://stevenlivingstone.com
January 27, 2004 12:46 AM

Rick Jelliffe said:

Another aspect is the cart-before-the-horse question of how much PSVI type information you require in your constraint schema: if the document has XSD/DTD invalid branches, then you can easily get many spurious errors when using Schematron-style XPath constraints.

In Schematron, http://www.ascc.net/xml/schematron we avoid that generally by providing the phase mechanism to turn off some patterns.

On the other hand, people may just be making fairly simple constraints from the constext of the current element or attribute. There is an implementation at http://www.topologi.com/resources/whitepapers.html
"Embedding Schematron in other Schema Languages" giving one common method.

But I like the exception idea, and I think I will propose it for ISO Schematron. We had been planning an "action" or "state" attribute for a similar purpose, but probably "exception" is better.

If you wanted your constraint language to be not gratuitously different to ISO Schematron, you could use

<xsd:element ...>
...
<xsd:annotation>
<xsd:appinfo xmlns:sch="http://www.ascc.net/xml/schematron">
<sch:assert test="not(.//x)"
exception="http://www.eg.com/exception/containmentException">
A <name/> should not contain an x as a descendent</sch:assert>
</xsd:appinfor>
</xsd:annotation>

I.e., add an exception attribute with an exception name as a URI to allow platform independence. (As a side issue, one reason people want exceptions is so they can generate customized diagnostic messages: Schematron already has a facility for this, and you might like to consider it if you want to also embed smarter diagnostics in the schema too.)

The XML Schema WG/IG at W3C has discussed adding XPath constraints, but I believe tey decided their plates were full maintaining what they already have :-)
January 27, 2004 5:31 PM

Andres Aguiar said:

Don,

We are trying to solve the same problem in DeKlarit but we are not using an XML-based approach for it. We have propietary declarative business rule language, where you can write:

error(OperationNotAuthorized, "Operation not authorized") if Amount > 1000 and UserRole <> Roles.Manager;

Then we generate some of this business rules in the typed DataSet itself and some in a custom DataAdapter that we generate to persist the data.
January 28, 2004 8:01 AM

TrackBack said:

February 4, 2004 6:03 PM

TrackBack said:

February 4, 2004 6:03 PM

TrackBack said:

February 4, 2004 6:05 PM

TrackBack said:

Dare Obasanjo aka Carnage4Life
February 6, 2004 1:07 PM

Udi Dahan - The Software Simplist said:

Just because you CAN do something, doesn't mean you SHOULD.

There is a serious problem today with the information available to developers. Everybody and their brother is telling them HOW to do X. Rarely do I see information on "If you do X, make sure you do Y first". Even less on "Why should you do X in the first place".

I feel that as a community, we've just about reached HOW saturation. What we need now is WHEN, WHERE, and WHY.
February 9, 2004 2:24 PM

TrackBack said:

The Problem with Typed DataSets?
May 4, 2004 8:44 AM

Leave a Comment

(required) 
(optional)
(required) 
Submit

About donxml

I’m an independent consultant, specializing in .Net solutions architecture, based out of New Jersey who also doubles as an evangelist for XML, Domain Driven Design, enterprise architecture and .Net. I do not work for Microsoft, the W3C or any other big company that you may know of (at least not yet). I’ve been an indie for over ten years, and although I’ve been tempted a couple times to take a job with companies like Microsoft, I’ve haven’t found something better than my current situation. I work mostly with the large pharmaceuticals that are based here in New Jersey, and usually find myself on long term contracts. Definitely not the prototypical indie consultant, but it lets me dedicate time to my non-income generating activities like the developer community stuff, plus financing open source projects like XPathmania and MVP-XML. If you would like to talk to me about doing some contract work, just contact me via the contact page. My rates vary widely, depending on lots of different variables, but mostly distance from Jersey, and type of work. Plus, I’ve been known to donate some of my code for various projects.
Powered by Community Server, by Telligent Systems