In general I get the reasons for this change, and think it's on whole a positive
shift, but want to drill down into some areas.
https://jira.jboss.org/jira/browse/TEIID-1077 defines the split into
translation/connection for individual connectors, and leaves some of them TBD but states
that some will not be JCA for the connection.
Q: Are we 'enforcing' the division of these components through the APIs we're
offering, or are we introducing a design pattern for connectors such that if you have a
JCA connector for source X, you can just write a translator for Teiid. LDAP seems
amenable for the design pattern case; I don't know that they are available or good but
there are hits for LDAP-JCA connector. For the TBD sources, and forthcoming connectors,
is the connector writer free ti implement the connection as they choose, or are we
establishing some kind of Connection API that the translation layer will use and that must
also be implemented?
Also, as part of the embedded Teiid for Designer which results from this change, its been
proposed to me that we use DTP as the infrastructure to create and manage connections to
sources for metadata and embedded execution. In an earlier thread we discussed using DTP
in this way (minus the execution part) and decided it wasn't a good idea because it
would cause confusion for the user to have all of these DTP connections that don't do
anything in the DTP views/tools (I've since had a chat with John Graham who says there
is precedent for using DTP in this way, although he agrees it is confusing). One
implication of this decision would be that any connector that is to be executed in
Designer will need a DTP Connectivity plugin. This significantly raises the bar for any
custom connector that is not a modification of one of our connectors (eg, SQL translators
for JDBC). It raises the bar not only in terms of effort, but it involves a different
skill set (eclipse develppment) that we did not require before. The alternative seems to
me that you have to deploy to Teiid test with your custom connector. Perhaps this
limitation is acceptable, I just want to highlight it. We can or course provide examples,
templates, etc to assist in this effort.
Still wrapping my hear around this...
~jd
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
I forgot to mention one more big plus going into this mode of
dividing
the connector binding is, supporting the "embedded" mode will be now
possible for Teiid.
After this change, essentially a host environment like JBoss AS is
providing
- data sources
- transaction manager
- xa terminator
- Work Manager
- JAAS provider (if authentication facilities are needed)
to Teiid. If any foreign VM can provide these facilities, then Teiid
will be fully operational. Except for the "data sources", which are
very
specific to the sources, every other item in the list can be
supplemented with other available technologies.
Thoughts?
If there are no huge objections, we will soon follow up with
implementation details, JIRAs etc. We would like make these changes
for
7.0 M4.
Ramesh..
On Tue, 2010-04-27 at 09:42 -0400, Ramesh Reddy wrote:
> After the 7.0 M3 release, and based some initial user feed back and
> issues we have seen, we would like to propose change in the how the
> Connector are defined.
>
> Traditionally in Teiid <= 6.2 and in Metamatarix
>
> Connector Binding = Translation Layer + Source Connection
>
> With the JCA changes, "Connector Binding" became the JCA Connector.
> However, in the container a Source is defined with a "Data Source",
> especially for relational sources the equation became
>
> Data Source = Managed Connection = Source Connection
>
> Connector Binding = Translation Layer + Data Source
>
> since the "Data Source" is defined with its own connector (i.e.
-ds.xml
> file) in the container, to support the "Connector Binding" in
container,
> we exposed the "Translation Layer" as another JCA Connector. So,
now
> this became
>
> Connector Binding = JCA Connector + Data Source
>
> But,
>
> JCA Connector = Managed Conection
> Connector Binding = Managed Connection + Managed Connection
>
> Now, this became an issue to have a managed connection over managed
> connection. Teiid does not *really* need the "Managed Connection"
for
> the translation layer, but it *really* needs in the "source
connection",
> so we want propose splitting the "Connector Binding" into two
>
> Translation Layer --> becomes a non-managed connection (not JCA)
> Source Connection --> becomes managed connection (JCA)
>
> This has some pros and cons
> Pros
> 1) Translation layer would be independent of connection layer
> 2) Since translation layer is independent of the environment
changes,
> they are portable and can be included in the VDB to migrate from
one
> environment to another.
> 3) Since the Connection layer is independent of Translation layer
it
> becomes more general purpose JCA connector, that can be used with
other
> applications. With out these changes, this connector was previously
only
> to be used with Teiid. This also paves easier way to handle any type
JCA
> connector.
>
> Cons.
> 1) Only JDBC Connector had two distinct configurations to define
the
> connector before. Going forward Teiid would need to devide the code
in
> all the Connectors between the translation layer and connection
layer
> and package as such. One as the regular jar file and as the JCA
> connector.
> 2) Two separate configuration files to define the layers
> 3) Dependent jar management for the translation layer.
> 4)
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/teiid-dev
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev