Discover Database Connectivity
the linked page shows
Date Posted: April 3, 2007
There should be a reason why this "news" pops up right know.
About the topic.
Where is Java here ?
Server-side = PHP
+ some XML glue
(OK, I know the position regarding Java not being exclusive technology for TSS topics).
Maybe the reason is that summer is coming ?
Dumbest idea since... uhm, glued bread.
The world of PHP already suffers from SQL Injection exploits, so now you want to add even more holes? If the client is making the calls, it wouldn't take much for a malicious user to fiddle with them. Heck, you even return the resultset to the client, so its simply a matter of trial and error, until my "DELETE FROM FOO WHERE 1" executes.
some databases like ms access come with built in ' forms' for CRUD type functions. why not just expose them to the web.
do you guys even know whay we have some layers in application development. ?
This is totally retard-o!
Oh my God, returning again to the fat client!!
Oh my God, returning again to the fat client!!
I don't agree client server is bad just because client shares load in the application. Client are getting rich as well as intelligent. The richness is eye candy, taking clients close to what is possible on a desktop app. The intelligence in the client reduces the server load and hence increases scalability. Imagine all state is managed by the client and the server becomes stateless, that will provide near linear scalability and smooth failover. Browser is heading to be the operating system of the future - Flex, Google Gears, Silverlight and Html5 are pushing it towards that. More details are at http://sunilabinash.vox.com/library/post/is-flex-yet-another-mvc-framework.html
Your argument was disproved about 15 years ago. The client/server projects of the late 1980's had begun to mature and were being taken to an enterprise level. It was commonly found that they could not scale beyond 100 to 200 concurrent users. The primary reason for this was the excessive chattiness of the clients which were communicating directly with the DBMS. That's why services and 3 tier architectures became the big thing in the 1990's. Unfortunately, people also had to learn the painful lesson that a client designed for a client/server architecture could not be easily converted to work with services. The relationship with the dbms was too tightly coupled with SQL calls being generated even by individual widgets.
The other big reason for client/server falling out of favor was that the client designs (encouraged by the tools used) tended involve a lot of spagetti code, tight coupling and such that made maintenance a nightmare.
That is not to say that a rich client UI does not scale; it does. It just has to be designed to communicate with services - coarse grained calls. The sort of technology that is the subject of this thread is a big step backward. It's like deja vu all over again.
When referring to client/server, do you mean the architecture of the platform, or the architecture of the application?
Because as long as we are using the Internet, the architecture of the platform will always be client/server. It's simple - there's a request from a client, and there's a response from a server. It doesn't matter if you have application handlers for PHP/Java/Python/w/e languages. It's still a client/server architecture. What we commonly refer to as 3-tier is basically an extension of client/server (referring to the internet), and not a whole new architecture.
I'll give an example. Let's say you have a banking application and you want to ensure that whenever a transfer is made from one account to another account, the exact amount is taken out from one and added to the other account. Now the first place I'd want to put this logic is as close to the database as possible because I don't want somebody sneaking into the database, bypassing the logic, and becoming millionaires. The appropriate place for this business logic is the database itself. Putting the same logic in the middle-tier then becomes a redundancy. So, if the middle-tier is stripped of data sensitive tasks, what's left of it is the presentation. Back to where we started.
These are my credentials:
I hope it is...
Oh, and I love this part, found in the PDF paper:
DBC-JS prevents SQL injection attacks by using a prepared statement API. Since the parameter values are never parsed as SQL, injection attacks cannot occure.
var stmt = rdb.prepare(sql)
What were they thinking?
-Send an Ajax Request with the query to a servlet
-Servlet use the JDBC to connect DB and return ResultSet
-Create a JSON object using API from json.org and popualate Result Set data.
-Return the HTTP Response
-Now you have the Result set in JSON format and your Ajax callback method is responsible to populate it in a table
One can imagine if the entire scripting is in Java Script then the API must take DB IP Address, User Name and Password as input arguments which one can easily view in browser by downloading Java Script or "view source" options and is nothing but the security threat.So my request do not waste your valuable time on reading this topic.
Look into Aptana Jaxer(http://www.aptana.com/jaxer
) . Its a ajax Server which is used to execute Server side java scripts from Client Side .
In this server architecture , You need to send a full java script code to execute . It will be rechecked with their Pattern and it will be executed .
Its a good try ...
See for example JSQL taglib from Coldtags suite: http://www.servletsuite.com/servlets/jsqltag.htm
The same idea - request data right from the web tier.
1 - To have knowledge about each layer & language set
2 - To share the responsibilities with a big team and have a good architect who knows at least a little about each layer so he can connect all layers with a good glue.
If we're building WEB Based and Database dependent applications we should at least have a look at these technologies and read at least one good book instead of searching only the problem areas from Internet.