Introduction
Teiid Designer begs for additional Usability enhancements.
One enhancement that was validated back in the old MMX days was the Web Service Advisor concept used in the Dimension Product.
Though the product focus itself was not successfull, the WS Advisor view itself and how it improved the design focus for a user was real. This view worked because it focused on managing a concrete step-wise process for defining a set of finite models into a VDB artifact. There was only ONE VDB which limited the design scope to something managable AND meaningful.
This view combined elements of

a finite stepped process

validation status of each step

applicable action sets

quick access to applicable cheat-sheets

=================================
Now what? .....
In order for an "Advisor" concept to be doable, there probably needs to be one or more a "finite stepped processes" that can be encapusulated.
The Advisor needs to be able to track a process (scope) from start to finish including all artifacts as well as properly assessing progress and status when re-selected or Designer is restarted.
Possible "scopes"?

VDB-centric approach

Could create a workspace "folder" who's contents is targeted for a VDB?

Already to this at the "project" level for the "Preview Data" feature

Users could have multiple VDB's defined in a project

= = = = = = = = = = = = = = = = = =
Project Scope

This scope allows users to select a specific project and determine the status of the various artifacts within the project

Project may have a "focus", be it Web Services or Data Acces or whatever, which may provide additional categories of status

If XML or Web Services focused, maybe a status category of "XML Schema" would be visible? (see below)

Users can switch between the "Project" they wish to monitor

Status Entries/Categories

Validation

Actions:

Open Problems View

Data Sources (Connection Profiles)?

Actions:

Launch Create Connection Profile Wizard

Maybe Create JDBC Connection

Create Other ....

Dialog to list source connections detected in Source models?

Create Data Source wizard (deploy to Teiid)

Source Models

Actions:

Create via Import (one or more tables, procedures, indexes)

Create new empty Source Model (copy from existing or empty) NEW MODEL WIZARD

Create source table (new Base Table... Wizard)

Create source function

Find table or procedure

Messages

Warnings for empty model, tables with no children, basic relational problem markers

Could add validation for tables with too many columns, or LARGE model detection

XML Schema

Optional based on project focus. if NO WS or XML, then probably not show this category

Actions:

Import into workspace (launch import wizard)

View Models (Business views?)

Actions:

Create view model from source model

Create new empty model

Create new table

Create new procedure

Create REST procedures for view table

Create new View

Messages

Warnings for empty model, tables with no children, basic relational problem markers

VDBs

Create VDB

Edit VDB - user queried to select VDB

Deploy VDB - user queried to select VDB

Execute VDB - user queried to select VDB

Create Teiid data source

Test

Execute VDB (user queried to select VDB)

Query table or procedure

user queried to select table or procedure

Then Preview Data action executed

= = = = = = = = = = = = = = = = = =
WS SOAP WAR Scope (Produce a SOAP Web Service)
This scope allows the user to create web service models, VDB, and JBossWS-CXF WAR.

Since this scope is targeted at a WAR containing a VDB JNDI NAME, then maybe a SOAP WAR Config file should be managed? Can you expand on this please?

VDB would have to be named and created prior to selecting or as part of setting this Scope?? No

So if I create a VDB (see step below) and name it something, how does this "SCOPE" know that a particular VDB is for THIS scope?

i.e. multiple VDB's in my workspace and/or project?

Seems I need to persist some State for "Scope"

This could be done via an AdvisorScope interface and object. Maybe just a set/map of properties

DEPLOYED = FALSE

VDB NAME = /project/folder/myVDB.vdb

etc....

Status Entries/Categories

Validation

Actions:

Open Problems View

Scope-specific validation?

NO VDB = ERROR

Requires a VDB source

Specifed source is not a VDB Source... need to identify this

Produce SOAP Web Services

Actions:

Create Web Service Models from WSDL

Create empty Web Service Model

VDB

Actions:

Create VDB (if not required to select this scope??)

Edit VDB - user queried to select VDB

Deploy VDB - user queried to select VDB

Execute VDB - user queried to select VDB

Create Teiid data source (To VDB)

WAR

Generate WAR

Deploy WAR (Mark as deployable from workspace)

Test

Execute VDB (user queried to select VDB)

Query table or procedure

user queried to select table or procedure

Then Preview Data action executed

= = = = = = = = = = = = = = = = = =
WS REST WAR Scope (Produce a REST Web Service)
This scope allows the user to create virtual procedures and map to REST operations/URIs, VDB, and RESTEasy WAR.

Status Entries/Categories

Validation

Actions:

Open Problems View

Scope-specific validation?

NO VDB = ERROR

Requires a VDB source

Specifed source is not a VDB Source... need to identify this

Produce REST Web Services

Actions:

Create virtual table with CRUD transformations (or whatever level of CRUD is required for support)

Create REST procedures from virtual tables

VDB

Actions:

Create VDB (if not required to select this scope??)

Edit VDB - user queried to select VDB

Deploy VDB - user queried to select VDB

Execute VDB - user queried to select VDB

Create Teiid data source

WAR

Generate WAR

Deploy WAR (Mark as deployable from workspace)

Test

Execute VDB (user queried to select VDB)

Query table or procedure

user queried to select table or procedure

Then Preview Data action executed

= = = = = = = = = = = = = = = = = =
WS SOAP VDB Scope (Consume a SOAP Web Service)
This scope allows the user to create .....

Status Entries/Categories

Validation

Actions:

Open Problems View

Scope-specific validation?

NO VDB = ERROR

WSDL Definition

Actions:

Create Web Service Data File (WSDF)

This file will contain:

the WSDL URL/SOAP Endpoint

Operations the user wishes to expose (doesn't have to be all of them)

Request/Response sample documents (where applicable)

Create or Select SOAP datasource

Source and View Models

Actions:

Generate create and extract procedures

Select WSDF

Based on the contents of the WSDF:

we create relational model with procedures (create/extract)

generate SQL

we create a procedure using the create/extract

generate SQL

VDB

Actions:

Create VDB (if not required to select this scope??)

Edit VDB - user queried to select VDB

Deploy VDB - user queried to select VDB

Execute VDB - user queried to select VDB

Test

Execute VDB (user queried to select VDB)

Query table or procedure

user queried to select table or procedure

Then Preview Data action executed

= = = = = = = = = = = = = = = = = =
WS REST VDB Scope (Consume a REST Web Service)
This scope allows the user to create .....

Status Entries/Categories

Validation

Actions:

Open Problems View

Scope-specific validation?

NO VDB = ERROR

WSDL Definition

Actions:

Create Web Service Data File (WSDF)

Will require

REST URL

BINDING -> HTTP or HTTPS

Methods (can have more than 1)

HTTP Method -> GET/PUT/POST/DELETE

Parameters (can have any combination of the following)

URI (/path/{var1}/{var2})

Query parameters (?var1=value&var2=value)

XML Document (user needs to provide a sample request/response)

JSON Document (user needs to provide a sample request/response)

OR user provides schema

User choose/selects xsd elements to set as elements/attributes in the transformation.

User provides sample Response document

Create or Select NON-SOAP datasource

Source and View Models

Actions:

Generate create and extract procedures

Select WSDF

Based on the contents of the WSDF:

we create relational source model with invoke or invokeHttp procedures. Invoke should work in most cases unless the response document is something other than XML (i.e. JSON).

we create relational virtual procedure to execute the invoke/invokeHttp procedure using the values from the WSDF. One procedure per method using the values defined for parameters.

optionally we could generate a virtual table on top of this procedure OR just generate the procedure transformation as part of the transformation for a virtual table, thus cutting out the need for the procedure altogether.

VDB

Actions:

Create VDB (if not required to select this scope??)

Edit VDB - user queried to select VDB

Deploy VDB - user queried to select VDB

Execute VDB - user queried to select VDB

Test

Execute VDB (user queried to select VDB)

Query table or procedure

user queried to select table or procedure

Then Preview Data action executed

= = = = = = = = = = = = = = = = = =
Model Extensions Scope ??
= = = = = = = = = = = = = = = = = =
Single-source/Single view Scope ??
Goal would be to have a streamlined approach to defining a source, wrapping it in a view (through joins?) and creating a VDB. This would be our simplist use-case.
= = = = = = = = = = = = = = = = = =
XXX Scope ??
List of Designer Stepped Processes?

Create VDB for simple data access

Create source connection profiles

Import from sources to create relational models

Random Thoughts
What if we treat a "project" as having "aspects". If a user wants to tag a project as "Data Access"...
Would it be beneficial to have a summary somewhere on a project that gives you lists of:

25 Source Tables and Procedures

72 View tables and procedures

15 Web service operations

etc...

Maybe quick access to lists of these objects and be able to dive down and view/edit them?

Source models (relational in particular) seem to make sense. Models are created to correspond with particular DB schema
View Models, however... who really cares that you have multiple view models? Could "view" tables sort of exist and be managed in a different way?
I know the Financials example project has layers and layers of view models. The VDB, I think, is LARGE.
Seems like a user would also want to create a VDB with only the necessary/target sources and views? Say someone create a view model containing a t-form to a couple of other View tables. If these "view tables" were LARGE, then the resulting VDB could contain LOTS of view and source tables that user really didn't need and didn't want but had to have because we index ALL model objects in a VDB.