Synthetic key vs Natural key in DB world

One of the decade old debates in SQL world:
                        Which is preferred primary key- synthetic or natural?

Both have their own pros and cons, so choosing one over other is not trivial. But you can definitely do one thing to make your life easier, whichever approach you (and your team) decides; let's stick to that and try to avoid mixing these two strategies.

Natural Key

The word relational used in DB/SQL world basically means that while designing tables your need to consider how the columns relate to each other. This way all columns together will define one entity. So conceptually it makes sense to have one or more than one column from the entity to make rows unique. But sometime over a period it becomes difficult to maintain this condition and we are forced to changed the schema of table to ensure that primary or composite key(primary key composed of multiple columns)  really remain unique.

Synthetic/Surrogate/Made-Up/Artificial Key

Synthetic is a generated unique value that is used as primary key of a database table. So it's one of the columns of the table but it doesn't have any logical relationship with the rest. But good thing is that a single synthetic key can ensure that all rows have a unique key.  It's a sequence generated by an algorithm which ensures its uniqeness. This is definitely better than managing multiple columns for a key. 

References
http://www.dbta.com/Columns/DBA-Corner/Surrogate-Keys-or-Natural-Keys-84892.aspx
http://stackoverflow.com/questions/4960263/sql-primary-key-column-artificial-id-column-vs-natural-columns

Brief overview of JPA

JPA(Java Persistence API) came into the picture to bring object-oriented and relational model together. It's basically an abstraction on top of JDBC (and is part of EJB 3.0 specification); to let you deal with tables without using SQL. Before this, the persistence model of Java was called as Entity Bean and was part of Enterprise Java Beans specification. Entity Bean wasn't lightweight, and hence got replaced by this new (new age) API.

Relational databases store data in tables in form of rows and columns. So dealing with tables directly was not very convenient in Java where objects rule. JDBC bridged the gap a bit but wasn't able to remove SQL altogether. JPA consists of two broad components to solve the full problem - first is the mapping of objects to tables and second is providing the ability to query. Let's cover them briefly:

Mapping (ORM): JPA maps Java objects to relational database tables. Mapping is achieved through ORM metadata. The metadata describes the mapping between table and objects (and attributes and columns). It was initially achieved by a descriptor XML file, but it got further simplified and now annotations are preferred approach (Use of annotations brought convention over configuration technique). So, just put annotations at Class, field/method level and boy you are done with mapping.

A common confusion is that hand-coded SQL queries are going to be as fast as one automated by ORM tool or maybe even better. So is it recommended to use ORM tools?

Yeah, it's safe to assume that hand-coded SQL/JDBC can be easily analyzed and optimized. But, ORM tools like Hibernate gives much more optimizations like automated queries and caching out of the box. It hides a lot many details and allows the programmers to focus on core business problems. Also, these tools abstract your underlying database as well. 

Querying: Mapping will not make much sense if we still have to write SQL queries so JPA tweaked SQL to come up with its own query language, JPQL(Java Persistence Query Language). JPQL queries entity objects.  JPQL doesn't understand underlying row/columns and tables, it queries objects so uses familiar notation i.e. dot (.). 

Evolution of JPA

JPA 1.0 (May 2006, EJB 3.0) brought the object-oriented and relational model together. It was bundled as part of J2EE 1.3 and then later J2EE 1.4 as well.

JPA 2.0 (Dec 2009, Java EE 6) It extended JPQL, added second-level cache, pessimistic locking (criterial API)

JPA 2.1(Apr 2013, Java EE 7) supports schema generation (persistance.xml), converters, CDI, stored procedures, bulk update and delete queries, enhanced criteria API (update and delete)
more here - http://www.thoughts-on-java.org/jpa-21-overview/

* From version 5, J2EE is known as Java EE, and similarly J2SE is know as Java SE.

Entity

Objects which get persisted through JPA provider(like hibernate) is referred to as Entity. Entities live shortly in memory and persistently in a database. So you basically perform all operations on Entity which are POJO and it typically represents a row of a table. Entity class should satisfy below conditions:

• Entity class must be annotated with @javax.persistance.Entity
• The class must have public or protected no arg constructor (it can have other constructors as well)
• The class must not be declared as final. No method or persistent instance variable must be declared as final
• The class must not be enum or interface 
• If the instance has to be passed by value as the detached object, the entity class must implement Serializable interface

@Entity
public class Employee{..}

@Entity annotation converts the Employee class into an entity (in above snippet).  Also going by convention over configuration rule, the table name is same as class name (i.e. Employee).

JPA Frameworks/Implementation

• Hibernate open source implementation, supports JPA from version 3.2, influenced JPA specification
• TopLink commercial implementation
• Java Data Objects (JDO)
• EclipseLink also supports object XML mapping. Reference implementation of JPA. 

Note: Persistence provider or provider refers to JPA implementation. 

Testing Websocket Service from Browser

Move aside HTTP, WebSocket is the new kid in the block. So typical request-response cycle initiated always from HTTP clients (like a browser) is gone. Websocket brings in more responsive communication to the web. But, you can't test WebSockets directly from the browser (the way we do for HTTP). This post, I will provide some hacks to simplify your WebSocket development by enabling easier testing.

Does your browser supports WebSocket

Not all browsers support WebSockets, so before testing the service make sure your browser has support for it. One quick way is, ping a WebSocket hosted on the public web from your browser.  How about testing a public WebSocket service from your browser? Launch below URL and just test it out (Make sure you have internet connectivity):

https://www.websocket.org/echo.html

simple, if you are able to ping the service; you have support in your browser!
You can also check your browser support over, here.   

Test a WebSocket service 

You have written a WebSocket service, now how do you know if it's all good and working. You might end up writing a client in your favorite language (Java / JavaScript). This is overhead!

To make testing easier without writing much code we can use browser plugins. Chrome provides a plugin for testing web socket (there might be an equivalent plugin for other browsers as well). Just install the plugin in chrome and you are all set to test your service. Once it's installed you will notice a small icon (ws) next to search text field. 

Click that link and you have a client for testing WebSockets. Enter your WebSocket URL as shown below and open connection. Once the connection is opened you can keep sending messages to the server and receiving the message from the server. I have shown my own WebSocket service named as helloWebSocket. 

That's it!

---
Live WebSocket echo server: http://www.websocket.org/echo.html

Websocket in Java

Covered the fundamentals of web sockets (vs HTTP) in the previous post, here. 

WebSocket protocol is part of HTML5 specification to provide full-duplex bi-directional communication channel over single TCP socket. It got added in Java EE version 7 (JRS 356). In this post, I will dig dipper into WebSockets and how can we implement it in Java. 

WebSocket uses HTTP connection to bootstrap itself. HTTP sends a normal request to initiate WebSocket connection but it has upgrade header (wiki link). Through this upgrade header, clients say that it would like to upgrade current HTTP connection to a different protocol connection.  If sever has support for it websocket connection gets established. Once the connection is established, both ends can transfer data.

Life Cycle of WebSockets

1. The client sends an HTTP request to the server with an upgrade header having value websocket.
2. If Server supports WebSockets then it responds with HTTP header having status code 101, which means now onwards the connection is upgraded to WebSockets (no more HTTP).
3. Now both client and server can send any number of messages to each other.  Server needs to obtain the session object to send message to client. 

Image Source

Client Request

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

Server Response

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

Implementation

Specification JRS 356, covers standards for Java client side as well as server-side WebSocket implementation. This is part of Java EE 7, so all Java EE 7 compliant application servers should provide WebSockets support. There are also independent libraries/jars which can be used to support this feature on non EE 7 compliant servers. 

Any POJO class can be turned into a WebSocket server endpoint by annotating it properly. As shown in below diagram, the class needs to be annotated with @ServerEndPoint and specify URL as the value. You just need to provide implementations of the callback methods which will be called appropriately during the lifespan of the connection. Your server will ensure that these methods get invoked appropriately.

Just like a server endpoint, client endpoint can also be created in Java by annotating the class with @ClientEndPoint and by providing implementations of lifecycle methods. WebSocket client endpoint initiates the connection and WebSocket server endpoints await for the request and establish it. Once the connection is established the request data will be received in the onMessage callback method. So this is the place where business logic will be put. Both client and server can keep sending the data to the other party unless the connection is closed.

Over the internet, clients will mostly be a browser, so make sure that your browser supports this. Both endpoints (client and server) have callback listeners- onOpen, onMessage, onError, onClose.

Please refer to this link which describes steps to create WebSocket in Java.

I have also hosted a hello world WebSocket application on GitHub (websockets).

Security

This is a new technology and hence concern for security is legitimate. Here is a nice article which covers some of the important aspects. 

Final Note

1. WebSocket protocol is supported in major browsers- Chrome, IE, Firefox, Safari. It also requires support from the server web app. Check for its support on your Android/iOS version if you want to use it for the mobile client. 
2. It opens connections on TCP port 80. 
3. WebSockets transmissions are described as messages, where a single message can be optionally split across several data frames. 
4. Good to validate Origin header before establishing connection on server side to avoid any security threat. 
5. WebSocket protocol defines a ws:// and wss:// prefix to indicate a WebSocket and a secure WebSocket connection, respectively. 
6. WebSocket is stateful (unlike http which is stateless), so it doesn't scale up nicely. 
7. One of the issue with WebSockets is that, what if proxy times out connection after some inactivity? Client and server should re-handshake to ensure that connections gets established again. 
8. Another legitimate question is, what if either of proxy or browser doesn't support it. You can use portable frameworks like Atmosphere. It transparently falls back to HTTP in such case. 

References:

https://blog.openshift.com/how-to-build-java-websocket-applications-using-the-jsr-356-api/
https://github.com/Atmosphere/atmosphere/wiki/Supported-WebServers-and-Browsers
https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_servers

---
keep coding !

HTTP vs WebSockets

HTTP is like walkie-talkie; data transmission can happen from only one direction at a time. WebSocket is like a telephone; data transmission can happen from both direction at the same time. 

Walkie-Talkie / HTTP

Telephone / WebSocket

Image source

HTTP

In HTTP both ends can transfer data but only one at a time. HTTP clients (like browsers) asks for data from the server by sending the request and then the server parses the request, understands it and responds appropriately by transferring response data back to the client. HTTP was designed to be half-duplex. 

HTTP was not designed to be highly interactive. This means if the server has some new data to push to a client, it waits for client to ask for it. The server has no way to just transfer the data as and when it wishes. There are work-arounds to overcome this limitation like polling and long-polling. In polling, the client keeps making request to the server in regular intervals and server responds back if there is any data available, otherwise, the request gets ignored by the server. In long-polling client makes a call and server keeps connections open and waits for a fixed time for data to be available and then responds back to the client (or times out). Long polling is also known as Comet. Clearly, both alternatives for interactive communication (from both-ends) are not efficient and not ideal of real-time applications like chat.

WebSocket

Above limitations clearly, suggest that there was a need for more reliable bi-directional (full-duplex) communication between two endpoints (in web-world known as client and server). WebSockets allows bi-directional communication from both ends at the same time. This means, even servers can create connection and push data to a client.  It enables more interactive and real-time communication between client and server. WebSocket packets are lightweight compared to HTTP packets and in a single connections client/server can push multiple messages. So, it's more efficient than HTTP.

Note:  Both HTTP, as well as WebSockets, use TCP.

References:
http://www.html5rocks.com/en/tutorials/websockets/basics/