I am developing an MVC Web app on Azure website. My service call to a unmanaged DLL that uses the Winsock to communicate with alarm system. I know that Azure website supports WebSockets so I wondering if it supports the Winsock too?
You're basically asking if you can allow traffic on specific TCP/IP ports to/from the Azure Website, and the answer is no.
You can still achieve what you want using a Cloud Service instead of WebSite (WebRole), which basically gives you more options, i.e. the ability to allow specific ports.
Reference here:
https://azure.microsoft.com/en-us/documentation/articles/vs-azure-tools-configure-roles-for-cloud-service/#manage-endpoints-and-certificates-for-your-roles
Related
I am developing an Emergency Response System. I have developed my server using the Django Framework in Python. I have an Android Client which needs to communicate with the Server. My question is :
1) Should I use REST API for communicating between the Android App and the Django Server?
2) Or is there any other RPC methods (like RMI in Java) which should be used for communication?
3) The Client developed as an Android App needs to send requests/messages to the server based on the user interaction. Would a REST API be a good option?
Thanks.
Use HTTP. This is the easiest protocol available to you.
REST is an architecture pattern (it describes how you would design your API service and client). It is designed to use HTTP (a protocol).
In order to implement RMI you would have to find an implementation for JRMP on Android and then make sure that all your users have access to this over the network; you would also have to use TCP/IP which would be near impossible to implement separately on your remote clients (unless you have deep level control over them) and even then, the network should allow such access which most mobile providers will not.
It is not practical, and it will not work reliably.
I am working on a WP 8 app which I would like to connect to an on-premise(local) web service. I have managed to do so using simple BasicHttpBinding without secuirty and Azure Service Bus Relay, but i cant manage to make a secure connection. WP 8 only support BasicHttpBinding, and thats my biggest problem so far.
I understand that Azure mobile service is an efficent and easy way to securly connect your WP 8 app to the cloud. Is it possible to access an on-premise web service through Azure mobile service? And if possible, could it be done without exposing all the content of the local service publically via Azure Service bus relay?
You should be able to do this securely from WP8 -- I'm not quite sure why it's not working -- but even if you had to roll something yourself, it should be possible (example, check out this post from Michael Collier on doing something similar: http://michaelcollier.wordpress.com/2011/08/19/azure-sb-and-wp7/)
To the question, though, WAMS (Windows Azure Mobile Services) is definitely easy to use, but it wouldn't be feasible to do what you want -- that is, to be a public endpoint in this fashion. In short, WAMS gives you an easy to use CRUD interface to data that happens to also expose features for authentication and notifications, and at the same time gives you some server-side javascript to do custom work -- such as calling out to other services, sending emails or notifications, etc.
But, each request into WAMS is essentially mapped to a CRUD operation on a database table. While you could likely 'inject' a simple call, this isn't what you want. It sounds like using the service bus is the right way to do this and should be possible...
The Window desktop application provides C++ API that gives an array of customer information such as name and address. I want to expose this as SOAP Web Service with Security so that authorized clients (from remote servers Linux/Java based through ESB) of this web service can get this information at any time they want in SOA implementation (Java based).
The desktop application does not have a standard database. It stores its data internally. Its basically old custom built CRM application that is installed on each agent's PC box. Each agent has its own list of customers.
What are the steps to achieve this task?
Do I need to run this as Windows service?
The short answer is, yes, you can expose data from a desktop application through a SOAP web service. It is easier to do with C# and .NET, but not impossible to do from C++. What steps you need to take will depend on which platform you are developing for.
Roughly -
Implement an endpoint that supports SSL where clients can connect to your desktop application (using sockets in C++ or HTTPListener using .NET).
Write code that can receive and dispatch SOAP requests.
Handle SOAP requests and return properly formatted SOAP responses.
Handle WSDL requests.
Implement a security mechanism (cookie based or otherwise).
Using .NET, most of this is in the platform code already, you just have to put the pieces together. With C++, you may find some third party libraries but essentially you'll be writing your own.
You only need to implement a windows service if you want the data to be available while a desktop user is not logged in and running your desktop application. The challenge here is that you'll have to make sure the windows service can access the same data the desktop application is using.
Another strategy would be to access the data from your desktop application using the C++ API and Interop and implement the web service as a standard out of the box asmx hosted on IIS.
Simple problem, actually. I am trying to evaluate the possibilities of Google Apps, using Python as development language. It seems practical to create a web application or web site with it, but how about creating web services?
I am not too interested in solutions to create a SOAP or REST service in Python for Google Apps, since a simple Google search should provide plenty of solutions. I am more interested in experiences and ease of use.
But the real question is: When comparing a web service in Google Apps with web services in the Microsoft Azure environment, which would provide the better performance? The best user experience? I don't care for the actual development languages but need a good comparison of pro's and cons of web services in both the Google App Engine and Microsoft Azure.
Somehow, Azure seems better suited for services while Google seems better for sites. A tough choice...
Would be very interesting to see if both could be combined into a single solution. :-)
Btw, choosing which engine to use also means choosing the proper development environment and programming language. While I'm proficient in .NET and Python and many other languages, the choice for the service engine determines my focus for future projects.
When building services in Windows Azure, they'd simply be processes running in your VM (Windows Server 2008 SP2 or R2 SP1). You can host services easily in any of the three role types:
Web Role (essentially Windows Server with IIS running) - just add a WCF endpoint to IIS or self-host from your own process).
Worker role (Windows Server with IIS not running) - self-host from your own process
VM role (your own Windows 2008 Server VM pushed to Windows Azure) - Host with whatever mechanism you install / set up.
Each VM in Windows Azure may expose a total of 5 endpoints. These can be a combination of input (external facing) and internal endpoint, each port supporting tcp, http, or https. You define endpoints in your vm role's properties.
Internal endpoints are only usable by other VMs in your deployment. You can't see them / access them from anywhere else, including other Windows Azure deployments. Input endpoints are accessible by the outside world.
If you want an app running in Google to access your Windows Azure service, simply connect to the endpoint via ip+port. The one thing you'll want to be aware of is bandwidth usage. Because your Google-hosted app will be in one data center and your Windows Azure service in another, you'll pay ingress / egress for data going in and out of your Windows Azure service (and I'm guessing there's an associated bandwidth charge on the Google side, but I'm not sure).
It's actually pretty simple to set up a service. For .NET-based examples, look at the labs in the Windows Azure Platform Training Kit (this also other good examples, such as setting up your first Windows Azure application). For a python service host, you'll need to execute python.exe from your VM role's OnStart() event handler, passing in your script name (and optionally port number to listen on). For a simple example of launching python.exe, look at Steve Marx's blog post here.
EDIT: If you're looking to host multiple services (e.g. multiple ports), you can choose to host them in a single VM role or in separate roles, to optimize for cost (with the known limit of 5 endpoints) or performance (scale each service independently).
What are the differences between a web service and a Windows service?
My experience has mostly been with Windows services, and I have never created a web service.
Do web services behave similarly to Windows services?
Can they have scheduling, run at certain times, etc.?
When you would use a web service in place of a Windows service, and vice versa?
They're about as different as two things can be.
A Windows service is an application that runs without a user being logged into the system, usually to process some data on the machine that needs no user intervention to work with.
A Web service is a website that, when contacted, returns XML (typically) in one of several standard formats for the service consumer to process.
One can't be substituted for the other. They are fundamentally different.
You are asking us to compare apples and oranges. I am posting definitions as well as links to further reading for you so you can see why these two things are exclusive and cannot be compared like you are trying to do.
Web service:
Web services are frequently just Internet application programming interfaces (API) that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services
Windows service:
A Windows service is a long-running executable that performs specific functions and which is designed not to require user intervention.
A web service is an HTTP interface to a system. For example: the Twitter API or the Google Maps API are REST web services.
A Windows Service is a background process that runs without user interaction.
The two are not related.
Webservices are simply a way of exposing services for consumption. They are about interaction between components.
A windows service is an executable that runs for a long time on a machine to perform some task.
You wouldn't use one in place of the other - they perform two entirely different functions.
For (a simple) example (to highlight the difference), if you wanted a method to pass control messages to your service, you could expose a webservice as the protocol through which third parties would communicate with your service.
A web service is software system used for machine to machine communication over a network.
Here's the wiki for Web Service.
A windows service, in contract, is a service that runs on an local machine.
Here's the wiki for Windows Service.
They are independent technologies, one would not replace the other.
I don't think there is a very large difference, a web service runs in IIS or Apache, a windows service doesn't. You can call windows service methods by using remoting and you can create windows service with WCF. The methods of a windows service can return xml or json too.
IIS 6 doesn't support all the WCF possibilities so we have build WCF windows services (this is called self hosting).
Both a web service and a windows service are apps that run in the background. You can use WCF to build both kind of services.
web service was mostly used in application integration between systems.
windows service was mostly used in background tasks, scheduled tasks.
A windows service program can call web service methods.
web service program cannot call window service methods.
A Web Service is a dll hosted by a web server and run as a web application and can be spun up upon request.
A windows service is an exe hosted by the operating system and runs continuously waiting on a request.