[Registry-dev] Registry as a library inside other products
Paul Fremantle
paul at wso2.com
Thu Dec 13 01:37:03 PST 2007
Sorry not to reply earlier. Comments inline.
>> * There is a "init" method which does lot of datasource related work.
+1 I thought we had consensus to get rid of these and just use
constructors.
>> JDBCRegistry(DataSource dataSource)
+1
>> If what user has is a DB URI... he will,
>>
>> new JDBCRegistry( new RegistryDatasource(DB URI, ...) )
I'm not sure I understand that but I will take a look at the code and
try to grok it.
>> * The SecureRegistry doesn't completely encapsulate the Registry
>>
>> Right now the user has to construct a Registry and pass it to the
>> SecureRegistry. The problem here is, there is insecure access to the same
>> registry since the use build that externally. If we aggregate the Registry
>> in to the SecureRegistry, an instance of a SecureRegistry is always secure.
No I don't agree. This was a deliberate design. The code that
instantiates the real registry (new JDBCRegistry) does of course have
full access to the internal registry. But that is life. If I have the
uid/pw of the database then I have full access to the database, I can
mess it up as much as I like.
The point of having the SecureRegistry take a registry as a parameter is
to completely isolate the security from the main registry code - AND the
registry from the security code. Think of it in terms of Aspect Oriented
Programming.
The security in real life comes from the fact that the WebApp ALWAYS
uses the SecureRegistry interface.
Paul
>>
>>
>>
>> BTW, I was thinking about Paul's reason to have a JDBCRegistry class and a
>> InMemory Registry class where he would like the developer to know what
>> exactly he is going to get just looking at the class name (without reading
>> the Javadoc). In that case how about naming them as, "PersistentRegistry"
>> and "TransientRegistry"?
>>
>> /Sanjaya
>>
>> On Wednesday 05 December 2007, Chathura C. Ekanayake wrote:
>>> Paul Fremantle wrote:
>>>> Sanjaya has also persuaded me (on IM) that we should add another
>>>> constructor
>>>>
>>>> new JDBCRegistry(DataSource dataSource)
>>>>
>>>> I'm not sure if there is an equivalent that uses a Connection as well.
>>> I think Sanjaya is proposing to have a DataSource implementation that
>>> can wrap a Connection to handle this scenario.
>>> So we need only one constructor to instantiate a registry with a
>>> database connection (datasource or connection).
>>>
>>> Thanks,
>>> Chathura
>>>
>>>> Paul
>>>>
>>>> Sanjiva Weerawarana wrote:
>>>>> +1.
>>>>>
>>>>> 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 at wso2.org
>>>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Registry-dev mailing list
>>>>>>>>>> Registry-dev at wso2.org
>>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>>>>>> _______________________________________________
>>>>>>> Registry-dev mailing list
>>>>>>> Registry-dev at wso2.org
>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>>> _______________________________________________
>>> Registry-dev mailing list
>>> Registry-dev at wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>> _______________________________________________
>> Registry-dev mailing list
>> Registry-dev at wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>
>
> _______________________________________________
> Registry-dev mailing list
> Registry-dev at 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
paul at wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
More information about the Registry-dev
mailing list