Address the problem where for example the desired image classification application:
((actor)) --instruct0--> (camera) --instruct1--> (ML)
^ |
| |
+--------------------instruct2-----------------+
where:
instruct0 = "take image, classify and return the class to me"
instruct1 = "classify image and return the class to ((actor))"
instruct2 = "interpret the class"
and descriptions are:
camera: function() -> image_buffer
ML: function(image_buffer) -> classification
in its current implementation is more accurately depicted as:
((actor)) -------instruct0-------> (camera) --instruct1---> (ML)
^ |
| |
+---rev(instruct0)&instruct2-- (camera) <--rev(instruct1)-+
where:
instruct0 = "take image, classify and return the class to me"
instruct1 = "classify image and return the class to me"
instruct2 = "interpret the class"
and descriptions are (still):
camera: function() -> image_buffer
ML: function(image_buffer) -> classification
where rev means "reverse" or handling the response (which causes the blocking and complexity with services' interfaces).
This strategy could probably be used for building the "composite service" from ((camera)) and ((ML))but then the services can not be individually described by their interfaces, or at least I think this creates unnecessary complexity (e.g., camera effectively becomes function() -> classification).
Address the problem where for example the desired image classification application:
in its current implementation is more accurately depicted as:
where
rev
means "reverse" or handling the response (which causes the blocking and complexity with services' interfaces).This strategy could probably be used for building the "composite service" from
((camera))
and((ML))
but then the services can not be individually described by their interfaces, or at least I think this creates unnecessary complexity (e.g.,camera
effectively becomesfunction() -> classification
).