Heads-up!
This is a post that I made to the fantastic aus-dotnet mailing list when Clark Scott posted up about the utility of CRUD-style web-services. For business applications I tend to take a fairly dim view of CRUD layers being exposed as the external interface to the application.
The following is a post that I made on the aus-dotnet mailing list a few hours ago, I’ve included it verbatim except for marking up the XML using a syntax highlighter.
The Post: Designing for SOA
I've built applications using CRUD-style web-services. Its easy initially but it gets rather tedious in the end, and all you really get is a slow wrapper around your database. What I think web-services enable us to do is model business transactions, and the reality is that they are always there, if you look hard enough.
Lets look at CRM software in a call centre (an area you are probably familiar with Clark). While it is true that we display and edit information we aren't actually constrained to giving free form access to text fields.
Lets say that a customer calls up the call centre. After they have given the operator their details their complete or partial record is displayed. In most CRM applications today the operator can just go through and change pretty much whatever they want governed only by the policies that are written down in some word document that is propping up their monitor.
Rather than allow that what I suggest people do is define precisely the kinds of changes that are allowed and make that view read-only (without exception). You could then use inductive UI principals to guide the operator to make changes.
For example:
The customer wants to:
- change their address.
- resend the latest invoice.
- register a complaint.
Each of those entries becomes a separate customised UI which almost directly maps onto a message that is sent to the server (not as a CRUD operation but as a logical business operation).
Lets think through the ramifications of this for a second in the context of auditing and authorisation, concurrency and requirements gathering.
Auditing and Authorisation:
We now have a really neat way of auditing the particular business operations that get performed.
I'm sure all of us have worked on systems with audit tables that get updated every-time a field changes in the database. When you actually do get a security breach you need to search through the log for all the activities performed by a particular user over a certain period of time and try and figure out what series of database updates mean a user was doing.
With the above approach you would write an audit record in the database that says something along the lines of:
"MaryJo changed customer 11181's address from 5/9 Oxenham Circuit to 78 Rischbieth Crescent."
There is no need to dig through the database - there are less rows added to the audit table and your security officer (the person actually doing the investigation) doesn't need to know anything about relational databases to know what is going on.
Concurrency:
One of the big advantages data-sets have is that they tend to automagically deal with concurrency in simple situations. Of course the abstraction breaks down on larger projects but they still aren't bad.
The problem is concurrency is hardly ever as big a problem as people make out. If you look at most business software its designed to assist dealing with the customer. Since the customer usually only has one head (ignoring corporate clients and Tasmanians for the moment - sorry couldn't resist :P) you are unlikely to run into a concurrency problem down at the database - and if you do the customer generally has to accept responsibility for it - last write wins is very appropriate 60-80% of the time (figures plucked from thin air but I would be surprised if it wasn’t higher).
This means your little XML message can be remarkably simple:
1 <ChangeAddress>
2 <CustomerRef>11181</CustomerRef>
3 <Address>
4 <Line1>78 Rischbieth Crescent</Line1>
5 <Line2 />
6 <City>Gilmore</City>
7 <State>ACT</State>
8 <Postcode>2905</Postcode>
9 <Country>Australia</Country>
10 </Address>
11 </ChangeAddress>
The message back would also be pretty simple:
1 <ChangeAddressConfirmation>
2 <ReceiptNumber>11181-14</ReceiptNumber>
3 </ChangeAddressConfirmation>
If you looked at the WSDL for this as a web-service it would be painfully obvious what you need to send and what it will do. That’s very different from the CRUD model where you need to try and understand a database schema while looking through a toilet role.
Finally - if you happened to nead concurrency then you could use a message like this:
1 <ChangeAddress>
2 <CustomerRef>11181</CustomerRef>
3 <NewAddress>
4 <Line1>78 Rischbieth Crescent</Line1>
5 <Line2 />
6 <City>Gilmore</City>
7 <State>ACT</State>
8 <Postcode>2905</Postcode>
9 <Country>Australia</Country>
10 </NewAddress>
11 <OldAddress>
12 <Line1>5/9 Oxenham Circuit</Line1>
13 <Line2 />
14 <City>Gordon</City>
15 <State>ACT</State>
16 <Postcode>2906</Postcode>
17 <Country>Australia</Country>
18 </OldAddress>
19 </ChangeAddress>
That should keep the corporate and Tasmanian clients happy. On to requirements gathering!
Requirements Gathering:
Back when I was in high school we were told that one of the important things you needed to do during the requirements analysis phase is collect business documents as artefacts. It seems that over the years this practice has fallen by the way-side which is a pitty because if it didn't most of us would have had an AHA! Moment when we looked at SOA.
SOA is all about mapping the flow of business documents around the organisation. Before us geeks arrived business worked perfectly well on these crude pieces of paper. I believe that SOA design is about finding these business documents and turning them into electronic messages (ever filled in a change of address card as the post office?).
Once you have mapped out the messages in any enterprise you start to see where information surfaces. If you have collected some information and it doesn't surface then you either A) don't need to collect it and can optimise the business process or B) are missing some kind of business document artefact.
Does CRUD have a place in today's business systems at the web-service layer. Not much - but it does have a place in other industries. Data mining and analysis, military systems etc.