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
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
Office: +1 646 290 8050
Cell: +44 798 447 4618
blog: http://pzf.fremantle.org
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
_______________________________________________
Registry-dev mailing list
Registry-dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
