05/09/08 :: [REST] Answer to My Open Letter [permalink]
Stefan and Subbu have kindly offered to help me understand how REST can be used to manage the lifecycle of resources. So let's go back to where we were last November and if it is ok with you, here is the example that we could pick (I don't think there is anything particular to this example, and if you'd like you could pick any other one).
This is the beginning of a job application lifecycle. We could focus on implementing the "RejectApplication" operation, i.e. the Job Application Resource transitions from a "submitted" state to an end state (Rejected).
Please note that the red boxes represent some code that would typically invoke the DAL as part of the action implementation. The blue rounded boxes represent states, typically a message event would be sent upon reaching a particular state. But unless you insist, let's forget about events for now. Let's keep it simple.
The trick in this scenario is that once the application has been rejected, the Job Application resource cannot accept any other state changes. Its lifecycle has ended. That would be interesting to show how that can happen based on the implementation that you choose (a, b or c as explained in my previous post).
Ideally, I would like to see both some "client code" and some "service code" (if any). You can pick any programming language -of course. Let's assume that the client is another service -an automated service- that was notified by an ApplicationSubmittedEvent (not represented on the picture) and that service is capable of processing automatically the application to decide to reject the application or not. Upon rejection, the decision service invokes the RejectApplication operation, otherwise, the job application simply waits for interviewers to submit their interviews. In the past, we used to process these applications manually, but James Taylor taught us how we could use a decision service instead, so it's all automated now. SOA really worked for us because we did not have to change a thing on the Job Application Service to make that transition.
Now, I am a lousy analyst and we realized once all this is in production that we can't give a clear status of the application until an interview is submitted (a rejection could still potentially come). What we should have done is to have the decision service tell us also whether the application has passed its criteria. So now, I need to add a new action "AcceptApplication" to my Job Application Service. Could you please explain how this change of the service impacts the "client", i.e. the Job Application Decision Service:
The statelessness constraint isolates the client against changes on the server as it is not dependent on talking to the same server in two consecutive requests.
So to sum up, if you could show me:
a) how to write some client code and potentially some service code that result in transitioning (in a RESTful way) the Job Application resource into a rejected state
b) how once the lifecycle has ended, no further changes can be made to the resource
c) how can I add an operation on the job application service and demonstrate that the decision service client is isolated from this change
I'd be infinitely grateful (and apologetic for all the trouble that I have caused).
Of course, my favorite implementation for the Job Application Service would be to use an SCA composite with a BPEL component to manage the lifecycle, wired to some Java components that implement the resource's DAL. If you allow me, I will publish that Sample code too.