how to connect to SQL Server from JSF - java

I have created a simple JSF application, now must to connect to SQL Server and perform CRUD operations on those tables from database.
I was a .NET programmer and i don't know how to connect to SQL Server from JSF. I have read something about JNDI, but not understood well. My questions are:
where should JNDI be defined: on Tomcat or my application?
where to define the connection string?
which driver/jar should be used?
Can you recommend any code samples, links to tutorials how to perform crud operations, or any other guidance?

where should JNDI be defined: on Tomcat or my application?
In the JNDI container. That's thus Tomcat.
where to define the connection string?
In the JNDI container. In case of Tomcat, that'll go in the context.xml. You can either modify Tomcat's own context.xml or supply your own in META-INF folder of your webapp. More details can be found in the Tomcat JNDI resources HOW-TO.
which driver/jar should be used?
The one which can communicate with the DB in question. In case of Microsoft SQL Server, that's under each the DB-vendor provided JDBC driver or the performancetechnically better jTDS driver.
Here are some useful tutorials which might help you step by step further:
Basic DAO tutorial (with JDBC) - Using in JSF
CRUD with JSF 2.0
JPA tutorial (better than JDBC)
Netbeans CRUD with JSF 2.0 and JPA 2.0

This is a very broad question. I will take a shot at trying too keep it simple and short.
Here are the steps.
First create a backing bean that works with your front end face page.
Create a service class that encapsulates the CRUD tasks.
Create a database methods class that performs each CRUD task.
This is how the code should flow:
"Your UI face invokes a method in the backing bean->the backing bean invokes service class->service invokes the database methods class. This is commonly referred to as the DAO pattern."
For details on how to connect to a database.
You can either create a local data source and connect via standard JDBC procedure.
Or you can create connection pools in your container (JBOSS, WebLogic, etc). Then look up those connection pools in your app via JNDI lookup.
If you are very new to this, then I would recommend to start out with creating a basic database connection using JDBC and running your queries against it. In the long term, you will want to get yourself familiar with connection pool (actually this will give you a better performance too), Spring JDBC framework, ORM support (hibernate, iBatis).
Here is a link to starting a jdbc connection for Microsoft SQL server (example on step1).

Related

deployment of WAR on IBM Websphere

I have developed a Rest webservice using JERSEY. WIth connects with the oracle database. I have JDBC connection code in my code itself, like the url, IP and username and password. Is is really required to again to configure the database connection on the server? like giving a JNDI name etc. Please help.
Thanks in advance.
Is it really required to again configure
No. It is not required to configure the database on the server, giving it a JNDI name and so forth.
Having said that, JavaEE best practices call for design whereby an application doesn't know the specifics of how to connect to external resources (such as databases). Instead, the application should "look up" that external resource by a logical name, and receives an object through which data can be accessed.
The main benefit in that is that your application code can focus on application functionality, while the application serving environment can take care of low-level aspects such as connection pooling, statement caching and so forth.
The other benefit of following this paradigm is that your application becomes immune to changes in the location of the database: no need to recompile your code, or re-package your application, in order to refer to a different data source. Instead, you could change the data source definition in the application serving environment so it points to a different location, and you're good to go.

Configuring a fall back datasource in RESTLet DAO Client Server Architecture In Java

I am using a Restlet DAO Client Server Architecture in Java, and a JDBC MySQL Data source with server deployed on Apache Tomcat 7.0 . My master database is online while the replicated slave database (read-only) is on local lan.
The server itself on startup should choose between the two available databases
- if online(master) is reachable it connects with it,
- else establishes a read only connection with the local DB
Assuming no internet, we connect to the local DB. Now How do I switch to the online DB once Internet is back. And switching has to be done on the reverse scenario as well i.e. first we have internet and then no internet.
I think that you should implement a custom DataSource (implementation of the JDBC interface DataSource) that acts as a proxy in front of the two targets datasources (one for the local DB and one for the remote one).
In this scenario, we need to implement a way to check if the internet connection is there or not.
You can notice that you DAO classes should base on a data source to interact with the database. Dependency injection or factory pattern could be helpful here...
Hope it helps you,
Thierry

Oracle/Java application, recommended architectures

I am working on a desktop Java application that is supposed to connect to an Oracle database via a proxy which can be a Servlet or an EJB or something else that you can suggest.
My question is that what architecture should be used?
Simple Servlets as proxy between client and database, that connects to the database and sends results back to the client.
An enterprise application with EJBs and remote interfaces to access the database
Any other options that I haven't thought of.
Thanks
Depending on how scalable you want the solution to be, you can make a choice.
EJB (3) can make a good choice but then you need a full blown app server.
You can connect directly using jdbc but that will expose url of db (expose as in every client desktop app will make a connection to the DB. you can not pool, and lose lot of flexibilities). I would not recommend going this path unless your app is really a simple one.
You can create a servlet to act as proxy but its tedious and not as scalable. You will have to write lot of code at both ends
What i would recommend is creating a REST based service that performs desired operations on the DB and consume this in your desktop app.
Start off simple. I would begin with a simple servlet/JDBC-based solution and get the system working end-to-end. From that point, consider:
do you want to make use of conenction pooling (most likely). Consider C3P0 / Apache DBCP
do you want to embrace a framework like Spring ? You can migrate to this gradually, and start with using the servlet MVC capabilities, IoC etc. and use more complex solutions as you require
Do you want to use an ORM ? Do you have complex object graphs that you're persisting/querying, and will an ORM simplify your development ?
If you do decide to take this approach, make sure your architecture is well-layered, so you can swap out (say) raw JDBC in favour of an ORM, and that your development is test-driven, such that you have sufficient test cases to confirm that your solution works whilst you're performing the above migrations.
Note that you may never finalise on a solution. As your requirements change, and your application scales, you'll likely want to swap in/out the technology most suitable for your current requirements. Consequently the architecture of your app is more important than the particular toolset that you choose.
Direct usage of JDBC through some ORM (Hibernate for example) ?
If you're developing a stand-alone application, better keep it simple. In order to use ORM or other frameworks you don't need a J2EE App Server (and all the complexity it takes with it).
If you need to exchange huge amounts of data between the DB and the application, just forget about EJBs, Servlets and Web Services, and just go with Hibernate (or directly with plain old JDBC).
A REST based Web Services solution may be good, as long as you don't have complex data, and high numbers (try to profile how long does it takes to actually unmarshal SOAP messages back and to java objects).
I have had a great deal of success with using Spring-remoting and a servlet based approach. This is a great setup for development as well, since you can easily test your code without deploying to an web container.
You start by defining a service interface to retrieve/store your data (POJO's).
Create the implementation, which can use ORM, straight JDBC or some pooling library (container provided or 3rd party). This is irrelevant to the remote deployment.
Develop your application which uses this service directly (no deployment to a server).
When you are satisfied with everything, wrap your implementation in a war and deploy with the Spring DispatcherServlet. If you use maven, it can be done via the war plugin
Configure the desktop to use the service via Spring remoting.
I have found the ability to easily develop the code by running the service as part of the application to be a huge advantage over developing/debugging something running on a server. I have used this approach both with and without an EJB, although the EJB was still accessed via the servlet in our particular case. Only service to service calls used the EJB directly (also using Spring remoting).

Using DataSource without app-server

My data access objects takes a DataSource as a parameter which works perfectly if they are deployed within an app server.
I'm wondering how I can assemble a data source from within a simple Java class. This might also be useful for unit testing?!
There's nothing magic about a DataSource. It's just an interface. Spring has a basic one for testing purposes if you're already using Spring. Apache DBCP is all about providing a pooling DataSource. Pretty much any other JDBC connection pooling library out there will also provide a DataSource implementation. Just instantiate it, set the properties, and run with it.

Java REST using DataSource

I'm new to REST on Java and I would like to create "simple" REST services that queries a database and returns some JSON info.
What I would like is to use JDBC access to DB, no JPA.
When working with servlets I configure a server datasource and in my servlets in the "init()" method I store a reference to the datasource and on every request create a connection.
What must I do for REST services?
Thanks in advance.
If you are planning to connect via JDBC based on the REST API requests and already familiar with REST, you should consider looking into Spring JDBC support: Current JDBC Spring Support. This would take care of all your concerns regarding the right place and time of instantiating/looking up a data source or connection.

Categories