SOA base component packaging
Hello,
I'm currently working on system integration of services and components for
service-oriented architectures. Among them are a few commonly used base
components which would be useful to have in Debian, and the rest would rather
go into a derivative/pure blend due to their specialisation and narrow
potential userbase.
Instead of heading off to file random RFPs/RFSs for them, I'd prefer a more
coordinated approach up to the point where one of the release goals for one of
the next versions could potentially include the SOA-ready buzzword :)
Debian ships with several client packages to often proprietary web services,
but is not yet a powerful platform for coming up with modern free service
hosting facilities by itself.
The following functionality is currently not provided by Debian:
* A message-oriented middleware - Apache ActiveMQ could fill this gap.
* Client libraries for OpenWire/Stomp to access the middleware. For my purpose
I'd need stompcli for PHP5.
* An XML database. Sleepycat/now Oracle Berkeley DB XML seems to have suitable
licencing terms and good binding support. I'm interested especially in the
Java version. See #307412 for a former ITP and #524039 for a related Ruby
bindings package RFP.
* A BPEL engine. There are several of them freely available. Apache ODE would
be my preference. There are some issues with it, e.g. it doesn't run on
Debian's tomcat6 package due to permission issues but runs fine on upstream
Tomcat, so this would require some coordination on Tomcat security policies.
* An OSGi container. Knopflerfish, Eclipse Equinox, Apache Felix come to mind.
* Several Ruby gems, especially httpclient, xml-object and prawn
In addition, several current packages are heavily out of date even in
unstable, see e.g. #531794 for Ruby and similarly for python-soaplib which
seems to be taken over by its lxml fork now (remember gcc/egcs).
Assuming that people other than myself are interested in this effort, I would
create a page on wiki.d.o to track the status. Some initial packaging metadata
is already available for each package and could easily be imported into, say,
Alioth.
Discussion might be appropriate on other lists (-java, -ruby, -isp come to
mind), currently I'm not subscribed to any of them, hence no crossposting.
Josef
Reply to: