I am having a ASP.net web application which is hosted in an internet server. Now i got a requirement to integrate this website with a computer telephony infrastructure. The details are as follows.
The user will be located in a building having TAPI standard, LAN – CTE infrastructure enabled telephone system and the logged-in user should be able to connect to the phone line (extension no:) within the same building through the browser. When a call comes to that phone line, a popup should appear in the users browser displaying the number of the caller. I am having the following doubts in implementation of this functionality
How should I connect (communicate) my application with this LAN – CTE infrastructure? The LAN – CTE infrastructre is simply an API having no web services exposed from their side for this purpose. So think I will have to write an extra wrapper class just above the LAN – CTE infrastructure to facilitate this. Please have your thoughts and suggestion on this.
Do I really need to connect to the telephone line across the internet as this logged user and the extension no: will be in the same local network?
you have to write a service and install that service on the machine where the TAPI TSP is installed. you could access your service via service-calls from your websites (e.g. via webservice).
for the service part: http://www.julmar.com/tapi/ here is a good starting point.
we have developed the scenario you are writing. we have a central installation of our CRM system, and in the branches of the customers is only the above mentioned service installed.
Related
I want to know is it possible to access my client Active Directory from my cloud application which is developed in C#. If yes then please provide the solution
Assuming required network connectivity is available, yes. What "required network connectivity" entails depends on the actual access mechanism being used. As an example, accessing Active Directory via secure LDAP requires TCP port 636 be open from the source to the domain controller.
Since it's not always feasible/practical/"a good idea" to open ports between cloud hosting sources and Active Directory domain controllers, you can look into ADFS (Active Directory Federation Services) which is a federated identify framework you can expose to the Internet and then use from within client applications (and we've got a good number of third party vendors that support authentication and directory data retrieval through ADFS as well).
As to the solution -- there are examples all over the Internet. Search here, search Github, search the Internet in general.
Situation
So I'm thinking about building ASP.NET Core website to host it on Linux based hosting provider. But I still want to use MSSQL database, so best choice for that would be Microsoft Azure.
My Question
Now my question is rather security based, since I know, that hosting them on different providers is totally possible (Regarding this question)
But if I'm about to do so, then how will be my data encrypted? If I'm about to use default HTTP protocol, then I asume, it's not, but if to use HTTPS protocol, it should be encrypted as well? Or how would it work, do I need to setup some other protocols or security for that matter?
My Thoughts
Since Client won't be directly connected with Web Site to Database connection, then there is not chance, that this connection would be listened, yet this "might not be listened" is rather not a far chance. And if HTTPS is included, then all connections should be encrypted, then it should work same with Web Server to Database connection.
You can access Azure SQL from anywhere as long as IP address is in the firewall rule. Since communication to Azure SQL is on SSL/TCP at all times, data is already encrypted.
Ideally, you want to host Azure SQL and web application in same region not to mention same provider. The main reason is your website will be dramatically slow due to network latency, if you host those in different location.
Recently, Azure offers App Service on Linux. It is definitely worth the try, before considering an alternative route.
FYI: Web Apps on Linux does not yet support deployment of .NET Core apps from uncompiled source. You need to publish/compile your .NET Core app locally first, and then push the published site bits to your app.
I have a App service hosted in Windows Azure in a region. When there are some issues with Azure servers in the hosted region, the app service goes down and the users are unable to see the website.
I would like to know if there is a way to geo-replicate the app service so that if the servers are down in 1 region, the website should automatically redirect it to a different server?
You can geo-replicate your app service by using Azure Traffic Manager service, which allows you to control the distribution of user traffic to your service endpoints running in different datacenters around the world.
As of today, Azure Traffic Manager provides 3 ways for routing the traffic: Priority, Weighted and Performance. For what you're looking to accomplish, I believe you would want to choose Priority routing method.
To learn more about how you can make use of this service to make your app service highly available, please see this link: https://azure.microsoft.com/en-us/documentation/articles/app-service-app-service-environment-geo-distributed-scale/.
This is an old entry but I thought I'd chime in after working with Azure for a few years.
If your statement "When there are some issues with Azure servers in the hosted region" is referring to transient outages, what you might be experiencing is your App Service Plan instance transitioning. Microsoft regularly moves ASP instances to new machines for reasons that make sense to them. Likely this is to load balance hardware or apply patches to the underlying VMs that host app services.
It has been my experience that when the ASP instances are moved, the new ASP instance needs time to warmup the app services hosted on it. If your ASP is configured with only 1 instance, your app service will be unreachable during this time.
If on the other hand, you configure your ASP with a minimum of 2 instances, Microsoft will synchronize the moving of the instances so that at least 1 remains up and available while the other is being moved.
Of course running a multi instance ASP requires your application to either be stateless or built using a session provider other than the default .Net "In Memory" session provider. CosmosDB for instance.
I belong to a team of several people, divided throughout the world.
We are building software for a certain platform, lets call it "Platform S". To develop for this platform there are 2 resources that are necessary. One is the SDK, which can be installed only using certain installer, that connects directly with the Platform S centrail server, and install it in out machine. The other resource is the developer website, where people post their questions and doubts about the SDK and hardware it operates on itself.
The problem comes that to connect to these resources, both the forums and to download/update the SDK, I need to have always the same IP address.
To solve this problem, I initially created a server with a fixed IP and installed proxy software in it, so that we could configure our local machines to connect to the proxy, and all have the same IP address.
Of course, to avoid that this proxy were used with nefarious purposes by hackers, and others, I protected the proxy with a password. When accessing the forums, this was no problem, as the browser opened a small dialogue window, to ask me for the user and password. But the installer that is in charge of installing/updating the SDK does not offer me this dialogue window. The last time, I disabled the password for a while, since SDK updating is not a task that one does that often, but after just a couple hours, I already got a notice from my server provider to warn me that the server was being used for malicious purposes. So that meant that this solution was not appropiate.
What approach could I take to solve my problem? Is the proxy idea the wrong way to go?
I have seen variations of this question but couldn't find any that dealt with our particular scenario.
We have an existing aps.net website that links to a SQL Server database.
The database has clr user-defined types, hence it can only be hosted in Azure VM since Cloud Services don't support said types.
We initially wanted to use a vm for the database and cloud service for the front-end, but then some issues arose:
We use StateServer for storing State, but Azure doesn't support that. We would need to configure either Table storage, SQL Databases, or a Worker role dedicated to State management (a new worker role is an added cost). Table storage wouldn't be ideal due to performance. The other 2 options are preferable but they introduce cost or app-reconfiguration disadvantages.
We use SimpleMembership for user management. We would need to migrate the membership tables from our vm instance sql server to Azure's SQL Databases. This is an inconvenience as we want to keep all our tables in the same database, and splitting up the 2 may require making some code changes.
We are looking for a quick solution to have this app live as soon as possible, and at manageable cost. We are desperately trying to avoid re-factoring our code just to accommodate hosting part of the app in Azure Cloud services.
Questions:
Should we just go the VM route for hosting everything?
Is there any cost benefit in leveraging a VM instance (for sql server) and a Cloud Service instance (for the front-end)?
It seems to me every added "background process" to a Cloud Service will require a new worker role. For example, if we wanted to enable smtp for email services, this would require a new role, and hence more cost. Is this correct?
To run SQL Server with CLR etc, you'll need to run SQL Server in a Virtual Machine.
For the web tier, there are advantages to Cloud Services (web roles), as they are stateless - very easy to scale out/in without worrying about OS setup. And app setup is done through startup scripts upon bootup. If you can host your session content appropriately, the stateless model will be simpler to scale and maintain. However: If you have any type of complex installations to perform that take a while (or manual intervention), then a Virtual Machine may indeed be the better route, since you can build the VM out, and then create a master image from that VM. You'll still have OS and app maintenance issues to contend with, just as you would in an on-premises environment.
Let me correct you on your 3rd bullet regarding background processes. A cloud service's web role (or worker role) instances are merely Windows Server VM's with some scaffolding code for startup and process monitoring. You don't need a separate role for each. Feel free to run your entire app on a single web role and scale out; you'll just be scaling at a very coarse-grain level.
Some things to consider...
If you want to be cheap, you can have your web/worker role share the same code on a single machine by adding the RoleEntryPoint. Here is a post that actually shows how to do what you are trying to do with sending email:
http://blog.maartenballiauw.be/post/2012/11/12/Sending-e-mail-from-Windows-Azure.aspx
Session management is painfully slow in SQL Azure DB, I would use the Azure Cache if you can..it is fast.
SQL Server with VMs is going to cause problems for you, because you will also need to create a virtual network between that and any cloud services. This is really stupid, but if you deploy a cloud service AND a VM they communicate over the PUBLIC LOAD BALANCER causing a potential security concern and network latency. So, first you need to virtual network them (that is an extra cost)..then you also need to host a DNS server to address the SQL Server VM. Yes this is really stupid, unless you are OK with your web/worker roles communicating with your SQL Server over the internet :)
EDIT: changed "public internet" to "public load balancer" (and noted latency)
EDIT: The above information is 100% correct contrary to the comment by David below. Please read the guidance from Microsoft here:
http://msdn.microsoft.com/library/windowsazure/dn133152.aspx#scenario
DIRECTLY FROM MICROSOFT GUIDANCE speaking about cross Cloud Service communication (VM->web/worker roles):
"We recommend that you implement the first option as the connection process would not need to go through the public Internet. Therefore, it would provide a better network performance."
As of today (8/29/2013) Azure VMs and Worker/Web Roles are deployed into DIFFERENT "Cloud Services". Therefore communication between them needs to be secured via a Virtual Network that exposes private IP addresses between the instances.
To follow up on David's point below, that about adding an ACL. You are still sending packets over the internet using TDS (SQL Server protocol). That can be encrypted, but no sane architect/enterprise governance/security governance would "allow" this scenario to happen in a production environment.