What’s New in SQL Server 2008

SQL Server 2008 delivers on the Microsoft data platform vision by enabling organizations to run their most mission-critical applications while lowering the cost of managing the data infrastructure and delivering insights and information to all users. This platform has the following qualities:

• Trusted—Enables organizations to run their most critical applications with very high levels of security, reliability, and scalability.

• Productive—Enables organizations to reduce the time and cost required to develop and manage their data infrastructure.

• Intelligent—Provides a comprehensive platform that delivers insights and information where your users want it.

TrustedIn today’s data-driven world, organizations need continuous access to their data. SQL Server 2008 provides robust security features, reliability, and scalability for mission-critical applications.

Protect Your InformationBuilding on the proven strengths of SQL Server 2005, SQL Server 2008 extends its security capabilities with the following enhancements:

Transparent Data Encryption:
SQL Server 2008 enables encryption of entire databases, data files, and log files, without the need for application changes. Encryption enables organizations to meet the demands of regulatory compliance and overall concern for data privacy. Some of the benefits of transparent data encryption include searching encrypted data using either range or fuzzy searches, more secure data from unauthorized users, and data encryption. These can be enabled without changing existing applications.

External Key ManagementSQL Server 2008 provides a comprehensive solution for encryption and key management. To meet the growing need for greater security of information within data centers, organizations have invested in vendors to manage security keys within the enterprise. SQL Server 2008 provides excellent support for this need by supporting third-party key management and hardware security module (HSM) products.

Enhanced AuditingSQL Server 2008 improves compliance and security by allowing you to audit activity on your data. Auditing can include information about when data has been read, in addition to any data modifications. SQL Server 2008 has features such as enhanced configuration and management of audits in the server, which enable organizations to meet varied compliance needs. SQL Server 2008 can also define audit specifications in each database, so audit configuration can be ported with databases. Filtering of audits to specific objects allows better performance in audit generation and flexibility in configuration.

Ensure Business ContinuityWith SQL Server 2008, Microsoft continues to give organizations the ability to provide highly reliable applications with simplified management.

Enhanced Database MirroringSQL Server 2008 builds on SQL Server 2005 by providing a more reliable platform that has enhanced database mirroring. New features include:

• Automatic page repair. SQL Server 2008 enables the principal and mirror computers to transparently recover from 823 and 824 errors on data pages by requesting a fresh copy of the corrupted page from the mirroring partner.

• Improved performance. SQL Server 2008 compresses the outgoing log stream in order to minimize the network bandwidth required by database mirroring.

• Enhanced supportability

• SQL Server 2008 includes additional performance counters to enable more granular accounting of the time spent across the different stages of Database Management System (DBMS) log processing.

• SQL Server 2008 includes new Dynamic Management Views and extensions of existing views to expose additional information about mirroring sessions.

Hot Add CPUExtending existing support in SQL Server for adding memory resources online, Hot Add CPU allows a database to be scaled on demand. In fact, CPU resources can be added to SQL Server 2008 on supported hardware platforms without requiring application downtime.

Optimized and Predictable System PerformanceOrganizations are faced with growing pressure to provide predictable response and to manage increasing volumes of data for growing numbers of users. SQL Server 2008 provides a comprehensive set of features to provide scalable and predictable performance for any workload on your data platform.

Performance data collectionPerformance tuning and troubleshooting are time-consuming tasks for the administrator. To provide actionable performance insights to administrators, SQL Server 2008

centralized data repository for storing performance data, and new reporting and monitoring tools.
Extended EventsSQL Server Extended Events is a general event-handling system for server systems. The Extended Events infrastructure is a lightweight mechanism that supports capturing, filtering, and acting upon events generated by the server process. This ability to act upon events allows users to quickly diagnose run time problems by adding contextual data, such as Transact SQL call stacks or query plan handles, to any event. Events can be captured into several different output types, including Event Tracing for Windows (ETW). When Extended Events are output to ETW, correlation with operating system and database applications is possible, allowing for more holistic system tracing.

Backup compressionKeeping disk-based backups online is expensive and time consuming. With SQL Server 2008 backup compression, less disk I/O is required, less storage is required to keep backups online, and backups run significantly faster.

Data compressionImproved data compression enables data to be stored more effectively and reduces the storage requirements for your data. Data compression also provides significant performance improvements for large input/output-bound workloads such as data warehousing.
Resource GovernorSQL Server 2008 enables organizations to provide a consistent and predictable response to end users with the introduction of Resource Governor. Resource Governor enables database administrators to define resource limits and priorities for different workloads, which enables concurrent workloads to provide consistent performance to end users.
Plan FreezingSQL Server 2008 enables greater query performance stability and predictability by providing new functionality to lock down query plans, enabling organizations to promote stable query plans across hardware server replacements, server upgrades, and production deployments.

Business Intelligence – SQL Server 2005

SQL Server 2005 furthers Microsoft leadership in the area of business intelligence (BI) through innovations in scalability, data integration, development tools, and rich analytics. SQL Server 2005 enables scalable BI by putting critical, timely information in the hands of employees across your organization. From the CEO to the information worker, employees will be able to quickly and easily harness data to make better decisions faster.

The comprehensive integration, analysis, and reporting capabilities of SQL Server 2005 enable companies to extend the value of their existing applications, regardless of the underlying platform. BI features include enhancements in the following areas:

• An end-to-end integrated business intelligence platform
• Integration Services
• Analysis Services
• Reporting Services
• Integration with the Microsoft Office System

End-to-End Integrated Business Intelligence Platform
SQL Server 2005 is a complete BI platform that provides the features, tools, and functionality to build both classic and innovative kinds of analytical applications. The following information introduces the tools that you will use to build an analytical application, and highlights new functionality that makes it easier than ever to build and manage complex BI systems.The SQL Server 2005 BI toolset delivers end-to-end BI application integration:

• Design. Business Intelligence Development Studio is the first integrated development environment designed for the BI developer. Built on Visual Studio 2005, Business Intelligence Development Studio delivers a rich, integrated, professional development platform for BI system developers. Debugging, source control, and script and code development are available for all components of the BI platform.

• Integrate. SQL Server Integration Services (SSIS) has been rewritten to perform complex data integration, transformation, and synthesis at high speed for very large data volumes. Business Intelligence Development Studio makes building and debugging packages positively fun. Integration Services, Analysis Services, and Reporting Services work together to present a seamless view of data from heterogeneous sources.

• Analyze. Microsoft Data Mining has always been easy to use. Now it is even better with the addition of important new algorithms, including Association Rules, Time Series, Regression Trees, Sequence Clustering, Neural Network, and Naïve Bayes. SQL Server 2005 blurs the lines between relational and multidimensional databases. You can store data in the relational database, in the multidimensional database, or use the new Proactive Cache feature to get the best of both worlds. Important new analytical capabilities have been added to Analysis Services cubes as well; these include key performance indicator (KPI) framework, MDX scripts, and other built-in advanced business analytics. The Reporting Services report delivery and management framework enables easy distribution of complex analytics to the widest possible audience.

• Report. Reporting Services extends the Microsoft BI platform to reach the business user who needs to consume the analysis. Reporting Services is an enterprise-managed reporting environment, embedded and managed through Web services. Reports can be personalized and delivered in a variety of formats, with a range of interactivity and printing options. Complex analyses can reach a broad audience through the distribution of reports as a data source for downstream BI. New with SQL Server 2005 is the reporting tool, Report Builder.

• Manage. SQL Server Management Studio integrates the management of all SQL Server 2005 components. BI practitioners will benefit from this extension of the server abilities you expect from the relational engine—scalability, reliability, availability, programmability, and so on—to the full set of BI platform components.

Integration Services:SQL Server 2005 includes a redesigned enterprise data extraction, transformation, and loading (ETL) platform, called SQL Server Integration Services (SSIS). SSIS enables organizations to more easily integrate and analyze data from multiple heterogeneous information sources. By analyzing data across an array of operational systems, organizations may gain a competitive edge through a holistic understanding of their business.

Enterprise ETL Platform:This new platform is the successor to the popular feature in SQL Server 2000 called Data Transformation Services (DTS). SSIS is completely new for SQL Server 2005. SSIS provides the breadth of features and very high-scale performance that is necessary to build enterprise-class ETL applications. SSIS is fully programmable, embeddable, and extensible—characteristics that make it an ideal ETL platform.

Beyond Traditional ETL:SQL Server 2005 supports nontraditional data (Web Services, XML) out of the box, in the following ways:

• SSIS brings analytics to the data without persisting the data.
• Data mining and text mining can be done in the data flow.
• Data mining and analytics are brought to the data flow for data quality and data cleansing.

Analysis Services:With SQL Server 2005, Analysis Services provides, for the first time, a unified and integrated view of all your business data as the foundation for your traditional reporting, online analytical processing (OLAP) analysis, and data mining.

Unified Dimensional Model:By combining the best aspects of traditional OLAP analysis and relational reporting, Analysis Services provides a metadata model that covers both sets of needs. A set of cubes and dimensions defined in Analysis Services is referred to as a Unified Dimensional Model (UDM). The UDM is a central metadata repository defining business entities, business logic, calculations, and metrics that serves as the source for all reports, spreadsheets, OLAP browsers, KPIs, and analytical applications.

Using the powerful new Data Source View feature, the UDM is mapped to a host of heterogeneous back-end data sources, providing a complete and integrated picture of the business regardless of the location of the data.With the UDM's friendly descriptions of the business entities, navigation hierarchies, multiple perspectives, and even automatic translations to native languages, users will find it easy to explore the corporate business data.

Data Mining:-SQL Server 2005 Data Mining is the BI technology that helps you build complex analytical models, and integrate those models with your business operations. Analysis Services establishes new ground for data mining. By creating an easy-to-use, extensible, accessible, and flexible platform, Analysis Services data mining capabilities introduce data mining to organizations that previously would never have considered a data mining solution.

Through enterprise-class architecture, a deep integration with the SQL Server family of BI tools, and a rich set of other tools, APIs, and algorithms, SQL Server enables the creation of a new breed of intelligent applications that enhance productivity, increase profits, and reduce costs by providing customized data-driven solutions to a broad range of business problems.

Reporting Services:Reporting Services extends the Microsoft BI platform to reach the information worker who needs access to business data. Reporting Services is a server-based enterprise reporting environment, managed through Web services. Reports can be delivered in a variety of formats, with a range of interactivity and printing options. Complex analyses can reach a broad audience through the distribution of reports as a data source for downstream BI.
As an integrated component of SQL Server 2005, Reporting Services provides the following:

• A high-performance engine for processing and formatting reports.
• A complete set of tools for creating, managing, and viewing reports.
• An extensible architecture and open interfaces for embedding reports or integrating reporting solutions in diverse IT environments.

Relational and OLAP Reports:Reports built on relational data are useful but the ability to add additional analytic capabilities makes such reporting powerful. Reporting Services allows you to easily build reports together or separately. SQL Server 2005 supports both relational and OLAP data and provides a query editor for both, including SQL Query Editor and MDX Query Editor.

Report Builder:Report Builder, a new component of SQL Server 2005 Reporting Services, allows business users to create their own reports using a user-friendly model of their data. Report Builder takes advantage of the Reporting Services platform to bring ad hoc reporting to all end users. Users create and edit reports with the Report Builder client application. The Report Builder user interface is built on top of familiar Microsoft Office paradigms such as Microsoft Excel and Microsoft PowerPoint.



Figure 6: Design Reports with Report Builder

Report Builder is a ClickOnce application deployed through the browser. Users start by selecting report layout templates containing predefined data sections such as tables, matrices, and charts. They drag and drop report items from the model to the design surface and set constraints to filter the report data. The model contains all of the necessary information for the Report Builder to automatically generate the source query and retrieve the requested data. The Report Builder also allows users to:
• Add text and formatting to reports.
• Create new fields and calculations defined using the model.
• Preview, print, and publish reports.
• Export report data to formats such as Microsoft Excel.

Integration with the Microsoft Office System:Reports served up by the Report Server in Reporting Services can run in the context of Microsoft SharePoint Portal Server and Microsoft Office System applications such as Microsoft Word and Microsoft Excel. You can use SharePoint features to subscribe to reports, create new versions of reports, and
distribute reports. You can also open reports in Word or Excel to view HTML versions of reports.

The EJB Query Language (EJB-QL) -Part 3

The EJB Query Language (EJB-QL)
Part -3
EJB-QL also contains the following built-in functions:
CONCAT(String, String) combines two strings into one and returns a String.
SUBSTRING(String, start, length) cuts a String into a smaller String, beginning at start and being length long.
LOCATE(String, String [, start]) returns an int denoting where a String is located within another String. You can use the optional start parameter to indicate where to begin locating.
LENGTH(String) gives you a string's length, returned as an int.
ABS(number) returns the absolute value of a number, which can be an int, float, or double.
SQRT(double) takes the square-root of a number and returns it as a double.

Dealing with collections
Normally if you want to use collections in the WHERE clause, you should declare those collections as variables in the FROM clause. For example, the following is invalid:

SELECT OBJECT(l)
FROM Order AS o
WHERE o.lineItems.product.name = 'chip'

The above is invalid because we are trying to reference a variable from a collection. The following is the correct way to write this EJB-QL:

SELECT OBJECT(l)
FROM Order AS o, IN(o.lineItems) l
WHERE l.product.name = 'chip'

The two special exceptions to this rule are when you use the EMPTY or MEMBER conditional expressions, shown in Table X.X. In these cases, you can use collections in the WHERE clause.

Performing comparisons
Sometimes you may need to declare more than one variable that represents the same entity bean. When you are performing comparisons this comes in very handy. For example:

SELECT OBJECT(p1)
FROM Product p1, Product p2
WHERE p1.quantityInStock > p2.quantityInStock AND
p2.name='Pentium 866'

The above query finds all products that have a greater quantity in-stock than a Pentium 866 chip.
The SELECT clause
The EJB-QL SELECT clause specifies the return results of a query. To understand why we need the SELECT clause, consider the following query, which returns all orders that contain line-items:
SELECT OBJECT(o)
FROM Order AS o, IN(o.lineItems) l
In this query, we have defined two variables in the FROM clause: o and l. The SELECT clause is necessary because it affirms that we want to return o (and not l) to the client who called the query.

How to traverse relationships
The SELECT clause can traverse relationships. For example, the following query returns all the products in all the orders that contain line-items:
SELECT l.product FROM Order AS o, IN(o.lineItems) l

As you can see, we can use the convenient dot-notation to traverse relationships in the SELET clause. Behind the scenes, a SQL JOIN statement might occur.

If you've been paying careful attention, you may have noticed that in the earlier example we wrapped a variable o with the phrase OBJECT(), but in this example, we didn't use the phrase OBJECT() at all. The EJB-QL rule is that you only wrap your return result with the phrase OBJECT() if you are returning a standalone variable that does not traverse a relationship using the dot-notation.

How to deal with collections
Let's say we want to find all line-items on all orders. We are thus asking for a collection of return results. Unfortunately, the following SELECT clause will not work:

SELECT o.lineItems
FROM Order AS o

The reason the above doesn't work is because SELECT clauses may only return single variables, not collections. To get around this restriction, you need to define a variable in the FROM clause. The following demonstrates this as a legal way to find all line-items on all orders:

SELECT OBJECT(l)
FROM Order AS o, IN(o.lineItems) l

How to filter for duplicates
You can control whether SELECT clauses return duplicates. For example, take our previous EJB-QL query that finds all products in all order line-items:

SELECT l.product FROM Order AS o, IN(o.lineItems) l

The above query may return duplicate products, because two different people may have ordered the same product. To get a unique list, you must apply the DISTINCT filter, as follows:

SELECT DISTINCT l.product FROM Order AS o, IN(o.lineItems) l

Another choice you have is to declare your finder or select method to return a java.util.Set, which may not contain duplicates compared to a java.util.Collection. If you use a java.util.Set, then both of the above EJB-QL statements would return the same unique results.

How to control what gets returned in finders
EJB-QL queries return results differently depending on how the client initiates the query. For example, take the following finder queries (thrown exceptions omitted):

// declared on the home interface
public java.util.Collection findAllProducts();

// declared on the local home interface
public java.util.Collection findAllProducts();

We want EJB objects to be returned for the first query, and EJB local objects to be returned for the second query. The EJB-QL code in the deployment descriptor for both of these query methods could be:
findAllProducts

What's great here is that we wrote our EJB-QL once, yet we can reuse it for both the home interface and local home interface. The container will automatically wrap the return results in an EJBObject or EJBLocalObject, respectively. These are the only possible types you can return from a finder query.

How to control what gets returned in selects
With finder methods, the container knows whether the results of a finder should be EJB objects or EJB local objects, because the container could look at whether the query was defined on the home interface or local home interface, respectively. But what about ejbSelect() methods?

Consider the following ejbSelect():
public abstract java.util.Collection ejbSelectAllProducts();

Here, we define the ejbSelect() method on the entity bean class, which doesn't give the container any information about whether our query should return EJB objects or EJB local objects. How does the container know what objects to wrap around the results?

To get around this, EJB requires that you setup a special stanza in the deployment descriptor to inform the container about whether the results should be local or remote objects:
ejbSelectAllProducts Local
The above code will cause the ejbSelect() method to return a collection of EJB local objects. If you want the results to be a collection of EJB objects, then change the result-type-mapping element to have the value Remote.

Finally, note that ejbSelect() methods can also return container-managed fields.
For example:
public java.lang.String ejbSelectProductName();

Finder methods cannot return container-managed fields because finder methods operate remotely and at the granularity of entity beans, not parts of entity beans.

Truth Tables
Let's wrap-up our EJB-QL lesson with a look at the truth tables for how the operations AND, OR, and NOT evaluate. In the tables, the case of unknown means expressions that produce an unknown result, such as the clause:
WHERE NULL IN ('Intel', 'Sun')

AND	True	False	Unknown
True	True	False	Unknown
False	False	False	False
Unknown	Unknown	False	Unknown

Table X.X The AND truth table.

OR	True	False	Unknown
True	True	True	True
False	True	False	Unknown
Unknown	True	Unknown	Unknown

Table X.X The OR truth table.







Table X.X The NOT truth table.

NOT
True	False
False	True
Unknown	Unknown

The EJB Query Language (EJB-QL) -Part 2

The EJB Query Language (EJB-QL)

Part -2
EJB-QL Syntax
An EJB-QL query contains three parts:
1. A required SELECT clause
2. A required FROM clause
3. An optional WHERE clause

We now discuss the intimate details of each of these clauses. We'll do the SELECT clause last because that indicates the return results of a query.

The FROM clause
The FROM clause constricts the domain of a query. It indicates what part of the data storage you are querying over--that is, what entity beans you are going to be looking at. In the case of a relational database, the FROM clause would typically restrict which tables you are querying over. For example, the following FROM clause means we are only looking at Order entity beans:

SELECT OBJECT(o)
FROM Order AS o

What we're doing here is declaring a variable in the FROM clause. We are creating a variable, o, which can be used later in the query. In this case, we are re-using that variable in the SELECT clause. You can also re-use that variable in the WHERE clause.

Note that declaring variables will restrict your queries even if you don't use the variables. For example:

SELECT OBJECT(o)
FROM Order AS o, Customer AS c

The above query finds all orders that have customers. Even though we aren't using the variable c anywhere else, we are still excluding orders without customers.

Finally, you should note that the phrase AS is optional and is merely syntactic sugar to help make the query look better. This query produces the same result as the previous one:

SELECT OBJECT(o)
FROM Order o, Customer c

Declaring collection variables
Sometimes you need to declare variables in the FROM clause that represent a collection of values. For example, let's say we want to find all of the line-items which are attached to orders. The following query achieves that:

SELECT OBJECT(l)
FROM Order AS o, IN(o.lineItems) l
The above EJB-QL declares two variables.
· The phrase Order AS o declares a variable o that represents any order entity bean.
· The phrase IN(o.lineItems) l declares a variable l that represents any line-item linked off any order bean.
Thus, you use the AS syntax when declaring a variable representing a single value, and the IN syntax when declaring a variable representing a collection of values. And since the evaluation order is left-to-right, you can use variables on the right that were declared on the left.

Variables only represent one value at a time
Next, consider the following query, which returns all line-items that are attached to orders which are attached to customers:

SELECT OBJECT(l)
FROM Customer AS c, IN(c.orders) o, IN(o.lineItems) l

Notice the phrase o.lineItems. While o is a collection variable, it only represents one element of that collection at a time. Thus it is perfectly legal to use the phrase o.lineItems because in that phrase, o represents an individual order, not a collection of orders.

The WHERE clause
The EJB-QL WHERE clause restricts the results of a query. It is where you choose the values you want from the declared variables in the FROM clause. The general syntax of the WHERE clause is "WHERE ". For example:
SELECT OBJECT(o)
FROM Order o
WHERE o.lineItems IS NOT EMPTY

The above query finds all orders that have line-items.

Handling Input Parameters
When performing a query, often times you'll want to query based upon parameters supplied by the client.
For example, to implement the following finder method which finds a product based on a description:
findProductByDescription(String s)
A WHERE clause can be used as follows:
SELECT OBJECT(p)
FROM Product p
WHERE p.description = ?1
Here, ?1 represents the first parameter passed-in. Additional parameters would be numbered as ?2, ?3, and so-on. Note that you don't need to use all variables declared in the finder/select method.

Conditional Expressions
There are many conditional expressions that are built-in to EJB-QL. Here is the complete list.@@@COMP: The CODE is inside the TB@@@

Conditional Expression	Example	Notes
Mathematical operations: +, -, *, / Comparison operations: =, >, >=, <, <=, <> (not equal) Logical operators: NOT, AND, OR	Find all products that are computer chips and whose profit margin is positive: SELECT OBJECT(p) FROM Product p WHERE (p.description = "chip") AND (p.basePrice - p.cost > 0)	· Two entity beans are equal if and only if they share the same primary key value. · You cannot compare two different entity bean classes.
Between expressions	Find all products whose price is at least 1000 and at most 2000: SELECT OBJECT(p) FROM Product p WHERE p.basePrice BETWEEN 1000 AND 2000	Can also use NOT BETWEEN to return all data that is not between two values.
In expressions	Find all products whose manufacturer is either Intel or Sun: SELECT OBJECT(p) FROM Product p WHERE p.manufacturer IN ('Intel', 'Sun')	Can also use NOT IN to return all data that is not in a range.
Like expressions	Find all products with ids that begin with '12' and end with '3'. For example, '123' or '12993' qualifies, but not '1234': SELECT OBJECT(p) FROM Product p WHERE product.productID LIKE '12%3' Find all products with ids that begin with '123' and are a total of four characters long. For example, '123c' qualifies, but not '14' nor '12345': SELECT OBJECT(p) FROM Product p WHERE product.productID LIKE '123_'	· % stands for any sequence of zero or more characters · _ stands for a single character · You can represent the literal % or _ character by using special escape sequences (see the EJB spec for more) · You can also use NOT LIKE to achieve the opposite effect
Null comparison expressions	Find all products that have NULL descriptions: SELECT OBJECT(p) FROM Product p WHERE product.description IS NULL	You can also use NOT NULL to find all data that has non-NULL values.
Empty collection comparison expressions	Find all orders that have no line-items: SELECT OBJECT(o) FROM Order o WHERE o.lineItems IS EMPTY	· You can also use IS NOT EMPTY to find valid collections. · In this special case, you can declare collections in the WHERE clause rather than declaring them as variables first in the FROM clause
Collection member expressions	Find all line-items that are attached to orders: SELECT OBJECT(l) FROM Order o, LineItem l WHERE l MEMBER OF o.lineItems	· The word OF is optional · In this special case, you can declare collections in the WHERE clause rather than declaring them as variables first in the FROM clause · Can also use NOT MEMBER OF to locate data where elements are not members of collections

Table X.X EJB-QL Conditional Expressions
Note that you can have more than one conditional expression, and use parenthesis to denote order of execution. Your container may provide proprietary extensions to these conditional expressions as well, perhaps in a separate deployment descriptor.

The EJB Query Language (EJB-QL) - Part 1

The EJB Query Language (EJB-QL)

Part -1
In this article, we will fully understand the syntax and semantics of the EJB Query Language (EJB-QL), which is the language that you use to describe query methods for container-managed persistent entity beans.

Overview
EJB-QL is a standard and portable language for expressing container-managed persistent entity bean query operations. These entity bean query operations can include finder methods (used by external entity bean clients), as well as select methods (used internally by the entity bean itself). EJB-QL is not necessary for bean-managed persistence because the bean provider writes the database access code, which is integrated into the entity bean class itself.

EJB-QL is a new addition to EJB 2.0. Before EJB 2.0, you would need to explain to the container how to implement your query operations in a proprietary way.

For example, you might bundle a container-specific flat-file with your bean. This flat-file would not be portable to other containers, which is very annoying for bean-providers who wish to write components that are container-agnostic.

Throughout this appendix, we will use an E-Commerce object model to illustrate EJB-QL, using such entity beans as orders, line-items, products, and customers. We designed that object model in Chapter X.

A simple example
Let's kick things off with a simple EJB-QL example. Take the following entity bean remote finder method:
public java.util.Collection findAvailableProducts() throws FinderException, RemoteException;
This finder method means to find all products that are currently in-stock.

The following EJB-QL in the deployment descriptor will instruct the container on how to generate the database access code that corresponds to this finder method:
...


Product
examples.ProductHome
examples.Product
examples.ProductBean
Container
examples.ProductPK
False

2.x
Product


inventory

...more container-managed persistent fields...



findAvailableProducts




0]]>



...

In the code above, we are putting together a query that resembles SQL or ORQL (see Chapter X for more on OQL). We can refer to entity beans inside of the EJB-QL by using that entity bean's abstract-schema-name defined earlier in the deployment descriptor. We can also query its container-managed fields or container-managed relationships, or other entity beans.

In fact, if we're using a relational database, the container will translate this EJB-QL code into SQL code in the form of JDBC statements.

The following SQL is an example of what might be generated depending on your container implementation:

SELECT DISTINCT p.PKEY
FROM PRODUCT p
WHERE p.INVENTORY > 0

The above SQL returns primary keys (not rows) back to the container. The container than wraps those primary keys in EJB objects and returns RMI-IIOP stubs to the client who called the finder method. When the client calls business methods on those stubs, the EJB objects will intercept the call, and then the ejbLoad() method will be called on the entity beans.

The container will then load the actual rows from the database. Note that this process may be optimized depending on your container implementation.

The power of relationships
The big difference between EJB-QL and SQL is that EJB-QL allows you to traverse relationships between entity beans using a dot-notation. For example:

SELECT o.customer
FROM Order o

In the above EJB-QL, we are returning all customers that have placed orders. We are navigating from the order entity bean to the customer entity bean easily using a dot-notation. This is quite seamless.

What's exciting about this notation is that bean providers don't need to know about tables or columns, rather they merely need to understand the relationships between the entity beans that they've authored. The container will handle the traversal of relationships for us because we declare our entity beans in the same deployment descriptor and ejb-jar file, empowering the container to manage all of our beans and thus understand their relationships.

In fact, you can traverse more than one relationship. That relationship can involve container-managed relationship fields and container-managed persistent fields. For example:

SELECT o.customer.address.homePhoneNumber
FROM Order o

The restriction on this type of recursive relationship traversal is that you are limited by the navigatability of the relationships that you define in the deployment descriptor. For example, let's say that in the deployment descriptor, you declare that orders have a 1-to-many relationship with line-items, but you do not define the reverse many-to-1 relationship that line-items have with orders. When performing EJB-QL, you can then get from orders to line-items, but not from line-items to orders. For more about how to define these types of relationships, see Chapter X in next article.

Virtual Functions in C++

C++ virtual function is a member function of a class, whose functionality can be over-ridden in its derived classes.
The whole function body can be replaced with a new set of implementation in the derived class. The concept of c++ virtual functions is different from C++ Function overloading.

C++ Virtual Function - Properties:

C++ virtual function is,

• A member function of a class
• Declared with virtual keyword
• Usually has a different functionality in the derived class
• A function call is resolved at run-time

The difference between a non-virtual c++ member function and a virtual member function is, the non-virtual member functions are resolved at compile time.

This mechanism is called static binding. Where as the c++ virtual member functions are resolved during run-time. This mechanism is known as dynamic binding.

C++ Virtual Function - Reasons:
The most prominent reason why a C++ virtual function will be used is to have a different functionality in the derived class.

For example a Create function in a class Window may have to create a window with white background. But a class called CommandButton derived or inherited from Window, may have to use a gray background and write a caption on the center. The Create function for CommandButton now should have a functionality different from the one at the class called Window.

C++ Virtual function - Example:
This article assumes a base class named Window with a virtual member function named Create. The derived class name will be CommandButton, with our over ridden function Create.


class Window // Base class for C++ virtual function example
{

public : virtual void Create()

// virtual function for C++ virtual function example
{

cout <<"Base class Window";

}

}
class CommandButton : public Window
{

public:void Create()
{

cout<<"Derived class Command Button - Overridden C++ virtual function"

y = new CommandButton();

y->Create();

}

The output of the above program will be,
Base class Window
Derived class Command Button

If the function had not been declared virtual, then the base class function would have been called all the times. Because, the function address would have been statically bound during compile time. But now, as the function is declared virtual it is a candidate for run-time linking and the derived class function is being invoked.

C++ Virtual function - Call Mechanism:
Whenever a program has a C++ virtual function declared, a v-table is constructed for the class. The v-table consists of addresses to the virtual functions for classes and pointers to the functions from each of the objects of the derived class.

Whenever there is a function call made to the c++ virtual function, the v-table is used to resolve to the function address. This is how the Dynamic binding happens during a virtual function call.

JSP Model

JSP Model 1 and Model 2 Architectures

The early JSP specifications presented two approaches for building web applications using JSP technology. These two approaches were described in the specification as JSP Model 1 and Model 2 architectures.

Although the terms are no longer used in the JSP specification, their usage throughout the web tier development community is still widely used and referenced.

The two JSP architectures differed in several key areas.

The major difference was how and by which component the processing of a request was handled. With the Model 1 architecture, the JSP page handles all of the processing of the request and is also responsible for displaying the output to the client.

This is better seen in Figure 1-1.

Figure 1-1. JSP Model 1 Architecture

Notice that in Figure 1-1 there is no servlet involved in the process, the client request is sent directly to a JSP page, which may communicate with JavaBeans or other services, but ultimately the JSP page selects the next page for the client.
The next view is either determined based on the JSP selected or parameters within the client’s request.

In direct comparison to the Model 1 approach, in the Model 2 architecture, the client request is first intercepted by a servlet, most often referred to as a Controller servlet.
The servlet handles the initial processing of the request and also determines which JSP page to display next.
This approach is illustrated in Figure 1-2.

Figure 1-2. JSP Model 2 Architecture

As you can see from Figure 1-2, in the Model 2 architecture, a client never sends a request directly to a JSP page. The controller servlet acts as sort of a traffic cop. This allows the servlet to perform front-end processing like authentication and authorization, centralized logging, and possibly helps with Internationalization.

Once processing of the request has finished, the servlet directs the request to the appropriate JSP page. How exactly the next page is determined can vary widely across different applications, for example, in simpler applications, the next JSP page to display may be hard coded in the servlet based on the request, parameters, and current application state. In other more sophisticated web applications, a workflow/rules engine may be used.

As you can see, the main difference between the two approaches is that the Model 2 architecture introduces a controller servlet that provides a single point of entry and also encourages more reuse and extensibility than Model 1. With the Model 2 architecture, there is also a clear separation of the business logic, presentation output, and request processing.

This separation is often referred to as a Model-View-Controller (MVC) pattern. While the Model 2 architecture might seem overly complicated, it can actually simplify an application greatly. Web applications built using the Model 2 approach are generally easier to maintain and can be more extensible than comparable applications built around the Model 1 architecture.

All of this doesn’t mean that applications built using the Model 1 approach are incorrectly designed. The Model 1 architecture might be the best decision for smaller applications that have simple page navigation, no need for centralized features, and are fairly static.

However, for larger enterprise-size web applications, it would be more advantageous to utilize the Model 2 approach.