Complex Services And App Languages

There is a growing general issue over how complex services interact with application languages. Query languages (databases) and GUI systems are the most common current examples.

Such services are generally designed to be more-or-less language neutral. This is done for the spirit of OnceAndOnlyOnce and standardization.

Heavy customization of complex services for each language would not be practical, and thus certain conventions and techniques of the service may not be a tight match for the style and paradigm of a given language. This is where most of the conflicts tend to arise. If somebody is using a language they like or invested time in mastering, they often don't want to have to go outside of its tools and conventions to use the "external" service.

Questions that come up include:

If the service builds complex structures, will these structures be "stored" in and by the app language, by the service itself, or mirrored by one or the other? (In this context, "complex structures" refers to many data nodes/records/objects interrelated in some way, and beyond just a list or simple hierarchy.)
How much will the service rely on the app language for complex expressions and conditionals? Will the "expression" burden be on the service or the app language? Can and should the service be designed to allow both as needed?
How and if it should integrate with the app-language TypeSystem.
Is making the service more declarative, in particular attribute-driven, and less behavioral a way to improve app-language independence? Will this upset behaviorist proponents?
Should the service attempt to mirror popular or common paradigms to make it fit app languages of the same style better? Will this lead to rejection of the standard by camps not happy with said paradigms or styles?
Should we have one-service-for-all, or split the service into 3 or so different "flavors" to match different common paradigms/styles? This is kind of a compromise between service-per-language and a single shared service. (This may not work in cases where the service state is shared between multiple different languages at the same time.) If this is pursued, I tentatively propose:
- An "attribute-driven" style with a weak/dynamic typing tilt.
- A type-heavy OOP style (OOP is well-suited to heavy-typing in my opinion.)
- A functional/logical style modeled roughly after ProLog, using user-definable AbstractDataTypes.

DivideAndConquer of complexity will likely result in more reliance on such services in the future such that addressing these issues now, or at least documenting them, may save us headaches down the road. (Or at least prepare for the headaches if not resolvable.)

--top

CategoryInfoPackaging, CategoryInterface, CategoryComplexity