13239Re: Business cases for REST
- Aug 28, 2009[oops, sorry, missed this while i was on vacation - Mark]
--- In firstname.lastname@example.org, Justin Cormack <justin@...> wrote:
> I am trying to collect business rather than technical cases for REST/
> resource oriented rather than "service oriented" architectures. If
> anyone has anything I would be interested. I started writing some
> thoughts at the link below, as a first pass based on some recent
Tracking SOA along a technical pathway gleans an interesting difference. The business advantage of ROA can be likened to other information systems that thrive due to transparency.
SOA services should be used to model service-to-service interactions (read: opaque services interacting). For example, ship this package for me to her. The package only needs to be inspect-able up to the point that the service is responsible. In this example, the shipper needs only provide the shipping service transparency into the weight, addressing, legality of the contents (stretch case area), yada yada.
Within the services that spawned SOA, most interactions were one-way messages. The SLA is simple. The service provider must acknowledge (or non-acknowledge) receipt (ownership of delivery). The service provider should also provide a means for the shipper to receive (or check up on (poll)) the final acknowledgement (or any non-acknowledgement along the path). Every service within the chain follows the SLA (or the calling service compensates to ensure they meet their SLA).
The shipping example can provide good insight into where ROA would have provided the optimal transparency from the start. (And conversely where SOA opaqueness leads to much re-negotiation.)
After the shipper ships the package, they get antsy, they want to track status all along the shipment path. A reply of "That's not our SLA!" is not very service-oriented (albeit technically correct).
Within SOA, the SLA is re-negotiated and all services within the chain go through this same re-negotiation. The services introduce storing of acknowledgments. And a storage invalidation scheme is introduced (wouldn't want to keep acknowledgments that no one will ask for). As a sidenote (from the SOA perspective), each service models the acknowledgment for transmission up chain(s) as well as down chain(s) and for storage.
The storing and representation of acknowledgments pretty well models the world without computers shipping scenario. That is how information flowed. And it is also very resource oriented. It is how a ROA service would be designed from the start.
We must think both in terms of resources and services. We are here to fulfill our clients' expectations (read: get paid). And we are here to be well served.
ROA services model requester -> resource action(s) including potentially triggered actions. The modeling actions within ROA is HATEOS. Through a reduction of verbs and a plethora of resources, the modeling of actions is transparent to consumers of the service as well as the implementers of the service.
Contract negotiation, being a necessary evil, cannot be avoided. ROA services are generally modeled and can be propped up (or mocked) quickly. By focusing on the resources, risk can be reduced by constructing the "edge cases" resources. This can be done in SOA, but most SOA developers do not understand their tools to that level or do not understand that in the end they are constructing a resource.
- << Previous post in topic