Thursday, August 22, 2013

In the DB schema of a previous project (which was a 10 year old legacy system), there was a table with a set of attributes listed as rows instead of columns as shown below.

When asked why, it was told that there was a client request to add additional parameters to the product entity, but adding a new column was not feasible since the table contained millions of records. Instead they opted for this solution as a workaround. Two new tables were added and the "Product_Config_Param_Def" contained the new parameter definitions and "Product_Config_Param_Value" contained the corresponding values. This was flexible and allowed adding many more parameters without having to add columns. And the plus point is when there are products that don't have the entire set of parameters, we don't need to populate DB with nulls.

This is what is known as "Entity-Attribute-Value" Modeling (EAV) and it's a great way for us to get closer to the benefits offered by No SQL DBS with our relational DBs. No SQL DB of course offer us unlimited flexibility in adding dynamic attributes and is the way to go if our entities have large amount of varying attributes (In other words, when entities have different sets of attributes) and the relationships between entities is rather limited (Think FB accounts).

With EAV, data is modeled as attribute-value pairs.

EAV should be used with caution. Many identify it as an anti-pattern. It can be such a performance hit. If I may copy the example mentioned in http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html

Sunday, August 4, 2013

Web service interface is defined using a Service Endpoint Interface (SEI) and the WSDL is generated from it. Steps
1. Implement & annotate the SEI.
2. Implement other requisite Java classes.
- Any data types referenced by the SEI.
- The implementation of the SEI. 3. Instantiate the Web service endpoint.
4. Generate the WSDL

1. Implement & annotate the SEI.

SEI is used as the;
• Base type of the Web service implementation (server side)—you define the Web service by implementing the SEI.
• Proxy type (client side)—on the client side, you use the SEI to invoke operations on the client proxy object.
• Basis for generating the WSDL contract—in the Java-first approach, you generate the WSDL contract by converting the SEI to WSDL.

In order to use the standard JAX-WS frontend, the SEI must be annotated with the @WebService annotation. Annotations are also used to customize the mapping from Java to WSDL.

When you run the Java-to-WSDL compiler on the SEI, it converts not only the SEI, but also the classes referenced as parameters or return values. The parameter types must be convertible to XML, otherwise it would not be possible for WSDL operations to send or to receive those data types. In fact, when you run the Java-to-WSDL compiler, it is typically necessary to convert an entire tree of related classes to XML using the standard JAX-B encoding.

In Apache CXF, you create a WS endpoint by defining a jaxws:endpoint element in XML. The WS endpoint is effectively the runtime representation of the Web service: it opens an IP port to listen for SOAP/HTTP requests, is responsible for marshalling and unmarshalling messages (making use of the
generated Java stub code), and routes incoming requests to the relevant methods on the implementor class.

jaxws:endpoint => To integrate a WS endpoint with a Java implementation class.
cxf:cxfEndpoint => To integrate a WS endpoint with a Camel route.

Creating a Web service in Spring XML consists of the following two steps:
1. Create an instance of the implementor class, using the Spring bean element.
2. Create a WS endpoint, using the jaxws:endpoint element.

4. Generate the WSDL

To generate a WSDL contract from your SEI, you can use either the java2ws command-line utility or the cxf-java2ws-plugin Maven plug-in. Plug-in approached is given below.