Hi Paul, The datasource I am refering here is the java.sql.Datasource interface. So what you get is a java.sql.Connection which you will be using internally like you do now.
Also this helps you to overcome the problem of having to treat a registry which need to work with a JDBC datasource as a different class of a problem. I do understand the need to have a registry interface. But then each implementation should handle different class of a problem while demonstrating the same behavior. SecureRegistry and Registry sounds right. But I dont' see how a JDBCRegistry fits in here. This is simply a design issue. There are many implementations techniques to overcome the programming language constrains when you have the right design in place. /Sanjaya On Tuesday 04 December 2007, Paul Fremantle wrote: > Sanjaya > > We did already look at this design where there were two key interfaces: > the Registry interface and behind this a DataStore interface. However, > we realized that the underlying datastore had to implement almost ALL > the logic that was in the Registry interface, so instead we refactored > it so there is only one key interface: Registry. The different > implementations - InMemory and JDBC are fundamentally simply different > backends. SecureRegistry works by implementing a security layer over > whatever backend you specify. > > We whiteboarded this in Colombo and came to a decision, so I suggest we > don't re-evaluate that. > > I can assure you that the InMemory and JDBC do not expose implementation > details - they both strictly implement the Registry interface. Of course > they do expose *implementation choices* - which is the purpose of having > an interface/implementation split. > > Paul > > Sanjaya Karunasena wrote: > > Hi Chathura, > > > > I see few OO problems here. > > > > First, InMemoryRegistry, JDBCRegistry doesn't sound polymorphic. It > > simply exposed implementation details. Do you have an abstract class > > Registry? > > > > What we have here is a Registry which can work with different > > Datasources. If a datasource is not available it can maintain data > > in-memory. So there are two classes here, Registry and a Datasource. If > > you need further specilization from the standard Datasource, you can have > > a > > RegistryDatasource. > > > > Then the API would be; > > > > RegistryDatasource(String datasourceName) > > RegistryDatasource(String driverClass, String URL, String userName, > > String password) > > > > Registry() //Use the in-memory DB > > Registry(Datasource datasource) //Use any given datasource to retrieve a > > java.sql.Connection and use it. You can use the RegistryDatasource here. > > > > Thanks > > Sanjaya > > > > On Monday 03 December 2007, Chathura C. Ekanayake wrote: > >> I like it too. Then the constructors imply what is happening inside. > >> Shall I change the code according to this? > >> > >> Thanks, > >> Chathura > >> > >> Paul Fremantle wrote: > >>> I understand that we are using HSQLDB to provide the in-memory DB, its > >>> just a bit odd that the class is called JDBCRegistry. > >>> > >>> From a beginners perspective, wouldn't it make more sense to have > >>> another class called InMemoryRegistry. Of course under the covers it > >>> can use the JDBCRegistry with HSQLDB? > >>> > >>> I'm just trying to think of this from a beginning programmers > >>> perspective, and I'm not convinced everyone is going to automatically > >>> think of using a JDBCRegistry to do in-memory. > >>> > >>> So my preference would be: > >>> > >>> new InMemoryRegistry() > >>> new JDBCRegistry(String datasourceName) - Use the given data source. > >>> new JDBCRegistry(String driverClass, String URL, String userName, > >>> String password) - Use given connection URL to connect to the DB > >>> > >>> > >>> Paul > >>> > >>> Chathura C. Ekanayake wrote: > >>>> +1. So shall we remove "allowInMemoryDB" parameter from all > >>>> constructors and only start the in-memory database if the default > >>>> constructor is used. > >>>> > >>>> Then the constructors would look like: > >>>> > >>>> 1) JDBCRegistry() - Use in-memory DB. > >>>> > >>>> 2) JDBCRegistry(String datasourceName) - Use the given data source. > >>>> > >>>> 3) JDBCRegistry(String driverClass, String URL, String userName, > >>>> String password) - Use given connection URL to connect to the DB > >>>> > >>>> Thanks, > >>>> Chathura > >>>> > >>>> Paul Fremantle wrote: > >>>>> I'm bothered about the "fallback" to an inmemory database. I don't > >>>>> think that makes sense as something to do automatically. > >>>>> > >>>>> Surely its better for a user to explicitly try to start the JDBCReg > >>>>> and if that fails catch the exception or null and then create an > >>>>> in-mem Reg? > >>>>> > >>>>> Paul > >>>>> > >>>>> Sanjiva Weerawarana wrote: > >>>>>> +1 for 3 alternative constructors. Since the registry is unusable > >>>>>> until init'ed, IMO constructors make more sense. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Sanjiva. > >>>>>> > >>>>>> Chathura C. Ekanayake wrote: > >>>>>>> We want to allow users to configure registry database in different > >>>>>>> ways (e.g. using a data source, using a connection URL, specify > >>>>>>> whether to start in-memory database if other database is not > >>>>>>> available). > >>>>>>> > >>>>>>> So we provide few methods in the JDBCRegistry to configure them. > >>>>>>> We only want the registry to initialize after those parameters are > >>>>>>> configured. > >>>>>>> And we don't know whether the user is specifying them or not at > >>>>>>> the construction time. Therefore, user has to call init() after > >>>>>>> configuring them. > >>>>>>> > >>>>>>> Alternative would be to have 3 constructors. > >>>>>>> > >>>>>>> 1) JDBCRegistry() - Use default datasource name if available. If > >>>>>>> not available, use in-memory DB > >>>>>>> > >>>>>>> 2) JDBCRegistry(String datasourceName, boolean allowInMemoryDB) - > >>>>>>> Use given data source. If not available, use in-memory DB > >>>>>>> depending on the allowInMemoryDB parameter value > >>>>>>> > >>>>>>> 3) JDBCRegistry(String driverClass, String URL, String userName, > >>>>>>> String password, boolean allowInMemoryDB) - Use given connection > >>>>>>> URL to connect to the DB > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Chathura > >>>>>>> > >>>>>>> Paul Fremantle wrote: > >>>>>>>> Chathura C. Ekanayake wrote: > >>>>>>>>> JDBCRegistry registry = new JDBCRegistry(); > >>>>>>>>> registry.init(); > >>>>>>>> > >>>>>>>> Love it! That's what I was looking for. > >>>>>>>> > >>>>>>>> Last question - why do we need init()? > >>>>>>>> > >>>>>>>> Paul > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Registry-dev mailing list > >>>>>>>> Registry-dev@wso2.org > >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Registry-dev mailing list > >>>>>>> Registry-dev@wso2.org > >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev > >>>> > >>>> _______________________________________________ > >>>> Registry-dev mailing list > >>>> Registry-dev@wso2.org > >>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev > >> > >> _______________________________________________ > >> Registry-dev mailing list > >> Registry-dev@wso2.org > >> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev > > > > _______________________________________________ > > Registry-dev mailing list > > Registry-dev@wso2.org > > http://wso2.org/cgi-bin/mailman/listinfo/registry-dev -- Senior Software Architect WSO2 Inc. www.wso2.com Office: +94 11 242 4303 ext 213 Mobile: +94 77 738 2548 "Oxygenating the Web Service Platform." ================================================== “Opportunity is missed by most people because it is dressed in overalls and looks like work.” - Thomas Edison _______________________________________________ Registry-dev mailing list Registry-dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
