ANANDHAN SUBBIAH - INSPIRE AND INNOVATE

Google and Apple are in opposite ends of the spectrum in terms of management styles. Google allows the developers to innovate and Gmail and Google News emerged as the by products. Steve jobs rules Apple with a iron hand and we have seen the iphone and ipod make history. The founders of Hewlett Packard had a really different management style “management by walking”.It is really difficult to predict the best management style for a company and it is unique to each company in the way they operate and mostly a common sense approach is the order of the day. A management style which allows managed innovation and generates revenue and motivates employees to sustain them will be the best approach.

A certain type of forcefulness and perseverance is sometimes helpful when tackling large, intractable problems,” says Roderick Kramer, a social psychologist at Stanford who wrote an appreciation of “great intimidators” — including Jobs — for the February 2006 Harvard Business Review. I believe strongly in this approach. Sometimes you can get the best out of people only if you apply pressure. Some of them may not be able to handle the pressure but then they deserve to get out of the corporate world.

I believe that work is not the place to fool around ; you can innovate but there is a thin line between innovation and wasting valuable work time. It will be a mess if all the engineers think they have the perfect ideas to change the world. It is the job of the business to have plans to change the world and the engineers should support and execute on it. A good manager will have the ability to identify folks who can create and deliver at the same time but it will be extremely unhealthy if you have individuals who have a personal agenda which does not align with the business. In most cases it will backfire and the business has to incur a loss so the best thing to do is to to treat it like pollution and take steps to eradicate it.

Trust is a key issue in almost all aspects of life and the work place is no exception. The engineers should be able to trust the product / business teams to be able to execute on the vision. Plain talk used to do the trick but not anymore. Accountability and a track record of success is very important. If the engineers know that too many decisions will not be tolerated and the product is closely managed in terms of reveneue and overall goals with a lot of transparency then there will it will be a lot easier to establish that trust.

Accountability is a key factor. It does not mean that the individuals who are not able to deliver or make bad business /engineering choices should be fired but they should not be given more opportunities unless they improve. Instead someone who is more capable and a better track record should be given opportunities. Steps should also be taken to make sure mistakes don’t happen too often by setting up policies in place for review and audit.If there are too many mistakes and they are repetitive then the employees should be allowed to go else it might affect the overall business.

I believe history can help you make decisions , if the company has not been able to deliver new cutting-edge products after a year of innovation time then that company is not suited to accommodate this. It does not matter if the business or the engineers are responsible but if a policy does not work then the best choice is to move forward and try other avenues.

Budgets are another key aspect . I have seen companies lay off employees when things go wrong. I believe companies can do a lot more than taking the extreme step. A lot of money is wasted on software which is never used and large companies have a lot of hardware lying around which is never utilized. Buying a software with an expensive support plan without a proper usage plan is a nightmare most companies have to deal with. The best thing to do is have a clear audit policy. There should be a designated person analyzing and questioning these kind of requests. Before taking desperate measures it makes a lot of sense to limit internet bandwidth and telephone usage and limit anything else possible to save money. The company has to spend that much more money to get new employees and then train them on their applications before they can be useful.

Management styles are changing in the web2.0 world Microsoft allows its engineers to blog. The CEO of Sun announces lay offs and major decisions via his blog. But no matter how different management styles are the rule is simple; employees have to work hard to make sure they support the business to improve and generate revenue. The business should make sure that they provide the vision and the platform for the employees to be productive. The employer has to make sure the employees who perform and have a track record of success are rewarded and encouraged .

Hibernate filters provide you with a programmatic way to restrict the result of your query.The advantage is that you can programmatically change filters even though you can’t do it at runtime it is still a better approach. In the following code sample I created a filter called activatedFilter and added it to the User class. You can specify or define the attribute in the filter-def. In this case the filter is boolean. You can enable the filter using the session.enableFilter() API.

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE hibernate-mapping
   PUBLIC "-//Hibernate/Hibernate Mapping DTD//EN"
   "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
 
<hibernate-mapping>
  <class name="com.hibernatebook.filters.User">
    <id name="id" type="int">
      <generator class="native"/>
    </id>
 
    <property name="username" type="string" length="32"/>
    <property name="activated" type="boolean"/>
    <filter name="activatedFilter" condition=":activatedParam = activated"/>
  </class>
  <filter-def name="activatedFilter">
    <filter-param name="activatedParam" type="boolean"/>
  </filter-def>
</hibernate-mapping>



import java.util.Iterator;
 
import org.hibernate.Filter;
import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
 
import org.hibernate.cfg.Configuration;
 
public class SimpleFilterExample {
    public static void main (String args[]) {
        SessionFactory factory =
           new Configuration().configure().buildSessionFactory();
        Session session = factory.openSession();
 
        //insert the users
        insertUser("ray",true,session);
        insertUser("jason",true,session);
        insertUser("beth",false,session);
        insertUser("judy",false,session);
        insertUser("rob",false,session);
 
        //Show all users
        System.out.println("===ALL USERS===");
        displayUsers(session);
 
        //Show activated users
        Filter filter = session.enableFilter("activatedFilter");
        filter.setParameter("activatedParam",new Boolean(true));
        System.out.println("===ACTIVATED USERS===");
        displayUsers(session);
 
        //Show nonactivated users
        filter.setParameter("activatedParam",new Boolean(false));
        System.out.println("===NON-ACTIVATED USERS===");
        displayUsers(session);
 
       session.close();
   }
 
   public static void displayUsers(Session session) {
       session.beginTransaction();
       Query query = session.createQuery("from User");
       Iterator results = query.iterate();
       while (results.hasNext())
       {
           User user = (User) results.next();
           System.out.print(user.getUsername() + " is ");
           if (user.isActivated())
           {
               System.out.println("activated.");
           }
           else
           {
               System.out.println("not activated.");
           }
       }
 
       session.getTransaction().commit();
   }
 
   public static void insertUser(String name, boolean activated, Session session) {
       session.beginTransaction();
 
       User user = new User();
       user.setUsername(name);
       user.setActivated(activated);
       session.save(user);
 
       session.getTransaction().commit();
   }
}


Database operations are typically very expensive. A typical query would have to be first transmitted over the network. The database has to create a query plan for it and then execute it. The response then has to be transmitted over the network again before the client can process the results. Most databases will cache the results and some will cache queries thereby preventing the execution of the queries and sometimes eliminate the need for the query plan. But these are largely dependent on the number of unique queries and the network overhead is still there.

The natural and obvious answer is to have a cache at the client end of the database connection. Hibernateprovides one cache (the first-level cache) through which all requests must pass. A second-level cache is optional and configurable.

The L1 cache ensures that within a session the request for a object from the database always returns the same object instance hence preventing the object from being reloaded. You can always use object.evict() to discard the object and force a reload.To discard all objects in a session you can issue session.clear().This can also be called called a Java Virtual Machine (JVM) or SessionFactory-level class. . If you have a second-level cache at the SessionFactory level, the application objects are cached in a manner where they are available across sessions.

The L2 cache also called as query cache is external to hibernate . Hibernate provides a pluggable interface for the L2 cache. This allows a cache to be shared between applications on the same machine or even between multiple applications on multiple machines. The L2 cache will not be able to react to changes made by an external application so you have to be careful not to lose the state of the data. Also a distributed cache creates lot of network traffic and takes up memory as well.

Java threads do not timeout when there is a deadlock so don’t share sessions between different threads. If you absolutely must maintain an instance for a longer duration, maintain the instance within a ThreadLocal object. For most purposes, however, the lightweight nature of the Session object makes it practical to construct, use, and destroy an instance, rather than to store a session.

Some of the widely used L2 cache implementations are

EHCache
An in-process cache which is not cluster safe but supports Query Cache. It can use memory as well as disk.

OSCache
An in-process cache which is not cluster safe but supports Query Cache. It can use memory as well as disk.

SwarmCache
A multicast distributed cache which is cluster safe(clustered invalidation) but does not support Query Cache.

TreeCache
A multicast distributed transactional cache which is cluster safe but does not support Query Cache.

Configuration of EH Cache

When the objects being cached need to be updated, the read-write usage mechanism is an appropriate option to choose. If you use database imports or have an alternate way to update the database this option will not be suitable. It becomes even more difficult if the cache is clustered. The database has to be locked for the cache and the database to be in sync.

The nonstrict read-write cache is the same as read write except that it writes to the database occasionally.

The following properties are available in the Hibernate Configuration files to handle cache setup:

hibernate.cache.use_minimal_puts: Optimizes second-level cache operation to minimize writes, at the cost of more frequent reads (useful for clustered caches). Possible values are true and false.

hibernate.cache.use_query_cache: Enables the query cache. The query cache is disabled by default. Possible values are true and false.

Example

Session session = SessionFactory.openSession();
Query query = session.createQuery("from Users");
query.setCacheable(true);
List users = query.list();
SessionFactory.closeSession();


To explictly use EHCache :
Add this property to the hibernate .cfg.xml

<property name="hibernate.cache.provider_class">net.sf.ehcache.hibernate
.Provider></property>

Create a file ehcache.xml and make sure it is available in the classpath

 
<ehcache>
 
    <diskStore path="java.io.tmpdir"/>
 
    <defaultCache
        maxElementsInMemory="1000"
        eternal="false"
        timeToIdleSeconds="120"
        timeToLiveSeconds="120"
        overflowToDisk="true"
        />
 
    <cache name="example.user.User"
        maxElementsInMemory="1000"
        eternal="false"
        timeToIdleSeconds="3600"
        overflowToDisk="true"
        />
 
    <cache name="example.user"
        maxElementsInMemory="1000"
        eternal="true"
        overflowToDisk="true"
        />
</ehcache>


timeToIdleSeconds specifies how long an object can be idle before it expires. The timeToLiveSecondsvalue specifies the overall length of time that an object can be cached before being expired.

When not to use Cache
1) When the database can be modified by an external source. You may be able to deal with this issue by specifying a version or timestamp property for your object and using the Session.lock() method to verify that the object hasn’t been changed.
2)Caching only helps when the same data is used multiple times within the expiry time period. There is no point in caching data which expires before it can be used.
3)In financial applications where auditing is very important.
4)When the dataset is too large
5) when you don’t know what the hell you are doing

As a general rule, formal inspections are about twice as effective in finding bugs as any known form of testing. Most forms of testing are less than 30 percent efficient in finding bugs, but formal inspections on average are more than 60 percent efficient and sometimes top 95 percent. As an additional benefit, inspections also raise testing efficiency levels and they serve as surprisingly effective defect prevention methods.

The term inspection refers to a formal procedure in which a trained group of practitioners examine a software artifact, such as a specification, page by page in a planned fashion. Each inspection session is limited to a two-hour duration, and no more than two such sessions can be held in any business day. Prior to the inspection, each participant will have received the material to be inspected no less than a week prior to the start of the first inspection process.

It should be noted that informal reviews of another person’s work, which often occurs with the pair-programming concept, is not the same as a formal inspection. Informal reviews are useful, of course, but their measured level of defect-removal efficiency is usually less than 50 percent. Incidentally, the defect efficiency of programmers in finding errors in their own work is only about 30 percent. Most testing steps are also only about 30 percent efficient. Formal inspections have the highest average defect-removal efficiency levels of any form of defect removal yet studied.

The participants in the inspection process normally include the following set, although there is some flexibility and doubling up, such as having one person perform two roles:

• The producer of the material being inspected

• A moderator, charged with keeping the inspection on track

• A recorder, charged with keeping track of problems identified

• A reader, charged with paraphrasing each section

• One or more reviewers, charged with performing the inspection

• One or more observers, normally novices there to learn how inspections operate

In really large organizations that use inspections, such as IBM or AT&T, there are other specialized personnel associated with the inspection process, too:

• A coordinator, charged with scheduling inspections and reserving rooms

• One or more trainers, charged with instructing novices in the inspection protocols

The minimum number of participants needed to actually perform a formal inspection is three: the producer, the moderator, and the recorder. In this minimum complement, the moderator and recorder are, of course, also serving as reviewers.

For an average inspection held within a major corporation on specifications associated with large systems, the normal complement is five personnel: the producer, the moderator, the recorder, and two reviewers.

The maximum number of participants in formal inspections is limited to no more than eight. This is a practical limitation caused by the fact that large meetings tend to be discursive and inefficient, coupled with the fact that rooms big enough to hold more than eight people are not readily available in many corporations.

The most difficult role to fill when performing inspections is that of the moderator, because the moderator must deal with rather delicate human relationship issues. It is sometimes stressful to have other individuals performing a close scrutiny of one’s work, and from time to time producers challenge the validity of whether or not a particular finding is really an error or defect or not. The moderator has to keep such disagreements from growing into full-scale disputes.

The reviewers also must be selected carefully, since they have to understand the work being inspected. For large projects, the reviewers are normally selected from the project team for the practical reason that other team members have the best prospect of being able to contribute meaningful observations.

On average, software designs and specifications contain about 1.25 errors or defects per function point, which for a project of 1000 function points can amount to about 1250 design bugs. Of these, about 15 percent, or almost 200, will be serious.

Design inspections average about 65 percent defect-removal efficiency overall, but against serious design defects the efficiency of formal design inspections tops 95 percent. Therefore, after a series of formal design inspections on this 1000–function point example, only about ten serious design issues may remain under best-case conditions.

By contrast, most forms of testing are less than 30 percent efficient in finding bugs, and are even less efficient in finding design defects. If design errors stay in the design, there is a strong chance that testing will not find them at all, because test cases are constructed using the design specifications as the basis. The efficiency of testing in finding design errors is less than 10 percent, which is a very low value indeed.

Surprisingly, formal inspections have proven both to benefit overall project costs and to shorten project schedules. Indeed, the inventor of the inspection process, Michael Fagan, received an IBM outstanding contribution award for determining that inspections shorten schedules as well as improve quality when applied to major systems software projects.

Although formal design and code inspections originated more than 35 years ago, they still are the top-ranked methodologies in terms of defect-removal efficiency. Further, inspections have a synergistic relationship with other forms of defect removal, such as testing, and also are quite successful as defect-prevention methods.

ormal inspections have not yet played a major role in the Agile methodologies. Extreme programming is interested in quality and is good in testing, but has not adopted formal inspections. The daily Scrum sessions that identify and discuss problems are useful, but they are not as efficient as formal inspections.

A combination of formal inspections, formal testing by test specialists, and a formal (and active) quality-assurance group are the methods that are most often associated with projects achieving a cumulative defect-removal efficiency higher than 99 percent.

Formal inspections are manual activities in which three to eight colleagues go over design specifications page by page, using a formal protocol. In order to term this activity an inspection, certain criteria must be met, including but not limited to the following:

• There must be adequate preparation time before each session.

• Effort expended during preparation and during the inspections is recorded.

• Records must be kept of the defects discovered.

• Defect data should not be used for appraisals or punitive purposes.

The original concept of inspections was based on actual meetings with live participants. The advent of effective online communications and tools for supporting remote inspections, now means that inspections can be performed electronically, which saves on travel costs for teams that are geographically dispersed.

Any software deliverable can be subject to a formal inspection, and the following deliverables have now developed enough empirical data to indicate that the inspection process is generally beneficial:

• Architecture inspections

• Requirements inspections

• Design inspections

• Database design inspections

• Quality Function Deployment (QFD) diagrams

• Code inspections

• Test plan inspections

• Test case inspections

• User documentation inspections

• Web page inspections

For every software artifact where formal inspections are used, they range from just under 60 percent to more than 90 percent in defect-removal efficiency and have an average efficiency level of roughly 65 percent. Overall, this is the best defect-removal efficiency level of any known form of error elimination.

Further, thanks to the flexibility of the human mind and its ability to handle inductive logic as well as deductive logic, inspections are also the most versatile form of defect removal and can be applied to essentially any software artifact. Indeed, inspections have even been applied recursively to themselves, in order to fine-tune the inspection process and eliminate bottlenecks and obstacles.

It is sometimes asked why everyone doesn’t use inspections if they are so good. The answer to this question reveals a basic weakness of the software industry. Inspections have been in the public domain for more than 35 years. Therefore, except for a few training companies, no company tries to sell inspections, while there are many vendors selling testing tools. If you want to use inspections, you have to seek them out and adopt them.

Most software development organizations don’t actually do research or collect data on effective tools and technologies. They make their technology decisions, to a large degree, by listening to tool and methodology vendors and adopting those represented by the most persuasive sales personnel. Since there is comparatively little money to be made in selling inspections, sales personnel tend to concentrate on things like testing tools, where the commissions are greater.

It is even easier if the sales personnel make the tool or method sound like a “silver bullet” that will give miraculous results immediately upon deployment with little or no training, preparation, or additional effort. Since inspections are not sold by tool vendors and do require training and effort, they are not a glamorous technology. Hence, many software organizations don’t even know about inspections and have no idea of their versatility and effectiveness.

The companies that are most likely to use inspections are those that for historical or business reasons have some kind of research capability that looks for best practices and tries to adopt them.

It is a telling point that all of the top-gun quality software houses, and even industries, in the United States tend to utilize pretest inspections. For example, formal inspections are very common among computer manufacturers, telecommunication systems manufacturers, aerospace equipment manufacturers, defense systems manufacturers, medical instrument manufacturers, and systems software and operating systems developers. All of these need high-quality software to market their main products, and inspections top the list of effective defect-removal methods.

One of the most effective ways of illustrating the effectiveness of formal inspections is to produce graphs that connect the points where software defects are discovered with the points in software development where the defects originate.

Whenever there is an acute angle in the line connecting a defect’s discovery and origin points, there is a serious problem with software quality control, because the gap between making an error and finding it can amount to many months.

Both in real life and in software cost estimating, the combination of having quality as a key project goal, keeping complexity low, and having experienced users and experienced team members pays off in lower costs, quicker schedules, and higher quality than result through the opposite situations.

Formal design and code inspections are fairly major discriminators between best-in-class organizations and the rest of the software industry. The really good groups tend to use inspections because nothing else can find so many bugs or errors, nor find so many deep and subtle problems, as the human mind.

Refrences :

Estimating Design Inspections

by Caper Jones

The phases of the maturity model include:

• Early Learning
• Re-engineering
• Integration

• Maturity

 Early Learning

In the early learning phase is where an organization begins the journey to adopt SOA. During this phase is where the Enterprise Architecture function is founded and staffed with the leaders of the SOA definition and adoption program. Also, small cores of service procurement and operations resources are assembled. In Early Learning is where the first revision of the service taxonomy, roadmap, and foundational architecture decisions are made. Success metrics are defined along with a working financial model to project the investments and associated financial returns expected from the SOA roadmap. Finally, in early learning an appropriate number of hands-on proof-of-concept and pilot projects should be completed to demonstrate the viability of the services, service infrastructure, and associated architecture. As part of these pilot projects, documentation regarding key learnings and shifts in operational policy should be delivered to the organization in preparation for the ramp into the Re-engineering phase.

 Re-engineering

Re-engineering is the phase where the SOA adoption roadmap gets out of the lab an into the software factory. At this point the Enterprise Architecture team will have completed the definition of the first generation services inventory, the architecture for the services infrastructure, and have defined an approved roadmap for solution adoption. The starting team of Service Procurement and Operations will have established a “pilot light” of services and infrastructure that provide real working examples for additional engineering and project manager resources to handle and understand the shift to SOA. During reengineering a shift of resources from the built-to-order or made-for-order teams will migrate to the Service Procurement, Operations and Service Assembly teams. At this point there should a number of production solution development projects underway which leverage the services inventory and infrastructure to deliver the application functionality. During re-engineering the beach-head of the assemble-to-order software factory is definitively established.

 Integration

Once re-engineering is completed, the integration phase will begin. Integration starts when a mature service inventory and infrastructure is established and the first phase of identified solutions on the Enterprise Architecture roadmap have transitioned to SOA. The Enterprise Architecture and Service Procurement teams are fully established and at a reasonably mature state of operation. At this point, multiple and simultaneous teams will address the remaining targeted business domains on the roadmap and initiate the transition to SOA. Integration will involve continuous improvement to the service inventory and infrastructure as well as a substantial rise in the Solution Assembly and Operations teams. At this point, the established metrics and associated communications processes should be driving adjustments to the future roadmap.

 Maturity

Once re-engineering and integration phases are completed, then you enter the maturity phase of the roadmap. Maturity is a state where that the material defined aspects of the service inventory, infrastructure and organizational shifts are completed and work going forward is primarily focused on continuous improvement from the foundation established by the Integration phase. At this point the full shift to an assemble-to-order manufacturing model is completed.

It is important to pace technology investments, organizational shifts and new funding/reward policies in alignment with one another. You do not want to be crawling in one area while running in another … doing so will cause you to trip in the execution of the SOA transition.

Hibernate 3 actually implements most of its functionality as event listeners. Event listeners are always registered globally for the event that they handle. You can register them in the configuration file or programmatic ally. Either way, you will need to map your implementation of one of the interfaces to the associated types.Here is the different types of events supported by hibernate

AutoFlushEventListener

DeleteEventListener

DirtyCheckEventListener

EvictEventListener

FlushEventListener

FlushEntityEventListener

LoadEventListener

InitializeCollectionEventListener

LockEventListener

MergeEventListener

PersistEventListener

PostDeleteEventListener

PostInsertEventListener

PostLoadEventListener

PostUpdateEventListener

PreDeleteEventListener

PreInsertEventListener

PreLoadEventListener

PreUpdateEventListener

RefreshEventListener

ReplicateEventListener

SaveOrUpdateEventListener
Let us consider the following example

class : EventExample.java
public class EventExample {
public static void main(String[] args) {
Configuration config = new Configuration();

// Apply this event listener (programmatically)
config.setListener(”save-update”, new BookingSaveOrUpdateEventListener());

SessionFactory factory = config.configure().buildSessionFactory();
Session session = factory.openSession();

Transaction tx = session.beginTransaction();

// Make our bookings… seat R1 is NOT to be saved.
session.saveOrUpdate(new Booking(”charles”,”R1″));
session.saveOrUpdate(new Booking(”camilla”,”R2″));

// The confirmation letters should not be sent
// out until AFTER the commit completes.
tx.commit();
}
}

Class : BookingSaveOrUpdateEventListener.java

import java.io.Serializable;

import org.hibernate.HibernateException;
import org.hibernate.event.SaveOrUpdateEvent;
import org.hibernate.event.def.DefaultSaveOrUpdateEventListener;

public class BookingSaveOrUpdateEventListener
extends DefaultSaveOrUpdateEventListener
{
public Serializable onSaveOrUpdate(SaveOrUpdateEvent event)
throws HibernateException {
if( event.getObject() instanceof Booking) {
Booking booking = (Booking)event.getObject();
System.out.println(”Preparing to book seat ” + booking.getSeat());

if( booking.getSeat().equalsIgnoreCase(”R1″)) {
System.out.println(”Royal box booked”);
System.out.println(”Conventional booking not recorded.”);

// By returning null instead of invoking the
// default behavior‚ we prevent the invocation
// of saveOrUpdate on the Session from having
// any effect on the database!
return null;
}
}

// The default behavior:
return super.onSaveOrUpdate(event);
}
}

The objective of the listener is to prevent R1 from getting saved so the default behavior is overridden by the listener class.

Stored procedures may be a thing of the past but sometimes they can be very helpful. They reduce network traffic and can perform efficient and fast computations if required.

<sql-insert callable="true">
{call insertClient(?,?,?,?,?,?)}
</sql-insert>

This example may be very trivial but really complex computations can be performed using stored procedures. The drawback with hibernate and stored procedures is hibernate session cache cannot track any modifications done using a stored procedure.

There are three tags you can use to override the default behaviour of hibernate


<sql-insert/>
<sql-update/>
<sql-delete/>
 
<class name="com.hibernatebook.legacy.Client" table="Client">
<id type="int" name="id" column="id">
<generator class="native">
</generator></id>
<property type="text" name="name" column="name"></property>
<property type="text" name="number" column="number"></property>
<property type="text" name="streetname" column="streetname"></property>
<property type="text" name="town" column="town"></property>
<property type="text" name="city" column="city"></property>  
<sql-insert>
insert into client(name,number,streetname,town,city,id,country)
values (?,?,?,?,?,?,'UK');
</sql-insert>
</class>


As you can see the advantage is you can specify default values explicitly.

The biggest disadvantage is you lose hibernates cross platform portability.

First and foremost, Hibernate wants every entity to be identifiable with a primary key. Ideally, it would like this to be a surrogate key (a single column distinct from the fields of the table). Hibernate will accept a primary key that is not a surrogate key. For example, the username column might be used to uniquely identify an entry in the user table. Hibernate will also accept a composite key as its primary key, so that the username and hostname might be used to form the primary key if the username alone does not serve to identify the row.

In the real world, things do not really work like that. Any database that has been around the block a few times is likely to have at least one table for which the primary key has been omitted. For instance, the contents of the table may not have needed to be involved in any relations with other tables. While this is still bad database design, the error is only exposed when Hibernate tries to map objects to data. It may be that adding a suitable surrogate key column is an option—when this is the case, we urge you to do so. In practice, however, the fundamental schema may not be under the developer’s control, or other applications may break if the schema is radically changed.

In most scenarios, a developer will be able to arrange the creation of views or stored procedures. It may be possible to create the appearance of a suitable primary key using these if no other options present themselves, but you should consult with your database administrators, since a table for which no true primary key can be obtained is likely to cause long-term corruption of your data.

Finally, if you can neither change a broken schema nor add views or stored procedures to ameliorate its effects, you have the option of obtaining a pure JDBC connection.

The primary goal of service-oriented architecture (SOA) is to align the business world with the world of information technology (IT) in a way that makes both more effective. SOA is about the business results that can be achieved from having better alignment between the business and IT.

SOA starts from the premise that all businesses have a business design. A business design describes how that business works — the processes that it performs; the organizational structure of the people and finances within that business; the business’ near-term and long-term goals and objectives; the economic and market influences that affect how that business achieves its goals; the rules and policies that condition how the business operates.

Most businesses have a written form of their high level business plan — the high level definition that states the business’ purpose. Few businesses, however, have a written form of their business design. Many of those who have documented their business design have trouble keeping their design up to date with what they actually practice. Business processes evolve as businesses respond to shifts in the marketplace, regulations, or product innovations; this evolution usually happens without reflecting those changes in the formal design of the business.

However, even if the business design has not been documented, or even if what is documented is now obsolete, there is nonetheless a business design in effect. A fundamental premise of SOA is that if the business design can be transcribed and maintained there is a potential for leveraging that captured design information.

Even if the business design is not used to communicate between the business and IT organizations, it can nonetheless be a valuable tool to help businesses understand what they are doing and how. Beyond that, however, the business design becomes an essential tool in communicating requirements between the business and the IT organization. The business can identify those elements of the design that should be automated and what within that design should be performed by people, creating a blueprint of the information systems that are created to support that automation.

By deriving the information system design from the business design you can more easily drive changes into the information system at the rate and pace of change in the business design. Furthermore, the information system can be used as a catalyst for change in the business design. It is from this correspondence that SOA delivers on the promise of more flexible businesses through more flexible IT.

This correspondence is represented as the SOA Lifecycle, in which the business process is modeled, assembled, deployed and monitored in an iterative manner. This transforms the information system from being one of merely a “cost of doing business” to a fundamental tool for enabling a business to be more competitive, profitable and responsive to changes in the marketplace.

To achieve this synergism between the business and IT domains we need to employ a number of capabilities:

A formalism and language for capturing the business design

A methodology for translating the business design into a set of information system artefacts to implement that design

An infrastructure for hosting those implementation artefacts that is as flexible to changes in its marketplace as the business itself needs to be

A place for retaining the correlation between the business design and the information system that can be used to identify and fix failures in executing on the goals and constraints of the business design

A means by which we can manage the system to ensure those goals are met.

These capabilities improve the flow of the business process through SOA Lifecycle iterations.

What is a “Service” in Service-Oriented Architecture?

We refer to the practice of deriving an information system design from a business design as service-oriented architecture. The business process and the tasks from which it is composed can be collectively thought of roughly as services. Thus, the business design is essentially a composition of services and the policies and conditions that must be applied to their use which form the information system design.

However, there remains the question of “what is a service?” Is it a function within an application? Are all application functions services? Does SOA include system services? Coming up with a single, mathematically precise definition that applies universally to all situations can be hugely complicated. In practice, such precision is not necessary to achieving value and success from SOA.

An underlying premise in the application of SOA to information technology is the principle of loose coupling — that is, avoiding or at least encapsulating temporal, technological and organizational constraints in the information system design. This same principle applies also to the definition of service — the rules used to define services in one context may not be applicable in another. What is important is that whatever definition we arrive at, it should originate from the primary concerns and constraints of that context. As a generalization, a service is a repeatable task within a business process. So, if you can identify your business processes, and within that, the set of tasks that you perform within the process, then you can claim that the tasks are services and the business process is a composition of services.

However, note that certain tasks can be decomposed into business processes in their own right. The order-entry process includes, among other things, a task to confirm availability of the items being ordered. The confirm-availability task is itself a business process that includes, for example, the tasks of checking the on-hand inventory, verifying the supply pipeline, and possibly creating a background request and determining its availability. Thus, business processes are themselves services; there is a principle of recursive decomposition implied in the term service. If taken far enough we could easily claim that everything is a service. This, obviously, is not useful — at some point treating everything as a service would yield an incredibly inefficient over-generalization of the problem space. You should exercise this principle of recursive decomposition only to the extent that you legitimately need flexibility within your business design.

From this definition of service, service-orientation is a way of integrating your business as a set of linked services. If you can define the services in each of your vertical and horizontal lines-of-business, you can begin to link those LOBs by composing their services into larger business processes. Likewise, you can decompose the main services of your LOBs into a set of more basic services that can then be easily recomposed either to change LOB processes, or to interlink your LOBs at a lower level of their capabilities. Similarly, you can use the same principles of composition to create links with your business partners to both automate those relationships and to gain more efficiency from them. One consequence of service orientation is flexibility: you gain the ability to iteratively optimize your business design, unhampered by inflexible IT structures.

A service-oriented architecture, then, is an architectural style for creating an Enterprise IT Architecture that exploits the principles of service-orientation to achieve a tighter relationship between the business and the information systems that support the busines.

Refrence :
Building Composite Applications
by Juan R. Rodriguez et al