The DataConnectServer (DCS) Project / News: Recent posts

dcnut, evidently an australian company, sent me the following email (from adam crow, acrow@dcnut.com):

"Good work on the project.
Just a note that in Australia the name dcserver is a trademark
of ours. Just in case there is confusion .
Our product is being launched in the US next year."

so, uh, they're giving me a pat on the back and a friendly notice that i'm infringing their trademark . . . or are they? and indeed, am i infringing anything? try the following google search:... read more

i am rather lame.

i've been digesting and interpreting what the osgi spec has to say about service loading, classloaders, service and bundle management, etc. since i'm choosing to make new features and changes as compatible as possible with osgi (with the eventual goal of being an osgi-compliant server), the dynamic service loading design has to take this into account.

it would be an easy addition otherwise. but keeping the changes in line with the eventual osgi-ness will take just a bit longer. also, with this change i'll be adopting the osgi's service/bundle archive format (just jar with osgi-specific extensions really).

recent events have left me without much time for hacking on the dcserver . . . what little i've done is all about the ca. i've fleshed out the service apis - that's half the fun. the other half is getting the services to actually talk to each other. i've started to actually code some of the certificate code - the cipher stuff will be fun ;)

bummer that sun's jce doesn't include api calls for directly creating x.509 certs. oh well, it's easy enough to get around but silly to have to do.

i've had a number of emails now asking me what is functional now vs. what will be completed in the future. so, let me try to summarize.

currently the dcserver bootstraps itself and provides several basic services: logging, persistence (string, java objects, and raw bytes), and event services (scheduled events and pub/sub). a simple and logical component and service api exists to allow developers to easily develop and deploy their own services; as such, it's a great platform for developing any server-oriented, long-lived application.... read more

so . . . i was looking at the osgi 2.0 spec, and i recalled what started me down the path that resulted in this project. it was building a residential gateway server, osgi-compliant, with 802.11, infrared, x10, blah blah. then, the project became the basis for something more, which i still want it to be. but i also want to return to a portion of the original vision: the dcserver should be compliant with the osgi framework spec, so that it is a suitable candidate for embedding; at least, osgi has a spec for embedded gateways/servers, and we might as well work from/to a spec. the current design should be largely the same, with some minor additions and changes.

got it running on linux tonight - no real difficulty.

it seems to run faster now (big surprise there).

so - more or less, the basic pieces are in place:

1) the service container

2) the core and standard (non-core) service deployers

3) the core services:
- logging service
- persistence service
- event pub/sub and job scheduling service

which means that we're very close to releasing what i would call an alpha: a working version that a programmer could use to implement and deploy new services. i need to write the "service writer's cookbook/howto", and then i'll package and release the alpha.... read more

i've checked the event service into cvs - it has two major facets:

1) a pub/sub system: clients of the service can publish events in the form of a String event identifier and a java.util.EventObject object. clients can sign up (subscribe) with the event service for specific events; clients must implement the dcs.service.event.EventSubscriber interface

2) a job scheduling service: clients can add jobs to be scheduled by submitting dcs.util.scheduler.SchedulerJob objects along with a desired frequency for running the job... read more

i've implemented a basic but flexible persistence service based on an embedded sql-based db engine, hsqldb. the service implements the dcs.service.persistence.PersistenceService interface, and allows either memory- or disk-based storage.

just one more core service to implement (the scheduling and event service), and then the 1st alpha release of the dcs foundation will be complete!

- r

it's based on apache/jakarta's log4j. it works pretty well.
- rp

okay, today i checked in the code - it's not release-quality yet, but it's got very very basic functionality, and the skeleton for what's to come. check it out!

- r