CODEWITHSUNDEEP
asp.netperformanceweb-servicesiis-7.5
AykutCanturk
AykutCanturk

Reputation: 101

use webservice in same project or handle it with code?

This is a theoretical question.

imagine an aspnet website. by clicking a button site sends mail.now:

none of above solutions wait for mail operation to be completed.so they are fine.

my question is why I should use service solution instead of other solutions. is there an advantage ?

4th solution adds additional tcpip traffic to use service its not efficient right ?

if so, using service under same web site (3rd solution) also generates additional traffic. is that correct ?

I need to understand why people using services under same website ? Is there any reason besides make something available to ajax calls ?

any information would be great. I really need to get opinions. best

Upvotes: 0

Views: 33

Answers (1)

HashPsi
HashPsi

Reputation: 1391

The most appropriate architecture will depend on several factors:

  1. the volume of emails that needs to be sent

  2. the need to reuse the email sending capability beyond the use case described

  3. the simplicity of implementation, deployment, and maintenance of the code

Separating out the sending of emails in a service either in the same or another web application will make it available to other applications and from client side code. It also adds some complexity to the code calling the service as it will need to deal with the case when the service is not available and handle errors that may occur when placing the call.

Using a separate web application for the service is useful if the volume of emails sent is really large as it allows to offload the work to one or servers if needed. Given the use case given (user clicks on a button), this seems rather unlikely, unless the web site will have really large traffic. Creating a separate web application adds significant development, deployment and maintenance work, initially and over time.

Unless the volume of emails to be sent is really large (millions per day) or there is a need to reuse the email capability in other systems, creating the email sending function within the same web application (first two options listed in the question) is almost certainly the best way to go. It will result in the least amount of initial work, is easy to deploy, and (perhaps most importantly) will be the easiest to maintain.

An important concern to pay significant attention to when implementing an email sending function is the issue of robustness. Robustness can be achieved with any of the possible architectures and is somewhat of an different concern as the one emphasized by the question. However, it is important to consider the proper course of action needed if (1) the receiving SMTP refuses the take the message (e.g., mailbox full; non-existent account; rejection as spam) and (2) an NDR is generated after the message is sent (e.g., rejection as spam). Depending on the kind of email sent, it may be OK to ignore these errors or some corrective action may be needed (e.g., retry sending, alert the user at the origination of the emails, ...)

Upvotes: 2

Related Questions