Team Leader: Jerry Gray (grgray@cmsenergy.com) This technically-oriented team defines integration requirements and service definitions in accordance with the use cases defined by the Use Case Team. This work is to be done in accordance with the presentation/discussion Jerry led during AMI-Ent meeting in New Orleans (refer to file: “AMI-ENT Application Integration - A Framework-1.ppt”).
 | Edited: 9/28/2009 1:23 AM by System Account | | |
|
| | AMI-ENT support for REST Please review the attached document for thoughts on using REST for the development of AMI-ENT artifacts and feel free to add your thoughts to this thread.
| |
| |
| Posted: 9/28/2009 1:23 AM by System Account | |
|
| | I forgot to add, kudos to Shawn Hu for doing the initial research on this topic, I merely edited the document.
| |
| |
| Posted: 9/28/2009 1:23 AM by System Account | |
|
| | Hi Gerald, I don't see the document you mention here, in the shared section, or in your original email?
We are interested in this effort and will be glad to help.
rgds
-john mani
Comverge, Inc.
| |
| |
| Posted: 9/28/2009 1:23 AM by System Account | |
|
| | I am a proponent of REST from a simplicity perspective. However, the lack of WS-Security standards support leaves something to be desired with respect to the security capabilities of REST when compared to SOAP.
SSL probably provides for sufficient protection of the communication channel, but pure REST does not provide for very robust authentication. Most REST security models rely on shared-secret keys, as opposed to a more robust certificate-based authentication mechanism. WS-Security and related standards, on the other hand, provides much more capability in this regard.
Additionally, there are some things, stateful transactions or workflows, branching service invocations, guaranteed message deliveries, and others, that just can't be done well with REST.
If REST is to be considered, the use cases need to be carefully considered for when REST is appropriate and when it is not. | |
| |
|
|
|
|