As seen in #19 FraSCAti Velocity for Light Proxy, the WSDL to HTML form generator (be it based on XSL or velocity+WSDL Java model) has its limits.
The current form generator supports simple params (primitive types) OK (ex. paf, travel), but not more complex types. They could be supported, but this alone would not be useful : merely having a tree of forms to input complex types won't help the business user, and the dev user probably prefers raw XML/json.
Nuxeo & FraSCAti alternatives
Nuxeo : CMIS "browser binding" is rather about ECM browsing in a browser
20120914 FraSCAti implementation.widget provides a service binding in browser html / js.
Customize HTML UI
Let users edit and customize the generated HTML (see #45 Editable scaffolder HTML & #102 in FraSCAti Studio) and / or the HTML template..
Addressing complex services
Here are alternatives to make it useful to the business user :
Templatized form UI
Let the user edit the HTML form-generating template. In addition, other UI development strategies could be integrated (form editor...).
This should be allowed by #102 integrating Service Scaffolder in FraSCAti Studio. Service Scaffolder has limitations (when service is complex) but they are inherent to the approach.
Simpler service through templatized exchange
Only require the user to input the few fields that really interest him, and "templatize" the remaining xml/json. The original exchange may come
from a previously recorded exchange (done using HTTP monitoring & #73 records),
or if none from the WSDL (ex. by SOAPUI-like example generation).
The request transformation might either be done by :
a content tranformation, edited online an anything-allowed transformation template editor (ex. #102 in FraSCAti Studio). Requires language (ex. XSL for XML) or libraries (java for template engine ex. velocity) allowing to introspect request content. For developers.
a template whose parameters are fields extracted from the request. Can come from automatic suggestions from an "exchange templatizer" (done using #73 correlations between recorded request and response detecting "interesting" fields to templatize like ids and query criteria), or even in an online interactive version of this "exchange templatizer" (ex. where the user could choose a field by inputting a well-known value in his business application and monitoring the service call)
a Talend job, designed in Talend Studio, ran there or wrapped in FraSCAti Studio.
"REST-izing" the service
That's making it "browsable", but also actually breaking it up into multiple services, one for each Resource i.e. business atom, while keeping all of them linked together. This requires knowing the service structure semantics. It can be done by correlating request and response data types, putting the no-parameter operations as roots, and when one service's response (sub)element is another's request, put a link allowing to call the second from the first.
(other end of the spectrum) "mashups" / Light (app) development
Develop an EasySOA Light app with a custom UI and custom code (script) calling services. These service calls could be helped by various tools : FraSCAti binding.html or REST to SOAP proxy, SPoRE client api... There are several "Light" alternatives providing such thing :
Service Scaffolder (templatized form UI) is the simplest
RoR-like rapid web application development integrated with (Easy)SOA Light services is the full scale alternative
TODO Q is there anything in between ? Ideas :
A multiple service scaffolder would be a single UI consuming several injected RESTed services, this UI been coded or generated. If coded, we're coming back to RoR-like web app dev. If generated, it can be generated from an existing service definition (Service Scaffolder again), or from other UI design tools. Such could be integrated with EasySOA, but le's not go that far. So the question becomes : how to make easy defining a simple (primitive parameters) service i.e. a list of fields ? A few ideas among a lot : WSDL design, tabular (excel) field definition, Talend (WSDL design, but what about WSDL generation from a flow ?)...
NB. This feature, along with others, have to be thought about in the whole "SOA on rails" functional perimeter, and among the kind of proxies we're interested for INRIA's FraSCAti proxy factory.
Generating more specific interfaces according to context
CRUD scaffolder UI for CRUD services. That's what do RoR-like web app dev & MDA / RAD. It requires to know the CRUD semantics of services, which can be done ex. correlating among a series of records #73 request-response detected fields.
Other cases ?
modular, "divide and conquer" approach
In a more framed / patterned process, by following a "divide and conquer" approach : develop "simpler" EasySOA Light services, each exposing only a part of the main service it calls, and composing them all again in a single EasySOA Light UI. This is similar to the "scatter / gather" EIP pattern.
It is more of an architectural and methodological approach, allowing to use all of the previous ones (templates, simpler Light services, Light UI). It can be helped by EasySOA by allowing to implement gradually some modular parts in more robust technologies while others stay in Light and still work together.
As seen in #19 FraSCAti Velocity for Light Proxy, the WSDL to HTML form generator (be it based on XSL or velocity+WSDL Java model) has its limits.
The current form generator supports simple params (primitive types) OK (ex. paf, travel), but not more complex types. They could be supported, but this alone would not be useful : merely having a tree of forms to input complex types won't help the business user, and the dev user probably prefers raw XML/json.
Nuxeo & FraSCAti alternatives
Customize HTML UI
Let users edit and customize the generated HTML (see #45 Editable scaffolder HTML & #102 in FraSCAti Studio) and / or the HTML template..
Addressing complex services
Here are alternatives to make it useful to the business user :
Templatized form UI
Let the user edit the HTML form-generating template. In addition, other UI development strategies could be integrated (form editor...).
This should be allowed by #102 integrating Service Scaffolder in FraSCAti Studio. Service Scaffolder has limitations (when service is complex) but they are inherent to the approach.
Simpler service through templatized exchange
Only require the user to input the few fields that really interest him, and "templatize" the remaining xml/json. The original exchange may come
The request transformation might either be done by :
"REST-izing" the service
That's making it "browsable", but also actually breaking it up into multiple services, one for each Resource i.e. business atom, while keeping all of them linked together. This requires knowing the service structure semantics. It can be done by correlating request and response data types, putting the no-parameter operations as roots, and when one service's response (sub)element is another's request, put a link allowing to call the second from the first.
(other end of the spectrum) "mashups" / Light (app) development
Develop an EasySOA Light app with a custom UI and custom code (script) calling services. These service calls could be helped by various tools : FraSCAti binding.html or REST to SOAP proxy, SPoRE client api... There are several "Light" alternatives providing such thing :
TODO Q is there anything in between ? Ideas :
NB. This feature, along with others, have to be thought about in the whole "SOA on rails" functional perimeter, and among the kind of proxies we're interested for INRIA's FraSCAti proxy factory.
Generating more specific interfaces according to context
modular, "divide and conquer" approach
In a more framed / patterned process, by following a "divide and conquer" approach : develop "simpler" EasySOA Light services, each exposing only a part of the main service it calls, and composing them all again in a single EasySOA Light UI. This is similar to the "scatter / gather" EIP pattern.
It is more of an architectural and methodological approach, allowing to use all of the previous ones (templates, simpler Light services, Light UI). It can be helped by EasySOA by allowing to implement gradually some modular parts in more robust technologies while others stay in Light and still work together.