Community
Participate
Working Groups
We made the SQL page better, now we need to make the REST page better. It could have two radio buttons: ( ) Invoke a service at the following URI URI: [ ] ( ) Invoke a service in the workspace Service: [ ] [browse...] URI to use in deployed applications: [ ] This way if you're invoking a third party service, you would always use the first option. And if invoking an EGL service, you would click the browse button to select the service in the workspace. We'd then use the workspace:// URI format under the covers. And when using the second option we'd also let you tell us what the URI will be when deploying, so that you can use the same binding for test and deployment (deployment would need to be updated to look for this new parameter). The wizard would have similar restructuring. So the benefits: 1) User just browses to a service, does not need to know the internal workspace:// syntax 2) Same binding is used by test and production
We really need to address this soon to make the test/deploy story simpler and more consistent with SQL access. And I'm having second thoughts on the UI. How about: Base URI: [ http://foo ] [X] Invoke a service inside the workspace during development Service: [ proj/pkg.service ] [browse...] This makes it easier to toggle between the test server and deployed service (no duplicate URI information).
The doc on service access now focuses on what kinds of details the developer must provide: "how" to interact with the exteral logic, "where" to access the service, and "what more" the EGL tech requires: http://wiki.eclipse.org/EDT:Resource_Binding_Services It's important that we explain details in the simplest, day-to-day way possible. Given recent changes, the proxy function includes one of two annotations for specifying "what more": o EglService (for dedicated or EGL REST-RPC services) o REST (for third-party REST services) The developer might be sophisticated about REST and REST-RPC, but might be sophisticated only about this or that personnel or accounting rule. If the service bindings follow the same pattern as the annotations... o EGL Service o REST ... the instruction to a proxy-function developer would be clear: "pair your service annotation with the equivalent kind of service binding." In a sense, we have three kinds of binding types (two within EGL Service). There are three kinds because each has different restrictions: http://pic.dhe.ibm.com/infocenter/rbdhelp/v8r5m0/topic/com.ibm.egl.pg.doc/topics/pegl_core_rest_service_parameters.html The technology could validate what combination of choices were made for annotations and for settings in the EGL Service binding. In this way, the restrictions are enforced at development time, for ease of use. Proposal: o Do not all-but require most developers to maintain multiple deployment descriptors. That way of working requires an extra level of file management. The practice might work best for some uses, but is not as easy for the non-enterprise developer or for marketing the technology. Let the developer switch between dedicated and EGL REST-RPC in the EGL Service binding. o The checkboxes mentioned earlier would be specified in the EGL Service page. The REST page would only be for third-party REST access. o The EGL DD entry should retain (in comment form) any EGL REST-RPC detail previously provided but not now in use. Is a small amount of detail and would never be included in a deployed output; but the presence would prevent extra typing if the developer goes back and forth between dedicated and EGL REST-RPC. o Consider removing workspace URI. I think the reason for keeping workspace URI is the set of REST-RPC restictions mentioned earlier. Otherwise, why couldn't the developer use a dedicated service before trying out a local Tomcat deployment? In the future, EGL could use two kinds of EGL DD entries to support SOAP: one for EGL and one for third-party. The distinction would not be for validation, but for ease of thought.
