The central conductor service resides at the hub, and clients and partner services are at the spoke ends.Such scalability issues and an architectural approach to addressing it are discussed in my thesis titled RESTful Service Composition. The key idea is to implement a composition in a flow-like structure rather than hub-spoke.
1. The central conductor service needs to support many concurrent orchestration instances and handle more Input/Output (i/o) operations than normal services, which can bring more performance and scalability challenges.
2. The central conductor service is a single point of failure and, therefore, is critical to the reliability of a service composition.
Friday, October 25, 2013
There are a lot of news recently about the healthcare.gov website issues. The terms of hub and service have been used widely to describe the technical nature of the system to general audience like this. It is good that they did not use the more technical term of orchestration. Scalability issues are intrinsic to orchestrations that are realized by a hub-spoke structure.
Tuesday, October 8, 2013
In order to clone or copy a file, we execute a command like
cp a bGiven a file named a, the command creates a new file named b that has the same content as a. Similarly, we can clone a resource A. The client sends the following request to the server.
PUT /resources/BHowever, a client normally does not have the knowledge to properly name a new resource. A more reasonable alternative is the following request.
POST /resourcesAll these are straightforward, but really smell like RPC. They did not follow the REST constraint of self-descriptive message. How could the server figure out /resources/A is what the client wants. What if the resource has been changed or deleted after the request was sent out? The following approach may be better:
POST /resourcesWhat if the representation is huge? Maybe we can do the following:
the representation of /resources/A