[Webapps-common-discuss] Flexible configuration of web apps/services

[Josef Spillner]

Hello,

please have a look at the attached draft for a webcontext debconf convention 
and comment on it or point to existing solutions to the problem mentioned 
therein.

Josef
-------------- next part --------------
New packaging infrastructure package: webcontext-common
Draft by Josef Spillner <josef.spillner at tu-dresden.de>
12.12.2009
=======================================================

Problem description:
 Operating system installations on servers are increasingly offering interdependent
 web applications and web services. Some packages are prepared for being used in
 multiple instances in parallel (multi-tenancy operation), while others are not.
 Sometimes external services are to be used, and sometimes the server hosts the
 relevant software by itself.
 In general, the setup of web apps and related resources, like databases, is not
 very straightforward.

Use case:
 The ????? Service Platform (serviceplatform.org) is a distributed web service
 marketplace for the upcoming Internet of Services. It consists of several platform
 services which often link to each other to some extent. Some are also integrated
 through shared databases. The use on a live medium requires all components to use
 local hostnames, either as virtual subdomains (like foo.demo and bar.demo) or
 differentiated by port numbers (demo:80, demo:81). The URLs containing these
 base context URLs are primarily used in configuration files.

Web context concept:
 (Should be integrated with debconf, for now suggested as external app)
 For each package using webcontext-common, a context needs to be specified.
 A number of contexts can be predefined. This is especially useful for virtual
 networks on live media and for development.
 All "context-dependency" packages using webcontext-common will be used in the postinst
 to query their context URLs. This takes into account the context(s) configured
 for these packages, including predefined contexts and multi-instance contexts.
 As these dependencies can be fulfilled by remote services, they're kept separate
 from Debian package dependencies but instead are recommended so that they're still
 pulled in by default. (This is a separate, long-lasting dependency management issue
 and will not be solved by this proposal.)

Web context example (via use case):
 There are three web apps, access-gate (a SOAP proxy), provider wizard (a service
 provisioning tool) and puq (a unified hosting environment).

 User installs access-gate
  Offered contexts: [access-gate.demo:80, other/specify]
  Configured context: [foo.invalid:80]
 User installs providerwizard
  Offered contexts: [providerwizard.demo:80, other/specify]
  Configured context: [foo.invalid:81]
  Offered dependency contexts for access-gate: [access-gate.demo:80, foo.invalid:80, other/specify]
  Configured dependency context for access-gate: [foo.invalid:80]
  Offered dependency contexts for puq: [puq.demo:80, other/specify]
  Configured dependency context for puq: [someotherhost:9090]