[teiid-dev] Proposal to further refine the JCA Connectors

[John Doyle]

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 at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/teiid-dev
> 
> 
> _______________________________________________
> teiid-dev mailing list
> teiid-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev