How Does the UI Fit In?
It is axiomatic that we want validity checks to occur as close to the user as possible, and this is why we often duplicate validity checks in the UI layer itself using validation controls and the like. We don't want users to have to wait long to know that what they've given the application is valid (or invalid); we certainly don't want them to walk away thinking that they've given valid data when they haven't.
|Once we allow for the possibility that the database is not and indeed should not be thought of as the center of our application, it allows us to think more in terms of how the business thinks, chiefly how to get things done.|
In other words, we definitely want to have as much validation as possible occur on the "client side." So how can we make this mesh with a separate validation layer? This goes back to my dual-naming of the validation layer as a service. We need to be able to call this layer either directly or through the domain model to ask if the data as it stands now is valid. If it is a WCF service endpoint, a standard Web service, or a direct method call-whatever it is-we need to be able to ask it from the UI what is valid and what is not.
If you were using WF as I suggested earlier, this might imply a child workflow that is specific to a UI flow that has its own set of rules attached to the various points in the UI flow. If you don't need that extra granularity, you can just ask the main workflow if the document is valid. The nice thing is that WF is flexible enough to make such an approach work.
If that isn't responsive enough, you could add a client-side validation generator to the framework to attach appropriate validation controls to the UI based on the current point in the process. But I tend to think that's over the top. Even with Web applications, you can use asynchronous server requests to your validation service while maintaining a usable interface for your users without going to the extra trouble of duplicating validation in the UI layer itself.
How Does SOA Fit In?
So you have this application that has a domain-driven-designed, behavior-based domain model. You have a persistent data store that plays well with your domain/process-driven design, and you've written your UI such that it takes advantage of your validation layer without duplicating logic. So what about this SOA thing?
It should be clear by now that the validation layer could (and probably should) be exposed as a primary service in your application. But contrary to some approaches to designing services, the messages should be loosely-schema'd. This means you need some basic XML payload that will contain the data to be validated that has virtually no schema attached to it, some kind of identifier for the data, and some kind of identifier for the instance of the process (e.g., a WF workflow ID). This should be sufficient for the validation service to find the appropriate workflow, ascertain its state, and request validation of the XML payload it was given.
You might also expose particular services that are specific to certain objects during certain points in their lifetime. These can adhere to the more strongly-schema'd contracts because they are both object and point-in-process-specific. These are also more likely to be the kinds of services that you expose to other applications.
Where to Next?
Most everything I've discussed thus far is reasonably achievable with Microsoft technologies as they stand today. But I do think that we could do better. Maybe we're limited by the generalness of the general-purpose languages that are far and away the most popular in the business market (Visual Basic, Java, and C#), so maybe it's not an option to change those to be more process-centric.
As it is now, even for a standard approach to workflow, things are far too complicated. While it is good that WF is an F (foundation), it would be better if process awareness was built into the language and even the runtime itself, such that we're not learning a bunch of abstractions on top of GPLs and general-purpose runtimes. What I'd suggest is workflow and point-in-process-specific schema become easy to define using language constructs and easy to interact with and query.
If changing the GPLs and CLR is not an option, how about a language for business applications that has the features I'm hinting at? Even if we have to stick with frameworks and foundations like WF, how about a language that makes their usage integrated? I think something like this would be ideal and would be a big step forward in how we think about, design, and implement business applications.
Of course, this will never go anywhere if I'm the only one who thinks this is the right way to go. For all I know, I may not be the only one thinking this way. I'm certainly not intentionally stealing anyone's thunder, though I'm sure all of this comes out of a jumbled blend of my own experiences, critical thinking, and what I've heard and read others thinking over the years. I'm sure the more erudite readers will be happy to point out similarities in what I'm suggesting with what others have suggested, but hopefully there is something useful and original here, if not in the content then in the packaging.
|This is not negating what we have now in terms of architectural approaches, methodologies, or tools.|
In any case, I believe that any change in our industry in such a direction would have to be a grass roots effort that convinces a vendor with enough influence to produce tools to support this way of thinking about application design. Microsoft has proven itself to be responsive to developer customer input, and they've taken important steps in this direction with WCF and WF. If you think something like this sounds good, talk it up and spread the word-make sure other people know about it so that we can get the rest of the industry on board. Process-driven design is, I think, the next evolution we need to adequately address business needs.
Much of the foundations are in place; this is not negating what we have now in terms of architectural approaches, methodologies, or tools. In fact, it fits very nicely with agile development practices that have been rightly gaining popularity. It could easily fit in with test-driven design as well. I see all of these fairly recent advances in our industry (again in terms of architecture, software development life cycle, and in tools and frameworks) to be important and necessary foundations on which a process-driven design paradigm could be erected.
I'd love to hear what you think, so please either comment on this article online or send me an e-mail, and if you think it is worthwhile, blog about it, tell your friends, and just generally spread the word.