8:42 a.m.
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)
8:32 a.m.
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
5351
days inactive
5352
days old
1 comments
1 participants
participants (1)
-
Ramesh Reddy