Tuesday, September 21, 2004

Large Integration Project - No time to blog?

Received the go-ahead today to start on a very large integration project. As the result of an acquisition, we have an e-commerce solution that needs to connect with our enterprise solutions (yes, plural). I've already identified what will, most likely, be the easiest path to follow, but the way our market shares lay out, it isn't going to be the one that gets completed first. This puts me in a very difficult position of trying to do what's best for the software architecturally, what's best for the company in the short-term, and the former, again, which will be best for the company in the long-term. It's an interesting conundrum.

Unfortunately, this project isn’t going to leave me anytime for my pet projects, so the composable DSLs are just going to float for a while. I wish I could put more hours into my weeks, so I could do my job, and have time left to do the technological things I’m interested in on a personal level. I do get to participate in one standards body as part of my regular job, and standards do interest me on a personal level (as well as professional) so that helps, but I have ideas for my own business ventures that never seem to get enough attention, and I know I’ve missed some very lucrative opportunities.

The SOAPbox

If you happened to find the previous post interesting, you may also want to take a look at Richard Veryard's SOAPBox.

Richard had commented on the previous post, but since I decide to recreate this blog under it's own user in order to isolate it from my not quite serious stuff, the comments were lost.

Domain Specific Languages

Domain specific languages (DSL) are, I believe, the future of software development, well at lest as far as human computer interaction is concerned.

In a world where the majority of the people have at least some rudimentary technical skills, not necessarily computing skills, just technical, DSL will become the mechanism for interacting with the fundamental applications supporting not only their technology, but also their interaction with other technologies. However, making DSL viable will require that the DSL be more than a mini-language, as DSL success will depend on several factors:

  1. DSLs must be application, platform, and framework independent

  2. DSL will be combinable into another DSL or a super-language

  3. Different DSLs may have conflicting terms requiring resolution methods

  4. DSLs verbiage will be a realization of the Suggested Upper Merged Ontology (SUMO)

  5. DSLs will be syntactically identical allowing multiple DSLs in an application

  6. More to come...


Why Domain Specific Languages?

Let’s face it. Different people perceive things differently, even though their knowledge may be grounded in the same field. Problems have multiple solutions, and people adopt the solutions that they best understand. The natural evolution of human-computer interaction should be toward interfaces that are user-driven rather than program driven [1].

Suppose the process of using an ATM to withdraw cash from your bank could be controlled by you, the user, rather than by the programming of the ATM. The ATM must retain its ability to enforce such business rules as necessary, provide appropriate security, etc., the HCI should be controlled by you the end user. And, it should be the same sequence of events across all of the ATMs regardless of the ATM manufacturer or controlling institution. Personally, I only use an ATM to withdraw cash from a checking account. I don’t want to answer all of the other questions. My process would be something like this:

  1. Insert card

  2. Authenticate me

  3. Prompt for the amount (default to $200)

  4. Accept the amount

  5. Automatically accept charges that are < 1.5% of withdrawal

  6. Give me my money

  7. Show me my balance

  8. e-mail me my receipt

  9. Be done

Since this is a process, what does it have to do with DSL? The business process execution language (BPEL) is a domain specific language. For the above example, BPEL could be used to define the process flow. However, BPEL correctly doesn’t step out of the process domain, which leaves something missing from the picture. The builder the BPEL process must know which end-points to invoke, thus rendering BPEL useless to the average person engaging with domains outside his or her own. DSL would not provide the end-points, but would rather provide the verbiage necessary for the average person to take charge of their HCI. The realization of the DSL would be accomplished in the developer’s choice of language/platform, but the DSL would provide the developer with some portion of the program specification.

For the purposes of this discussion, let’s term the point at which a user is attempting to interact with a system the point-of-application (POA) [2].

The POA would receive DSL inputs from the user, and dynamically determine the appropriate end-point to bind with the interaction. The person creating the DSL process needn’t know the endpoint, they only need to be able to indicate the type of endpoint they wish to interact with.

To be continued...

[1] For the purposes of this article, we are concerned with the end-user interacting with their domain. This is not to say that validate machine driven human-computer interactions do not exist, they most certainly do. Maybe the second type should be referred to as computer-human interaction.

[2] This could also be termed the point-of-interaction, but the user could actually be physically removed from the system the are trying to interact with (say via cellular phone), so I think the point-of-application is more suitable.