A traditional SOA platform is composed of individual web services. All the the flow of interaction scenarios of web services are designed from client to web services. Let me draw the architectural concepts basically.
All right, but; if this is an accessible application, there is something odd we have missed. What if we have to notify our clients, to update a critical information? Some naive argument goes like this: "We recommend you, to invoke our "getX" method in a short period of time". This offer needs to be more clear and certain.
First of all, "recommend" is not indicating how crucial activity is, even if it is not an essential part of product. Also, "short period of time" is so ambigious term that can probably cause failures of users on run-time.
There is a need for applying Observer-Observable pattern between UI and web-services. The distinction between UI and web services makes use of observer-observable pattern simple impossible. Thus, a new candidate solution to be adopted in a SOA manner. I draw the below figure to indicate how to notify UI. The notification goes from webservice to UI with invoking a simple method of another web service on client(UI).
By doing this, responsibility of action is taken from UI developers to web service developers (also responsible of business logic). Additionally, the questions of "WHY to show" and "WHEN to show" is gone away for UI developers.
I inspired from model in Ivar Jacobson's book [Object-oriented software engineering: a use case driven approach]. The architecture that is about boundry interfaces between UI and Controllers.
Now everybody can be more happy but things are not so easy. Client must register to be notified and web service must manage the registrants' status. Also, the notification messages format and the actions to be taken for individual message must be defined, well.
Other questions come to my mind: How many service should be observable, how many services can be observed? I haven' t google' d for this so far, if i found i will be posted here, literally.
Thx for reading
 |
| Basic UI - WS interaction scenario: blue part on UI indicates client stub codes to call WS |
All right, but; if this is an accessible application, there is something odd we have missed. What if we have to notify our clients, to update a critical information? Some naive argument goes like this: "We recommend you, to invoke our "getX" method in a short period of time". This offer needs to be more clear and certain.
First of all, "recommend" is not indicating how crucial activity is, even if it is not an essential part of product. Also, "short period of time" is so ambigious term that can probably cause failures of users on run-time.
 |
| Adding the observer web service that has single one-way method to listen changes on domain |
There is a need for applying Observer-Observable pattern between UI and web-services. The distinction between UI and web services makes use of observer-observable pattern simple impossible. Thus, a new candidate solution to be adopted in a SOA manner. I draw the below figure to indicate how to notify UI. The notification goes from webservice to UI with invoking a simple method of another web service on client(UI).
By doing this, responsibility of action is taken from UI developers to web service developers (also responsible of business logic). Additionally, the questions of "WHY to show" and "WHEN to show" is gone away for UI developers.
I inspired from model in Ivar Jacobson's book [Object-oriented software engineering: a use case driven approach]. The architecture that is about boundry interfaces between UI and Controllers.
Now everybody can be more happy but things are not so easy. Client must register to be notified and web service must manage the registrants' status. Also, the notification messages format and the actions to be taken for individual message must be defined, well.
Other questions come to my mind: How many service should be observable, how many services can be observed? I haven' t google' d for this so far, if i found i will be posted here, literally.
Thx for reading
No comments:
Post a Comment