Re: [teiid-designer-dev] Connection Factories

On Apr 7, 2010, at 2:55 PM, Barry Lafond wrote: Let me point out that all of Barry's references to "server" refer to a Teiid instance, not the application server (JBoss AS/EAP, etc.). To help clarify Barry's statement, and to answer a few responses, I'll layout our current plans a little better. First, keep in mind Teiid has modified the configuration format and content within a VDB such that no connector or connection factory definitions (what we previously called connector types/component types and connector/connector bindings, respectively) are stored within the VDB. That means things like the URL and user name of the sources to which physical models will connect are not carried forward within the VDB. In addition, the ability to create new connectors (again, what we used to call connector/component types) from the Designer will no longer be supported; that ability will be provided instead via new connector development tooling (a CDK replacement). The only connection-related information that will remain is a binding from each model in the VDB to a "logical" connection name that can be mapped to any real connection factory by an administrator when the VDB is actually deployed. The idea here is to transform VDBs into more portable artifacts that can be moved from one environment to another without modification. In the development environment, we still want the modeler to have a "sandbox" or "default" Teiid available to do things like previewing data and testing VDB deployment/querying; this is inline with functionality available in previous MetaMatrix Designer products that was available via an embedded Teiid. To ensure the user experience for the modeler remains as straight-forward as possible, we'll be automating a few things, for instance, ensuring that preview remains pretty much a one-click operation and attempting to automatically map models to connectors on the default Teiid (using information when available for imported physical models) to remove the modeler's concern for the aforementioned logical connection name. We are planning to have a Teiid view within the Designer that replaces the previous Connector, Connector Binding, and Source Binding views (I might have some of the old names wrong here), and that allows a user to: See which Teiid instances are currently configured and available for use regarding VDB deployment, preview, and binding between models and connectors (via connection factories). Note, the first Teiid configured will act as the "default" in this regard, but we will still allow the user to pick a different Teiid to act as the default. Also note, in the case of "bundled" offerings such as the JBDS product, a Teiid instance will be automatically configured and set as the default without any user interaction. See which connectors, connection factories, and VDBs are currently deployed on each Teiid instance, using any of those artifact types as focal points to categorize the view. "Go into" or "pivot" the view to focus on particular types of entities shown within this view, such as drilling into a particular connector to filter out all information expect which connection factories and VDBs/models are tied to that connector, or pivoting the view such that the VDBs are the top-level entry in the tree. What we've been discussing NOT providing in this view, which I believe is primarily the point Barry was bringing to light in his initial post, is the ability to create connection factories arbitrarily without being tied initially to a particular model (or models). The creation of connection factories will now be a task performed by the user within the context of building a VDB. The motivation behind not managing connection factories and their properties from this view has nothing to do with not having an embedded Teiid available, but rather is driven by the realization that connection and "binding" management is always intrinsically tied to the particular models that will be deployed within VDBs, and that changes to connection factory properties do not get persisted within the VDB and therefore only apply to the local environment. We are instead relying upon JOPR/JON for this type of management, which is always available via a browser for any configured Teiid instance, and may even end up as another plug-in within JBT/JBDS. In other words, we're saying management of particular properties for a connection (especially anything beyond the standard URL, user name, and password) are concerns for a Teiid administrator, and not a modeler. For every physical model added to a VDB, we will attempt to automatically create a connection factory that ties the model to an appropriate connector on the default Teiid using import information. If a match cannot be determined or import information doesn't exist (such as for manually created models), the user will be required to select a connector from the default Teiid and enter required connection properties (URL, user name, password) from within the VDB editor, at which point a connection factory will be automatically created on the default Teiid. All of this remains very similar to the user experience in previous MetaMatrix Designer versions. Management of connection factories will be completely automated, such that when a model is deleted from both all VDBs and the workspace, its corresponding connector factory on the default Teiid will also be deleted. So, let me demonstrate a Designer user experience to bring this all home: User starts Eclipse (possibly meaning starting JBT or JBDS) User creates/imports/edits both physical and virtual models using design-time features within Designer. User previews a model via a model's context menu (Note, the sub-steps below assume preview is setup lazily, as opposed to when a model is first created; performance will probably determine which way we go with this). If this is the first time the user has previewed anything after installing Designer AND has not previously setup a connection to a Teiid instance AND a Teiid instance wasn't bundled with Designer (such as with JBDS), the user will be prompted for the necessary information to connect to a Teiid instance. For all physical models involved (either the physical model being previewed or dependent physical models of a virtual model being previewed), if the model was manually created or an appropriate connector on the default Teiid could not be determined based upon import information, the user will be prompted to choose an available connector from the default Teiid along with connection information (URL, etc.). Assuming our attempt at auto-matching might be incorrect, I would envision a dialog always being shown with the connector/connection information that includes a checkbox to not show it again in the future (the user could, of course, force it to show up again via some other context menu option). A connection factory will be automatically created under-the-covers and preview data will be retrieved using a preview-specific Teiid client API and finally presented to the user. User creates a VDB and adds some of the models in the workspace to it. The connection factory name created for preview for physical models (which will match the model's name) will be migrated to the VDB. Only if a connector factory has not been created for preview purposes will the user be required to provide appropriate connector/connection information. If this information is provided for the first time via the VDB editor, I would expect we'd also automatically setup that model for preview (assuming preview setup is done lazily). The user will always be allowed to modify the connector/connection information for a given model. If a model is marked as multi-source, the user should be able to create multiple connection factories. The user experience for this case is still TBD. User deploys the model via a context menu option. There are certainly other options we can provide that allow the user more flexibility regarding to which Teiid instance we deploy VDBs, and therefore which connectors are used, but these will also necessarily require much greater interaction from the user. Thanks, JPAV