> Unfortunately, I have no idea what a "California DMV" is :-)
IIUC, I think "DMV" means "Department of Motor Vehicles", the govenment
agency that issues driver's permits, tracks the state of vehicles (to ensure
they are "legal") and so on. Somebody please correct me if I'm wrong.
> > I have a question. Do people really use OSGi services for
> > such fine grain objects such as vehicles? The California
> > DMV comes to mind. I was always under the impression
> > that it was intended for more course grained services.
> I was merely continuing the example as stated by David. However
> you're probably right: assuming the Vehicle here represents some
> kind of domain model object, then it would be unusual to register
> it as a service. Instead we might register some kind of
> "VehicleManager" which would be responsible for, say, looking
> up Vehicles in a database, persisting changes, etc.
Ok, it was a crappy example, but your question is very relevant, and the
answer is that there is no right answer: it depends on your needs.
I discussed this issue very briefly once with BJ Hargrave. He mentioned that
at IBM, they use mostly course-grained services, the main reason for which
being that within a very large organisation, it would be a nightmare to try
to manage fine-grained services.
For other smaller companies that can manage finer-grained services, they
could harness the benefits of reusable services to eliminate duplicate code.
Maybe you'll want something in between?
In any case, what Neil says about services is right. For example, you could
have a VehicleFactory or VehicleManager registered as a service. The great
thing about this approach is that you can swap out the implementation at any
time, or even provide more than one implementation depending on the context
in which you use your application. Perhaps a VehicleFactory isn't so
fine-grained, because maybe if you are the California DMV you have a huge DB
of vehicles behind the service.
Or maybe you have both a VehicleFactory service that only retrieves stuff,
and a full-blown VehicleManager that can do a little more. Maybe you only
expose the manager to "inside" developers, and the factory to the public so
they can't do any damage. You can register the same implementation under
different services interfaces.
One thing that's really cool about OSGi is that you can "hide" very complex
services behind an incredibly simple interface. So, depending on the
application, this service could be trivial, or very complex, so don't be
fooled by a simple-looking service interface like this:
public interface VehicleFactory
{
Vehicle getVehicle( String registrationId );
}
Cheers,
David
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
