I'm working on a web application and I'm having problem accessing the database on server side because there is no user for the DB proxy to map. In other word, I have a method which will start as soon as the application comes online and will call itself every 5 seconds to check for new messages. If it receives a specified message, it then goes to the database and finds whatever it needs. However, accessing database on server side wouldn't be possible because there is no user for the DB proxy to map. So what is a good design pattern for this type of application? Should I need an application account for these type of automation process?
Btw, I'm using Weblogic JPA 2.1 for database stuff.
Thanks in advance.
First of all, what exactly do you mean by "no user for the DB proxy to map"?
I assume, you meant that you don't have a user known by a session who connects to the database?
If yes, you usually wouldn't do that anyway and instead nearly always have a database user for your application. Then, no matter a user triggers a database call by an action or the backend triggers it by some scheduling, it will always be the same user who does it. In your Java EE application, you'd have a datasource containing this user in its configuration and all your application parts use the related entity manager when doing persistent actions or queries.
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.
I have a project has two parts.
1- Windows form or WPF application that basically connects to database and write/read/update some basic text data (this part is already done).
2- On the other hand, I am currently developing an IOS app that can connect to remote database and read/write/update data.
What is the best way to connect the same SQLite or SQL database from both Windows forms app and IOS app.
Thanks in advance
The best way is creating an API/WebService which will be the interface between the database and your clients: WPF, iOS App and any other client you might want to add in the future.
Using a WebService is more secure, I guess you wouldn't want your database username and password being everywhere.
Using a WebService allows you abstract the data layer. Not using an API and using the connection to the database directly from your Apps will tightly couple your apps with the structure of your tables and any single change that happens in the database will force you to do the changes in the apps.
With WebService you decide what information will be available to the ones consuming it.
There are many others Plus on using WebServices but hope this are enough to clear your doubt.
I have silverlight web app. This web app run in 4 servers with a NLB in front of them. I need to use SignalR in my web app.
Lets think about this scenario.
Client#1 is connected to Server#1 and everything is okay. They are communicating each other through a hub perfectly. Then suddenly NLB assigned Client#1 to Server#2.
Now, what will happen to Connection and Hub? How they will communicate?
How is the connection between Client#1 and Server#1 set?
PS: I don't know much about NLB. Maybe it is stupid question, but I could not find a good explanation.
My second question is, which way among scaling out (Azure, SQL, Redis) is the best for .NET Silverlight app with possibly not many clients (Less than 10K)?
Not: I use MS SQL, SQL Server highly in my app.
After I watch this very informative video, I found answers to my questions.
Basically, the new connection will be established automatically when the client is assigned to other server node. The old connection is lost, however in any case, all the clients can be notified if you are using Back-plane. Thus, this is not a problem.
The hub object is also not a problem since it is transient object, i.e, in every new single operation a new hub object is created. Thus, this is also not a problem. There is no persistent hub object between server and client. Even if there is one server and one client, the hub will be destroyed and created in every operation.
The only problem is that if you are using groups, then the group information is lost for the client when it connects to the other server. The server does not maintain lists of groups or group memberships. So in that case you need to use a database and you can update manually from your db. When the new connection is establishes between client and new server, you can search this client in the db, and if you find a group information of that client, then you can manually re-register to that group again.
For choosing the Backplane, there is no fastest or best way. Nobody can say this way is faster or better among Azure Service Bus, Redis, SQL. It really depends on your application. If you are already using MS Azure Services, then pick Azure implementation for your web app. If you are using Redis in you app, go woth Redis. Otherwise you can select SQL. As I said, all of them are more or less same. Pick one that is most suitable for your web app.
These are all what get from video and the official site of the SignalR page.
This site is one of the best SignalR tutorial and api guide site. It is highly recommended that go through all sections.
My question is how do i get information from a server to my iphone app. let's assume I have completed my current project I'm working on that only needs data to be uploaded to my application.
I understand there is a database or server I must create but how do I go about creating or modifying one for my needs.
I mainly want to store login information from one user and allow users to search for people who have entered login information (name) to add to a friends lists within the current app.
i think in your case you can use Django-tastypie for backend will be good choice.since using django you can develop it in quick time and the tastypie has api services which can used easily for retrieval and sending data
you can go through this
http://django-tastypie.readthedocs.org/en/latest/
Take a look at services like Stackmob or Parse. These types of service could make it really easy for you to get the server side part of your application up and running. These services would act as your database and also provide an easy api for you to access the server side pieces.
Im just in the process of putting together the base framework for a multi-tenant enterprise system.
The client-side will be a asp.net mvc webpage talking to the database through the asp.net web api through ajax.
My question really resides around scalability. Should I seperate the client from the server? i.e. Client-side/frontend code/view in one project and webapi in another seperate project server.
Therefore if one server begins (server A) to peak out with load/size than all need to do is create another server instance (server B) and all new customers will point to the webapi's on server B.
Or should it be all integrated as one project and scale out the sql server side of things as load increase (dynamic cloud scaling)?
Need some advice before throwing our hats into the ring.
Thanks in advance
We've gone with the route of separating out the API and the single page application. The reason here is that it forces you to treat the single page application as just another client, which in turn results in an API that provides all the functionality you need for a full client...
In terms of deployment we stick the single page application as the website root with a /api application containing the API deployment. In premise we can then use application request routing or some content-aware routing mechanism to throw things out to different servers if necessary. In Azure we use the multiple websites per role mechanism (http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx) and scale this role depending upon load.
Appearing to live in the same domain makes things easier because you don't have to bother with the ugliness that is JSONP or CORS!
Cheers,
Dean