• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to justify QoS when integrating with external systems

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

In my assignment, one NFR is that all messages should be constructed and sent to the IP address of the API server in a specified amount of time.

I understand that when integrating with external systems, SLAs will be set. But how can one justify through architecture that these SLAs are met? Moreover, when SuD is sending messages to external system how can we depict that this NFR can be met.

I hope I am violating forum rules by asking this question.

Thanks
 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Always we assume that all the External Systems will meet SLAs

all messages should be constructed and sent to the IP address of the API server in a specified amount of time
Separate into two parts
1. Message construction at your application
2. Sending the message to external system

Message construction at your application
How your architecture supports the construction of a message within SLAs
Example:
You need some data from database, the same can be achieved by caching the data and retrieving from it.
If there is any design pattern helps to improve the performance
Based on Sud requirement using asynchronous queues for constructing the message
Because of Clustered environment: meeting the SLAs criteria as load increases

External Systems
Example
Based on Sud requirement if possible you can define asynchronous communication with external systems and you are not holding your application resources for response. Incase external system is slow in processing the request it will not impact your application if it is asynchronous (depends Sud requirements)
 
Shruti Verma
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Murali,

Dividing the QoS into 2 separate requirements really made the picture very clear for me. Thanks for your very helpful input!

Thanks.
 
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

one NFR is that all messages should be constructed and sent to the IP address of the API server in a specified amount of time.



I'm a bit confused: This requirements means the SuD has to be able to send a message within a specified amount of time. This does not have anything to do with the performance of external systems.

With respect to the external systems, I think a safer approach is to assume that there are no SLAs on them in general. This is often true, as well. If the SuD needs to complete a certain job (i.e. process a request) within a certain amount of time, and the job includes calling an external system, then this is typically solved by calling the external system asynchronously, i.e. not to wait for the response of the external system. You can then just respond (in time always) that the request is being processed, or something like that.

Cheers,

Paul
 
I don't get it. A whale wearing overalls? How does that even work? It's like a tiny ad wearing overalls.
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic