Because the Request/Response paradigm is tied to the way we think about web applications, it seems that our frameworks and even our business logic must also be bound to the different request/response APIs. Is this necessary? Is it possible that the Request/Response concept is hindering the separation of Workflow and Data components by fulfilling both roles at once?

I'm working to abstract Action components in Shocks from the Servlet API. I've encountered a curious problem. Perhaps it is a big problem. In order for this whole thing to be a "framework", there need to be points of attachment. Simply removing all of the dependencies to these things in the method signatures isn't enough. The user might still need to get at that information.

But they might need to get at the information from a SOAP request. Or a Portlet request. Or maybe they might want to respond to some generic request triggered by an email message.

Ultimately, the Action classes need to perform operations on Data. Whether the data comes from mySQL, an HttpRequest or a JDO should be beside the point for the action. Why should it know or even need to know the nature of the object from whence it's derived its data (other than that it can get information from there and place it back there once it's done using it?)

Now that I've gotten clean separation between action and workflow, it's time to do the same with action and datasource (and workflow and datasource). And I'm not talking about the javax.sql.DataSource interface. I'm talking about any old source of data which an action component (tiny little thing that encapsulates a business operation). I don't want Action classes to have to implement some stupid ServletRequestAware interface just so they can access the servlet request. There'd be a dozen little interfaces like that and I know people have turned away from that in the past.

Nor do I really want to make the WorkflowContext object to have to implement a dozen little interfaces like that. It seems odd that we'd have to add another little interface each time a new protocol came around.

What if some company has a cool but little-known protocol they like using but it isn't supported in our workflow engine? They'd have to hack it in or we'd need to add it in ourselves. Seems a little stupid. Maybe there's already a "meta-protocol" for managing information with a RCP-style request, an asynch request or some kind of multihop protocol?

Greg Wilkins mentioned a concept for managing the data in a web application called "ContentLets", which sounds extremely analogous to what I've been thinking about making. Basically, something to provide a handle to and manage the state of the different representation components in a way which is representation and protocol neutral.

The action should just be able to ask for a chunk of data and get it from some kind of environment context, without making assumptions about the source of the data. In this sense actions should be completely protocol neutral. SOAP, Http, Servlet & Portlet protocols should all work the same. The context could be injected to the action through a constructor or an execute(DataSource context) method (which is how I'm planning on doing it since actions are constructed, cached and cloned well before they come into use and since they are stateless by design.)

Also, someone told me that the word "DataSource" wasn't cool to use because it infringed upon the javax.sql.DataSource namespace. I can't think of a better term for the concept, and it strikes me that

1. packages are supposed to address this problem. Otherwise,
2. javax.sql.DataSource probably could use a better name.

Mine is the most abstract concept of "data source" that I can come up with and which is still useful: a source from whence data can be drawn and into which it can be stored. Maybe there's a better, more abstract term which I am missing, and I'll happily switch the API if someone can tell me what the word is (and I have access to the OED, so you'd better make sure it's etymologically sound).

"The difference between the almost-perfect word and the perfect word is really quite a big thing; it's the difference between the lightning bug and the lightning." -- Samuel Clemens