1) Are you just exposing the ODBC API into REST API or using the Teiid for any data integration across dB1, dB2 and dB3?
2) When you say REST API, are you thinking custom REST API or are you open to standards like OData V4?
3) The REST API layer between Teiid and ESB does not make sense to me architecture wise, why exposing as REST then have business layer expose another REST layer. Teiid is already providing an abstraction layer.
- Is Teiid the right solution?
Yes, for data layer abstraction, But it does make more sense if you also using or considering the data integration across the data sources too. Although Teiid has weak support for ODBC API for consumption, upto JDK8 Teiid used JDBC-ODBC bridge, but that is no longer available so some other solutions need to be adopted. Teiid has great integration capabilities over the JDBC layers if that is acceptable.
- Is Teiid able to implement Data Access Policies?
yes, look for Data Roles in Teiid documentation. You can define the access policies and tie them to enterprise roles to manage the access.
- Could Teiid be defined as a software solution?
I want to say yes, but would like to understand more about your thoughts behind the question.
- Could Teiid run on a dedicated server with ESB or should it be used on a separated one?
yes, but it up to your deployment architecture. Teiid even has embedded version if you are willing to put in work to develop as one of the components in your ESB for transformation so that they are in single VM.
- If so, could you please give some hints in order to make Teidd fully operative on a Server (Installation and so on)? I am not sure about how to.
I suggest you start here Teiid Quick Starts - Teiid Examples - Project Documentation Editor look through the installation and Hello World example to understand some basics of Teiid and its nomenclature.
Thank you for your answer!
- Yes the idea is to use Teiid for any data integration across dB1, dB2 and dB3.
- I am talking about generic REST APIs, so yes I am open to standards like OData V4.
- Well the idea is to put ESB, Data Virtualization and Business Logic on 3 separated Servers so REST APIs between ESB/Business Logic and Business Logic/Data Virtualization are required in my point of view. But I am interested in what you say too: do you think only one REST API is enough to let an Application Server (with business logic) communicate either with ESB and Data Virtualization Layer (Teiid) even if we are talking about 3 phisically different servers? Did I get your observation?
Just another question: are there any kind of limitations in using Teiid Open Source solution instead of a fee-paying one? Are there license limitations?
On (3) it is about performance and amount of work it takes to build those REST interfaces both on client and server sides. Also, it about who is accessing your API, if your Data Virtualization's client at any given day is Business Logic, then there is only a single client. Personally, I like to see REST API abstractions at edge points not in between especially at lower layers like at data access (if possible). OData V4 does give you this access without any coding but imposes a certain structure and queries to use like SQL, but it can't be customized. JDBC gives you the most flexibility, if you can't use that, then OData is what I would suggest.
As per Open Source version vs paid one, there are no license restrictions on the Open Source one. If you use RedHat Data Virtualization product then that is restricted to development purposes only. What the fee-based one buys is support from RedHat, security and timely bug fixes and SLAs. So, it depends on what you are trying to use and how critical your application is. Open Source one gets only community support like these forums when a community member has time to answer, and the development is fast-paced (a release every 2 months) and we do not provide any bug fixes for any release older then n-1.