We want to create apps that connects to our database (Sybase ADS, connectable via .NET) over the Internet. The clients will include a windows forms app and probably an android app for phones and devices.
I know C#. I'm new to Web apps and webservices so bear with me here.
I'm thinking maybe the best way is creating a webservice in C# to run on IIS that will interrogate the ADS database using ADO.net.
So the webservice will expose methods via WCF that can be consumed by the clients.
The clients then invoke the methods via WCF. Am I right in thinking WCF will return data in .net XML objects?
Also can .net Forms consume XML objects easily?
The apps would have bespoke restricted access using credentials.
How does this approach sound? Any performance or security issues to think about? The data is not exactly classified but I wouldn't want snoopers to be able to pick up phone numbers etc.
Can most security be sorted out by just going from http to https?
What about performance. Presumably slower than if the apps were just connected using ADO.net to ADS on the LAN. Does WCF use bufers for http requests?
E.g. can you can start reading the stream on the client before the whole http request has finished? I'm thinking for populating list boxes of large record nos. etc
Related
I have currently built application in which I handle Products, Accounts, Orders, etc.
There are two databases one is a database which I created where I handle Users and Roles and some minor Application specific data. The other database is external and it is the one which holds all the data about Orders, Products and Accounts.
What I am trying to figure out is: how to build a server which runs parallel to the main application and handles all data manipulation with the external database.
Let's say a situation in which this would be helpful: There is an excel file which has to be created based on big amount of data and afterwards it has to be stored in the externalDB as certain type of format and sent as Email to someone. This will surely overload the main thread of the main application, hence we don't want that. Therefore, it would be a good idea to handle those kind of situations outside user's vision.
I am using ASP.NET MVC 5 and was curious what would be a good approach for this situation? I was thinking that I should make Console application, which is working as a service.
You would create a service architecture and have the services communicate with each other through controllers. These could push data back to the main application views, or the views could request data push from the services.
If you wanted to have jobs etc running on that server that send emails, you could easily just create SQL jobs or SSIS jobs or even custom service jobs that did that based on your criteria that are separate from the main view (where view is the main application that the user interacts with)
Services themselves could be configured with a light User Interface that you could call up on the server, perhaps in the service tray or through the Services component of Windows.
SOA architecture
https://www.cleverism.com/how-to-build-service-oriented-architecture-soa/
Micro Service architecture
http://microservices.io/patterns/microservices.html
Hope that helps. Good luck!
There are quite a few ways to do these kinds of things.
If your applications are for Android or iOS devices, it's common practice to have an external server running which handles intensive processing including managing your excel data, sending emails and database communication.
If your applications are cross-platform desktop applications or OS-specific desktop applications, you can still be able to use the external server, although certain other parts of the processing may be done on the client machine.
By using a web service to deal with database communication, it makes the applications more secure in regards to hard-coded database connection information, SMTP server credentials etc.
Using a RESTful web service will mean that you're adhering to the Hypertext Transfer Protocol (HTTP) which is great for exchanging data in the majority of cases.
Using a console application which acts as a TCP client server allows you to use the Transmission Control Protocol (TCP) to communicate in a different way. You're able to pass on data in a custom format if you wish. You'd be able to create a standard for communication which your applications will need to stick to.
The console application would do the same processing as the web service, however you would be in full control of logging requests, responses and data transfer.
I have a public server with web services (.Net) that collect data and uploaded files from different mobile apps and I need to synchronise it with an internal intranet server.
The intranet server is deeply protected by firewall and organisation policies.
I think this is a pretty common scenario where messages and brokers could be used, something like Rabbitmq or Nservicebus, but I'm not an expert on it.
As the data is only to be sent from the external server to the intranet one in unidirectional and asynchronous way I was thinking not to add another layer of indirection to the architecture and just use the web services exposed also for server to server communication.
The approach would be like:
An intranet windows serivce would poll regularly and at different scheduled intervals the external web service to know if there is new data to get (maybe from a certain point in time)
The web service would respond with the list of the new data and files
The windows service would iterate with calls to get all the data to be inserted in the intranet and download the uploaded files.
What are the risks of this approach? Would be better that the external web service would respond only a link to a huge zipped file response with all the data and files in it?
Should I use a something like RabbitMq also for a so simple scenario?
If you are literally dealing with files, you might want to think about something even simpler. FTP (more specifically sftp) might fit your needs better, and be FAR simpler to implement.
I have C# apps requesting data from PHP/MySQL API server (Rest/JSON). Now I also need to push messages to the C# apps when some events occur (form submission from the web site). I searched around, and it seems that COMET, long polling, and http streaming are options. Could you please provide some suggestions on which technology makes sense here, as I am not pushing to a web browser?
In addition, if using HTTP streaming (like twitter streaming API), do I need to keep a table of HTTP connections so I know which connection to use when pushing targeted events (only to certain C# clients)? I am a bit confused, and many thanks!
Make a WCF Web Service. http://www.codeproject.com/KB/WCF/WCFWebService.aspx
To connect using PHP: http://weblogs.asp.net/gunnarpeipman/archive/2007/09/17/using-wcf-services-with-php.aspx
In micro-services environment you might want to communicate between more different coding languages in the future, that's why in Kaltura we expose every API with descriptive XML that we can use later to generate client libraries in multiple coding languages, our code generator includes client libraries for C# and PHP.
I also published several REST server examples, including C#.
I want my WP7 application to fetch data from the DB; so it sends the query as string, the server execute the query, then send the result back.
how can I do that?
whatever you can do for me I am so thankful to you, I appreciate, if you provide any sample code (I am using C#).
thank you,
Regards,
Lena
You can use web services (WCF, .asmx, REST, etc. - however you want to build them). However, you should not be sending your query across, that is very bad for security. You should just be passing in parameters to your web service functions.
I don't have sample code for it, but for any connected system (client application, mobile app, whatever) your two best choices (In my experience, and depending on needs) are publishing the data source as OData or using some more specific WCF (or other web-type service) service to handle pushing the data back and forth.
Then, to your phone app, the request is basically just a web call.
I am using WCF to write a server that should be able to communicate with .Net clients, Android clients and possibly other types of clients.
The main type of client is a desktop application that will be written in .Net. This client will usually be on the same intranet as the server. It will make an initial call to the server to get the current state of the system and will then receive updates from the server whenever a value changes. These updates are frequent, perhaps once a second.
The Android clients will connect over the Internet. This client is also interested in updates, but it is not as critical as for the desktop client so a (less frequent) polling scenario might be acceptable.
All clients will have to login to use the services, and when connecting over the Internet the connection should be secure.
I am familiar with WCF but I am not sure what bindings are most appropriate for the scenario and what security solution to use. Also, I have not used Android, but I would like to make it as simple as possible for the person implementing the Android client to consume my services. So, what is my strategy?
with the small bit of android I have done.
the android sdk doesn't natively support soap server, you have to write it all your self.
Rest is your only option when working with WCF and android. Thats the way that Google are pushing you to develop apps.
WCF via HTTP transport is the way to go because it is not binary and does not make assumptions re all peers are .net/windows.
see this page for more info