Re: [teiid-dev] Teiid Admin API Access Changes
After spending some time on development of providing the remote client
access to Admin API through profile services, I have found that, in
container environment to invoke a remote ejb (ProfileService) requires a
large number (up to 25 MB) of classes as dependencies. This is simply
too much of dependency for Teiid. Especially for tools like Designers
would be burdened with managing them as they require to use the Admin
api.
To overcome this issue, we are going provide a proprietary socket based
connection for for Admin API, such that it would only require the
current Teiid JDBC client jar to connect and issue any Admin commands.
This is very much similar how Teiid functioned in prior releases.
The difference in this version is this is going to be a totally separate
connection to that of JDBC connection. So, Teiid will be listening on
two separate ports, one for the JDBC and another for Admin based calls.
Anonymous SSL will be turned on by default on the Admin based connection
for security of data in-flight. This connection will be tied into
container's security domain such that this connection would require
exactly credentials as security domain of a Profile Service.
Thanks
Ramesh..
On Sat, 2010-01-09 at 23:47 -0600, Ramesh Reddy wrote:
In prior releases of Teiid, if a user wanted to access Teiid's
Admin
API, they could get access to this API through JDBC connection. This was
a convenience method Teiid had provided. Internally Teiid created a
additional connection for admin.
With changes coming from management framework and security, even though
supporting the above is possible, it does seem right. What if, the
developer who has access to a JDBC connection can not have access to the
management or vice versa. Keeping this convenience access together under
single connection, also adds significant size to the Teiid's client JDBC
driver JAR to bundle the management framework.
So, we have been thinking to take these apart such that JDBC connection
only provides the access to the data side of the engine, where as a
separate "admin" connection will provide a management access. It will be
still possible for single user to be in the both roles, however they
would simply need to make two separate connections to access respective
functionality. This would let us package the admin access classes into a
separate jar file, so that this jar would only be required by users who
are dealing with admin functionality.
Please let us know if you have any comments.
Thanks.
Ramesh..
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev