Discussions

News: Database Connectivity for JavaScript

  1. Database Connectivity for JavaScript (20 messages)

    Discover Database Connectivity, a JavaScript API and implementation that enables Web clients to use an Ajax style of programming to directly access server-side relational data without compromising enterprise security. Also, learn how Web 2.0 applications can use this middleware to access relational data as a first-class construct instead of through ad hoc protocols.

    Threaded Messages (20)

  2. Hmm, 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 ? Client-side = JavaScript 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 ? Guido
  3. Dumbest idea since... uhm, glued bread.
  4. Database Connectivity for JavaScript requires Web clients to authenticate themselves to the database server. Built-in security mechanisms such as authorizations and privileges can be used to further protect your database assets. In addition, the Database Connectivity for JavaScript gateway can be customized to provide specific security features that your site requires.
    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. Roy Russo http://www.loopfuse.com
  5. Maybe in future: RIA for SQL[ Go to top ]

    Now we need RIA using SQL. SQL on client-side, JavaScript on data access. NICE!
  6. Great. I've been looking forward to the return of Client/Server disguised as new technology. We could package this up with some JavaScript libraries and sell it as "PowerBuilder Web".
  7. nuts !!![ Go to top ]

    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. ?
  8. This is totally retard-o!
  9. Oh my God, returning again to the fat client!! If this is the future, please FireFox guys, WebKit guys, Opera guys ... put Java on your browsers please. I'm having a headache thinking about how to deal with piles of slow, unstructured, untyped, un-OOP JavaScript.
  10. Oh my God, returning again to the fat client!!

    If this is the future, please FireFox guys, WebKit guys, Opera guys ... put Java on your browsers please. I'm having a headache thinking about how to deal with piles of slow, unstructured, untyped, un-OOP JavaScript.
    ...it actually sounds like you just don't know JavaScript. It's a solid language. I pity those that complain about aspects where it actually draws power, but people also say that of JSP (and they equally have my pity).
  11. It's true Javascript is getting better. If ECMAScript-262 edition 4 gets here it will be even better, but that misses the point. It's client/server all over again. Bad, bad, bad. We don't need to be loading up the browser with tons of code and making a lot of finegrained calls to whatever. We don't need to be directly exposing our backend resource managers to the internet or even the intranet. That's all a big leap backwards.
  12. It's true Javascript is getting better. If ECMAScript-262 edition 4 gets here it will be even better, but that misses the point. It's client/server all over again. Bad, bad, bad. We don't need to be loading up the browser with tons of code and making a lot of finegrained calls to whatever. We don't need to be directly exposing our backend resource managers to the internet or even the intranet. That's all a big leap backwards.
    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 Thanks Sunil
  13. 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.
  14. 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. Also, there's no way that Javascript can talk directly to a database. It has to be through a middle layer. IMO, this project is a great step. 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.
  15. ...it actually sounds like you just don't know JavaScript. It's a solid language. I pity those that complain about aspects where it actually draws power, but people also say that of JSP (and they equally have my pity).
    These are my credentials: ItsNat XPDOM Note: I have "a bit" of experience managing lots of JavaScript code and I like coding in JavaScript in a OOP fashion :) And... not, JavaScript IS NOT a solid language.
  16. Is it a joke?[ Go to top ]

    I hope it is...
  17. Re: Is it a joke?[ Go to top ]

    Oh, and I love this part, found in the PDF paper: http://domino.watson.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/507fddaf5626498b852572b200540aa2?OpenDocument
    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.
    Yeah right, but if you have a JavaScript function that gets called this way:
    var stmt = rdb.prepare(sql)
    the "sql" variable is still a JavaScript string that you can manipulate how you wish! What were they thinking?
  18. This is not a pure JavaScript program at client side. PHP is the mediator at the server side.You can do the same thing in Java or .NET also as follows : -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.
  19. 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 ...
  20. 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.
  21. Rich Client is not bad[ Go to top ]

    The common problem between programmers is to become an expert in one area and then try to move all the logic in this layer. If developer is an expert in DB he will write lots of Store Procedures and a few java classes, if he is an expert in Java then surely he'll try to use some ORM frameworks to access DB, Ajax for user interface and build all the logic in middle layer. But if he is an expert at interfaces, DHTML, Javascript etc. he will try to build lots of the codes in the UI layer. And all them will argue about their languages, structures etc. There are two ways to pass this problem: 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. I see lots of people blaming about Javascript. I understand because it's Java forum and lots of the people are expert at Java in middle layer, but having a rich client is a good opportunity for us. People don't like dumb terminals and mainframe interfaces. Why? Because they are so basic. For every good thing we also need a nice interface. This is why lots of the people use Windows. Accept it or not but it is very nice and simple for a starte user. Anyway. I've build a large project in an automotive manufacturer to follow-up quality problems without any paper. People use picture based interfaces to enter defects, their repair operations and other quality activities. I've build an archtitecture to share the workload through layers. By using Javascripts I've put all the user interface and rendering operations on UI layer. So I use client computer power. Even on a small server with only one CPU this module runs without any problem. 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.