I make use of the SQL Server Reporting Service's web services api to render reports using the ReportExecutionService proxy in an asp.net web application.
My question is: should I be creating a new instance of the ReportExecutionService proxy each time I generate a report, or is using a singleton instance the recommended approach? (eg. for performance reasons, etc).
What wcf bindings you are going to use? In general - you can reuse proxy, and in single-user single thread application it is a good idea.
But singleton is a bad idea in ASP.NET application - by itself proxies are not thread-safe.
Therefore, you can create proxy and cache it on session layer (is one session = one thread, as I remember this is configurable in ASP.NET).
Related
I am new to web development, and have seen posts such as these . If one is using AWS and is connecting to an AWS rds instance through Node, is that still considered a direct connection as opposed to a web service?
You're probably going to get a bunch of conflicting opinions on this. My personal opinion is a web service in front of your database makes sense in some scenarios. Multiple applications connecting to the web service instead of directly to the db gives several advantages, security, caching, etc.
That being said, if this is just a single app then most of those advantages disappear and in fact just make things more complex for you. You're going to have to setup your web service for the db as well as your actual code.
If one is using AWS and is connecting to an AWS rds instance through Node, is that still considered a direct connection as opposed to a web service?
No, if Node.js is running on a server or in "serverless" containers (e.g. AWS Lambda) that is not a direct connection. That is a web service, and that's what you want.
A direct connection means the app connects to the database itself... but that requires embedding credentials in the app.
You do not want to embed anything in your app that you would not willingly hand over to an arbitrary user -- such as database credentials and API keys -- because you cannot trust that the app won't be reverse-engineered.
You should design the app in such a way that you would have no security concerns if the entire source code of the app were exposed, because knowing everything about the app's internals would give a malicious actor no valuable information. How? The code on the server side (e.g. in Node.js) should treat every request from the app as potentially suspicious, untrustworthy, etc., and validates every request to do anything.
This layer of separation is one of the strongest reasons why you never give the app direct access to the database. Code running in a trusted place -- your web server/API layer -- needs to vet every database interaction. This topology also decouples the app user from tying up resources on the database server when not actually interacting with the database, which is far less practical with a direct connection.
We're developing a cloud based web application for customer management. One of the main goals i the capability to connect to different local applications on the customer endpoint.
As example, we don't want to have a customer database in out application, the customer should be able to search within his local ERP system right away.
What we need is not much. Only a client on the customers server with access to the local SQL server as well as the COM model.
But as webdevelopers and mainly going with PHP the question came up, what technology we should use?
I've got two approaches in mind:
NodeJS
Lightweight, Javascript and with the Express and winole32 extension we should have everything we need. But the deployment and installation as a service seems to be a bit wacky.
C# .Net Web API
Also a good approach I guess since the client servers are allways windows. But is there a way without IIS?
Or do you have something completely different in mind? It should be very fast and compact. So its basically just a RESTservice that can be deployed with ease.
Thanks for your inputs and thoughts.
C# .Net Web API Also a good approach I guess since the client servers are
allways windows. But is there a way without IIS
It is called OWIN and it is properly documented (web api self host is a good keyword) and works like a charm. Using that on various services to expose an API into the service.
Currently I am working on an ERP Project, Using Entity FrameWork and WCF at server side and WPF at client side. Since it is a big project , we have a lot of entities.What we did so far is, Created Service contracts for each Entities and exposed with multiple endpoints.The Problem is we had to add Service Reference for each Service and we are feeling difficult to manage these web services.
1.Is this a proper way ?
if yes,
2.Is there any way to allocate these web services (in classes or folders)..?
Thanks in advance.
You don't want to keep generating the proxy classes in the client.
Just move the POCO classes and contracts to single assembly which you can reference in the server and client. Then create the necessary channels in the client with ChannelFactory.
ChannelFactory(TChannel)
If you are dealing with many services you can create routing service which will behave like facade. Once you have routing service defined then all requests are going to be sent towards routing service and then, based on some criteria, provided to specific service. You are dealing with only one service so if any change in sub-services occures, for instance endpoint's address is altered, then such a change needs to be reflected only in routing service.
Finally i got how to deal with multiple Services
i am considering to use svcutil.exe in order to create proxy classes.
so that we can arrange those classes in folders, and also we can
get more control over proxies
Could someone please explain to me in a simple way, what is a web service?
Please correct me if I'm wrong. I have a DB hosted somewhere in the web, and I want to perform DB transactions from a desktop application as well as a mobile application. Can this be done through a web service ? Someone mentioned it to me and I wanted to make sure this could happen.
Here's a good explanation on Wikipedia.
A middle dynamic content processing and generation level application server, for example Ruby on Rails, Java EE, ASP.NET, PHP, ColdFusion platform
The middle tier of a 3-tier application is often the web service
i want to perform DB transactions from a desktop application and a mobile application, can this be done through a web service ?
This is Exactly what a web service is for.
A web service allow you to create multiple front ends if needed, and serve your database data to all of those front ends. You can also open up the API and allow third party developers to access the web service and thereby access the data of your application in a controlled environment.
It's considered a better practice for larger applications to access a web service or a middle tier rather than directly access the database.
In your case, a web service would involve setting up your DB behind a web server that listens for incoming requests, performs the appropriate DB operations, and returns whatever data is appropriate. Then, your desktop and mobile applications could send a http request and the DB would respond appropriately. This would let all your applications access the same DB.
We are designing a system that will use Silverlight webparts. These webpart will communicate with backend systems via web services.
What I am wondering is which route they should take:
Web services on the SharePoint server that talk to the backend service via business connectivity services.
A call via the service bus
A call directly to the backend service
Is any one of these better than the other?
It depends on requirements that you've not detailed here.
Negatives for via the sp server.
Add's extra latency
Adds overhead to the sp box
Makes it a little harder to do authentication (double hop)
Positives
Gives you more control - the SP web service could for example, implement caching or extra
security rules