1:24 p.m.
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
1:40 p.m.
New subject: Proposal to further refine the JCA Connectors
On Thu, 2010-04-29 at 14:24 -0400, John Doyle wrote:
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,
We define the "translator-api" aka "connector-api".
We do not define the
semantics of the connections . Either they are defined already like
javax.sql.DataSource or defined by the user.
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.
We are finally separating the concerns, into their areas. yes, you are
right. If there is JCA connector, Teiid would require them to just write
the translator and use the JCA connector. If there is a translator
defined already that understands the connection interaction then they
could use that.
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.
This is
simplest case; I will look it up.
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?
Yes, the developer should be free in defining
the connection semantics,
however then he/she needs to have translator that understands it. By
default, we could still provide current connection semantics that we
already have if somebody wants to use them.
for XML connectors, we are seeking out help from JBoss Web services team
on the connection semantics, so that we can re-use any work they may
have.
Also, as part of the embedded Teiid for Designer which results from this change,
This is entirely separate discussion. The decision to use "embedded" or
server is still pending upon discussion. however I will try to answer
your questions in separate email.
Ramesh..
3:37 p.m.
New subject: Proposal to further refine the JCA Connectors
Thanks for the explanations, I think I'm good with this.
I think we should offering our current connection semantics would be valuable.
~jd
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
On Thu, 2010-04-29 at 14:24 -0400, John Doyle wrote:
> 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,
We define the "translator-api" aka "connector-api". We do not define
the
semantics of the connections . Either they are defined already like
javax.sql.DataSource or defined by the user.
> 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.
We are finally separating the concerns, into their areas. yes, you
are
right. If there is JCA connector, Teiid would require them to just
write
the translator and use the JCA connector. If there is a translator
defined already that understands the connection interaction then they
could use that.
> 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.
This is simplest case; I will look it up.
> 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?
Yes, the developer should be free in defining the connection
semantics,
however then he/she needs to have translator that understands it. By
default, we could still provide current connection semantics that we
already have if somebody wants to use them.
for XML connectors, we are seeking out help from JBoss Web services
team
on the connection semantics, so that we can re-use any work they may
have.
>
> Also, as part of the embedded Teiid for Designer which results from
this change,
This is entirely separate discussion. The decision to use "embedded"
or
server is still pending upon discussion. however I will try to answer
your questions in separate email.
Ramesh..
2:01 p.m.
New subject: Proposal to further refine the JCA Connectors
On Thu, 2010-04-29 at 14:24 -0400, John Doyle wrote:
as part of the embedded Teiid for Designer which results from this
change,
No, this assumption is wrong. Designer can keep going on the same path
as today, the only thing will change in this case is to designer to
support the both layers. Designer team was already doing the similar
technique for JDBC connectors from the earlier design, now, with this
change it will apply to all the sources.
its been proposed to me that we use DTP as the infrastructure to
create and manage connections to sources for metadata and embedded
execution.
The proposal is, if we want the user experience is to be consistent
across different sources and different tools inside JBDS, we need to
look toward DTP for connection management. If this not possible, then we
need to see if we can expose a "import API" in the Teiid, so that user
is only going to one place to create any connection for importing and
previewing. Right now what we have DTP for JDBC sources, Custom for some
(SF, XML) and may be none (TEXT, LDAP) etc.
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.
Based on the conversation, we share the same view.
The benefits are more
compared to the drawbacks. Yes, you are right about the connectivity
plugin. The thought process for custom connector is user already knows
how to connect to the underlying source. May be he uses JCA on one side,
something else in the Designer. However if the user only has JCA way to
connect to the source then he/she will be out of luck in the embedded
scenario. Yes, this constitutes lot of work.
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
If we pursue this route, we could
provide canned framework to develop a
DTP plugin. You are correct in terms of limitations, may be they can be
just happy in providing the text based data for previewing, and can do
the real testing on the server. For example, XML connetion can use just
a TEXT file in Designer for preview and use a SOAP call in the server.
This offers us flexibly in switching connections.
Good questions, keep em coming.
Ramesh..
2:07 p.m.
New subject: Embedded Vs Server in the Designer
just changing the title of the email from last one..
On Thu, 2010-04-29 at 15:01 -0400, Ramesh Reddy wrote:
On Thu, 2010-04-29 at 14:24 -0400, John Doyle wrote:
> as part of the embedded Teiid for Designer which results from this
> change,
No, this assumption is wrong. Designer can keep going on the same path
as today, the only thing will change in this case is to designer to
support the both layers. Designer team was already doing the similar
technique for JDBC connectors from the earlier design, now, with this
change it will apply to all the sources.
> its been proposed to me that we use DTP as the infrastructure to
> create and manage connections to sources for metadata and embedded
> execution.
The proposal is, if we want the user experience is to be consistent
across different sources and different tools inside JBDS, we need to
look toward DTP for connection management. If this not possible, then we
need to see if we can expose a "import API" in the Teiid, so that user
is only going to one place to create any connection for importing and
previewing. Right now what we have DTP for JDBC sources, Custom for some
(SF, XML) and may be none (TEXT, LDAP) etc.
> 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.
Based on the conversation, we share the same view. The benefits are more
compared to the drawbacks. Yes, you are right about the connectivity
plugin. The thought process for custom connector is user already knows
how to connect to the underlying source. May be he uses JCA on one side,
something else in the Designer. However if the user only has JCA way to
connect to the source then he/she will be out of luck in the embedded
scenario. Yes, this constitutes lot of work.
> 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
If we pursue this route, we could provide canned framework to develop a
DTP plugin. You are correct in terms of limitations, may be they can be
just happy in providing the text based data for previewing, and can do
the real testing on the server. For example, XML connetion can use just
a TEXT file in Designer for preview and use a SOAP call in the server.
This offers us flexibly in switching connections.
Good questions, keep em coming.
Ramesh..
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
3:34 p.m.
New subject: Embedded Vs Server in the Designer
----- "Ramesh Reddy" <rareddy(a)redhat.com> wrote:
just changing the title of the email from last one..
On Thu, 2010-04-29 at 15:01 -0400, Ramesh Reddy wrote:
> On Thu, 2010-04-29 at 14:24 -0400, John Doyle wrote:
> > as part of the embedded Teiid for Designer which results from
this
> > change,
> No, this assumption is wrong. Designer can keep going on the same
path
> as today, the only thing will change in this case is to designer to
> support the both layers. Designer team was already doing the
similar
> technique for JDBC connectors from the earlier design, now, with
this
> change it will apply to all the sources.
I understood part of this proposal to be an alternative to the path designer was taking,
and addressing a lot of the complexities of that approach. Specifically that in this new
path 'preview' of physical and virtual models would be accomplished with an
embedded teiid, and that the user would "Deploy" a VDB to the container to test
a VDB via a DTP connection to Teiid. Do I understanding that your are proposing that
'preview' of models on a remote Teiid also be supported in the tooling?
~jd
2:47 p.m.
New subject: Embedded Vs Server in the Designer
On Thu, 2010-04-29 at 16:34 -0400, John Doyle wrote:
I understood part of this proposal to be an alternative to the path
designer was taking, and addressing a lot of the complexities of that
approach. Specifically that in this new path 'preview' of physical
and virtual models would be accomplished with an embedded teiid, and
that the user would "Deploy" a VDB to the container to test a VDB via
a DTP connection to Teiid. Do I understanding that your are proposing
that 'preview' of models on a remote Teiid also be supported in the
tooling?
As Teiid team, we want to offer solutions either way. The actual
decision to do one way other is still pending AFAIK.
We found yesterday that ESB tooling seems to be dependent upon the
Server being there, which is similar to current Teiid approach. So,
there are pros and cons in both approaches.
Ramesh..
5359
days inactive
5359
days old
6 comments
2 participants
participants (2)
-
John Doyle -
Ramesh Reddy