By Jim White (Director of Training and Instructor)

This is the second of a two part blog post on considering Windows Azure for your applications.  See the 1st post here.

Cloud computing, and in particular Microsoft Windows Azure are hot topics in IT circles today.  A report on CNN has even suggested that Internet users will live in the cloud by 2020 (see the report here).  While you and your organization is probably investigating Azure and other cloud computing technologies, here are a few things you should know before you jump into running your applications and data in Azure.

1. Migration is not free.

Azure is a different environment. Despite what some in the industry might lead you to believe, your existing .NET applications are going to need work before they can run in the Azure cloud. You can?t just flop an existing ASP.NET application on to the cloud without some thought. Architecture and design are still important steps on the way to cloud migration. Sriram Krishnam, a member of the Windows Azure program management team and author of Programming Windows Azure (O?Reilly) said it best in this passage from his book.

?you?ll often find yourself needing to rewrite/modify parts of your application. Though platforms such as Windows Azure try to make it as seamless as possible to port applications, there are some inherent differences, and you?ll need to make at least some small changes.?

Yes, you can leverage existing .NET knowledge and code, but you still have many things that operate a bit differently in the Azure environment. File storage/access, logging, diagnostics, security, and data storage/access are just a few aspects of your application that you?ll want to look at in migrating to the cloud.

2. Scaling is not automatic

One of the key selling points of Azure, and cloud computing in general, is that it allows organizations to scale their applications and data storage on demand without provisioning new hardware, bandwidth, software, etc. Azure does provide as near-to-infinite set of resources to host your applications and data as can be thought of in the real world. Moreover, these resources can be requisitioned within minutes or hours, versus days or months in normal provisioning cycles. However, the IT community often misunderstands that the scaling in Azure does not happen automatically. That is, if your application suddenly starts to see a huge spike in requests, Azure does not detect that and automatically requisition more hardware and virtual environments for application to run in to meet the onslaught of demand. You must either manually, or through code your write or purchase, detect the need to scale and then provision Azure resources (and deploy your apps/data) to answer the blitz of new requests.

If this doesn?t sound easy, you are right. In fact, one of the reasons that Microsoft does not yet provide automatic scaling and provisioning in Azure is that even they are not yet sure how to determine a scaling need. What does ?busy? or ?stressed? mean? Without a way to effectively measure and configure a response to measures, it is difficult to scale automatically.

3. Backups aren?t there.

Just one incident of not backing up your hard drive and losing sensitive data is usually enough to teach most computing resource users to backup early and often. We in the industry go to great lengths to backup crucial data; often contemplating and dealing with the unthinkable just to ensure the survival of our organization?s data. Many that explore Azure are glad to hear that all data stored in Azure, no matter what the form (Azure Storage or SQL Azure) is replicated three times (on three different physical servers). A common misconception is that this should suffice for ?backups.? The triplicate replicas of data stored in Azure is really meant for high availability of the data. It is not for backups! Backups are still your responsibility. When something happens to one of the three replicas, the other two take over while Azure rebuilds the third data replicate. Therefore, your applications and customers that use the data are never worse for wear. However, if your application (or a malicious user) creates bad data, or if the whole data center goes up in smoke (unthinkable ? maybe ? but remember backup is about contemplating the unthinkable), your data is gone, corrupt, unusable, etc? Backups in the cloud are not any picnic either. You do not have access to the servers that host your data and today there are no Azure tools that provide backup management activity. You must either write or buy code and tools to backup your data out of the cloud and put it somewhere it is safe.

4. Logging/Diagnostics require some thinking.

As developers, you cannot debug applications in the cloud. You debug your applications in a development environment and then deploy them to the cloud where you do not have very good vision of what is happening. Azure provides the means to capture all the standard log and diagnostic data you want. However, you must code and configure your applications to request and capture this data. You must also code or buy a solution for extracting this data to an environment near you where you can make sense of the information. In the case of some problematic event, you want to make sure your Azure logging/diagnostic solution can report back to you in a timely manner with enough data that you can react to the current situation. If this sounds like you have to put some planning and design into bug and downtime events (and the handling of those) you are correct again!

5. Savings are negated by poor architecture.

Azure and other cloud platforms are about saving money. Instead of buying and operating a whole data center yourself, you purchase a slice of a data center and share in the cost of its operation. Further, you ?pay for play.? That is, you provision the computing resources you need as/when you need them and you pay for exactly what you use ? nothing more and nothing less. All true, but because you are now charged for each computing hour, each transaction, GB of data stored, and GB of data bandwidth, you can write applications that exceed traditional data centers. Software engineers, as Azure engineers, need to think like an MBA graduate as much as they think like a CS major. Writing applications that are extremely (and often needlessly) chatty increase costs. Data stored too long or in the wrong place can inflate costs. Azure offers multiple data storage options for a reason. Some are cheaper and more scalable in certain situations. As you are charged for every hour of computing time, underutilized application instances meant to handle the occasional spikes in demand cost you money in Azure. Design and architect your applications and data storage to leverage the pay-as-you-go model without evaporating your savings on the data center.

If you would like to learn more about Windows Azure, check out our training course here. If your consultants can help you ?navigate in the clouds?, please contact Ryan McCabe for assistance. Also, I invite you to join the Windows Azure User Group ? it?s a virtual users group ? where you?ll find some great educational material and virtually meet people discussing Azure.

By Jim White (Directory of Training and Instructor)

A few weeks ago while teaching Hibernate, a student (thanks Dan) asked me about whether version numbers can be generated by the database.  The answer is - Yes, in some cases.  I thought the question and an expanded discussion of Hibernate's versioning property would be a good topic for this week's blog entry.

The <version> property (or @Version annotation)

For those of you that use Hibernate today, you are probably aware that Hibernate can provide optimistic locking through a version property on your persistent objects.  Furthermore, the version property is automatically managed by Hibernate.

To specify a version for your persistent object, simply add a version (or timestamp) property in your mapping file and add a version attribute to your persistent class.  Here is an example on a Product class.

public class Product {

    private long id;

    private String name;

    private String model;

    private double cost;

    private long version;

...

}

<hibernate-mapping package="com.intertech.domain">
  <class name="Product">
          <id name="id">
            <generator class="native" />
        </id>
        <version name="version" type="long" />
        <property name="name" not-null="true" />
        <property name="model" not-null="true" />
        <property name="cost" type="double"/>
  </class>
</hibernate-mapping>

For those using annotations, just mark the version property's getter in the class with the @Version annotation.

@Version
public long getVersion() {
    return version;
}

The version property on the class can be numeric (short, int, or long) or timestamp or calendar.  However, when a better configuration element is provided for timestamps or calendars (covered below).

With automatic versioning (and version set to a numeric), Hibernate will use the version number to check that the row has not been updated since the last time it was retrieved when updating the persistent object (Product in this example).  Notice the extra where "and version = X" clause below, when a product from above is updated.

Hibernate:
    /* update
        com.intertech.domain.Product */ update
            Product
        set
            version=?,
            name=?,
            model=?,
            cost=?
        where
            id=?
            and version=?

If the version has been updated, Hibernate throws a StaleObjectStateException and the transaction (and any persistent object changes) rollback.  If the update commits without issue, Hibernate also increments the version number automatically (note the "set version = ?" as part of the update clause above).

Hibernate versus the Database Managing the Version

Under this configuration and in this example, Hibernate (from within your Java application) is managing the version number.  However, some DBA's may prefer to have the version controlled by database rather than Hibernate, especially when the database may be a timestamp and the application is distributed to multiple systems (maybe even timezones).  If the Hibernate application is on different systems that are not time synchronized, the timestamp generated by each system might be different thereby generating improper optimistic lock success or failures.  To inform Hibernate to have the database manage the version, include a generated="always" attribute in the Hibernate mapping of the persistent object.

<hibernate-mapping package="com.intertech.domain">
  <class name="Product">
          <id name="id">
            <generator class="native" />
        </id>
        <version name="version" type="long" generated="always"/>
        <property name="name" not-null="true" />
        <property name="model" not-null="true" />
        <property name="cost" type="double"/>
  </class>
</hibernate-mapping>

Hibernate will now defer to the database to generate the necessary version and update the persistent object's row accordingly.  A warning is in order however.  This will cause Hibernate to issue an extra SQL to get the version number back from the database after a successful update or insert.  Note the extra SQL issued below after a successful update of a product (Hibernate even comments it to indicate why it is needed).  You might also note that the version number is not set as above when updating the product.  Again, Hibernate is now totally deferring to the database to manage this property.

Of important note, not all dialects (i.e. databases) support the managing of the version number.  HSQLDB, for example, does not allow the version number to be controlled from the database.

Hibernate:
    /* update
        com.intertech.domain.Product */ update
            Product
        set
            name=?,
            model=?,
            cost=?
        where
            id=?
            and version=?
Hibernate:
    /* get generated state com.intertech.domain.Product */ select
        product_.version as version8_
    from
        Product product_
    where
        product_.id=?

Timestamps for Version

In many situations, your DBA or organization may prefer a timestamp to be used as the version indicator.  In theory, the timestamp is a little less safe than a version number.  This is because a timestamp can, in theory, be updated by two transactions at the exact same time (depends on the precision of the database) and allow both to update causing a last in wins scenario (violating the optimistic lock).  It can also be argued that timestamps also take up more space in the database.  Depending on the dialect, the use of a timestamp may incur an additional hit of the database to get the timestamp.  However, on the plus side, timestamps provide useful information about the "when" a row was last altered.  In cases of auditing or record tracking, this might be important information.  Version numbers don't provide any context for when an update occurred.

If a timestamp is useful, change your version property to be a java.util.Date or Calendar and use a <timestamp> (rather than using a <version>) element in the mapping file.

public class Product {

...

    private Date version;

...

}

<hibernate-mapping package="com.intertech.domain">
  <class name="Product">
          <id name="id">
            <generator class="native" />
        </id>
        <!--<version name="version" type="timestamp" generated="always"/>-->
        <timestamp name="version" source="db"/>
        <property name="name" not-null="true" />
        <property name="model" not-null="true" />
        <property name="cost" type="double"/>
   </class>
</hibernate-mapping>

The <version type=timestamp"> and <timestamp> are equivalent, but it might help the reader to better see/understand that the version is an effectivity timestamp versus a numerical indicator.

You might also notice the source="db" in the mapping configuration above.  The source attribute can be set to "vm" (for virtual machine) or "db" (for database).  When set to "db", the database creates and manages the version timestamp (equivalent to generated="always") above.  As mentioned above, in the case of the database managing the version timestamp, your application may incur an additional hit of the database as Hibernate must first retrieve the timestamp before updating the row.  Further, as the Hibernate documentation says:  "Not all Dialects are known to support the retrieval of the database's current timestamp."

Optimistic Locking without a Version

Your application may need to deal with a legacy database and the database cannot be altered to contain a version (numeric or timestamp) column.  In this case, Hibernate provides two additional options for optimistic lock management.  You can use all the fields of the persistent object to check that nothing in a row was modified before updating a row.  Set the optimistic-lock="all" attribute (and dynamic-update="true") in the <class> element to use this approach.  The SQL issued by Hibernate will then use each property as a check in the where clause as shown below.

Hibernate:
    /* update
        com.intertech.domain.Product */ update
            Product
        set
            name=?
        where
            id=?
            and name=?
            and model=?
            and cost=?

comparison of the state of all fields in a row but without a version or timestamp property mapping, turn on optimistic-lock="all" in the <class> mapping

As a slight alternative to this approach, you can set optimistic-lock="dirty" and then Hibernate will only use modified columns as part of the optimistic check (see below).  This last approach actually allows to transactions to update the same object concurrently legally, but only if they are modifying different columns - something that might be advantageous in a larger application setting where many people are accessing the same objects (thus rows) but rarely updating the same properties (columns).

Hibernate:
    /* update
        com.intertech.domain.Product */ update
            Product
        set
            name=?
        where
            id=?
            and name=?

See the Hibernate documentation for more details on these alternatives to versioning.

Come join us to learn more about Hibernate!  Sign up for Complete Hibernate at Intertech.com here.

by Jim White (Intertech Director of Training and Instructor)

I attended fellow instructor Andrew Troelsen?s Complete Windows Communication Foundation (WCF) class last week (recently updated for .NET 4.0). Andrew is a gifted teacher with a deep deep knowledge of .NET. If you want to learn anything about .NET, you really need to take a class from Andrew. Regardless of the topic, you are going to learn more in a day with Andrew than you will reading an entire library of books on your own. For those not aware, WCF is Microsoft?s relatively new service oriented framework. In Java, this would be equivalent to your JAX-WS and JAX-RS more on that in a bit APIs.

If you had to put me in one of the software-centricities today, I guess you would say I am a ?Java developer.? I have been doing Java for over 14 years. However, I have recently ?crossed to the dark side? (as some of my Java friends would say) as I am participating in and leading Intertech?s Cloud Computing efforts ? most notably with Windows Azure (Microsoft?s cloud platform). WCF is at the heart of a lot of Azure capabilities and APIs. I took Andrew?s class to get better insight into this Azure foundational element.

However, as a Java developer, I was also curious to see how the other world treated SOA and Web services. When writing interoperable Web services or consumer applications, I am always very curious how non-Java applications might work with my Java service or Java consumer. After all, SOA and Web services are all about interoperability.  This week?s class gave me a much better appreciation for that, at least from the current Microsoft stack. Below, I have provided a kind of compare and contrast look at how Java and .NET provide developers with tools and APIs for wresting with services. For those that spend a lot of time in SOA worlds, I hope you find the discussion encouraging. The point of this post is not to highlight the differences, but to really spotlight the fact that the two have to address many of the same issues and are therefore more alike than you might think. In other words, there is more that binds us (pun intended) than separates us.

First, some of the differences I saw. Note, ?differences? doesn?t not mean better or worse ? just different.

Support for Multiple Bindings

Java has an API for everything. Unfortunately, that means for each job, you need a different API. The JAX-WS API provides a great environment for writing interoperable SOAP-based Web Services and Web Service Clients. What if you need to communicate Java-to-Java using a different (more Java centric) protocol? Well, then it?s probably another distributed technology API (like RMI or EJB) that you probably want to explore ? at least if you want the performance and Java objects passed around. Want to do REST in Java? You need JAX-RS. In the .NET world, its WCF - period. In fact, what I was impressed with is that WCF has taken over as the communications framework in the Microsoft camps. Gone (not deprecated, but certainly relegated to legacy support) are .NET Remoting, ASP.NET web services, and other such APIs. Everything is now WCF. .NET to .NET, or .NET to Java using SOAP, it?s all the same. WCF offers multiple bindings. Bindings dictate the protocols, encoding mechanisms, and the transport layer used between consumers and service providers. What?s more, when you write a WCF service, the code doesn?t know or care what binding you choose. The binding is taken care of through configuration and hosting operations. In class, we wrote simple services in our lab that ran SOAP over HTTP in one minute and in TCP or named-pipe, .NET-centric fashion the next minute. Java wonks will argue you can do multiple bindings with Java APIs too. Yes you can, just like I can cut my yard with scissors ? doesn?t mean I want to or that it?s a good idea either.

WCF Host vs. the App Server

In Java, you typically create your service as a simple Java object (POJO or plain old Java object as it is know) and hand it off (with some configuration) to a Java application server/container to do the rest of the work. While Java services (like those produced in JAX-WS) can run in multiple environments, by and large, they are really engineered to be simply packaged and deployed into a managed Java runtime container (a Java application server). Nicely, the container manages the lifecycle of the service, routes traffic to and from the service, and generally handles all the details of the service as it is deployed and running. In the WCF, once you have created the service (which is also just a simple object), your work may only be half done. Now, you need to pick and possibly build its host environment. You can choose something like IIS to host the service (your job is now simpler) or you may choose to have a custom Windows service, or console application, Windows Server (through Windows Activation Service) host your service objects. Some choices will require you to write the code that essentially manages your service at runtime. Other options just need some configuration. Choices are good.  Allowing for you to pick how and what manages the life of your service.  However, choices can also lead to some complexity. I can see that making the wrong choice (or coding the host inappropriately) could lead to some issues (like poor service performance).

To be fair and honest, as those in the Java community know, running in an application container is not always a picnic - i.e. seamless or easy.  Your Java Web services don't always deploy simply or easily in containers as it often requires special libraries and/or configuration.  In fact, there is even a JSR (JSR-109) that attempts to address the deployment issue interoperable Web services.

Development Approaches (top-down, bottom up)

As Java?s main Web service stack (JAX-WS) is all about interoperable SOAP-based Web services, it should come as no surprise that the IDEs, tools, and API support both top-down (a.k.a. WSDL or contract first) and bottom-up (a.k.a. code first) approaches to building Web services. I?ll leave the pros/cons of both approaches to material you can find on the Internet. However, both are supported with neither relegated to an ?alternate approach? status. While you can do top-down service development in WCF, you need to use a command prompt tool (SvcUtil) to generate code from the WSDL and related schema documents. This seemed a bit kludgey to me. I am sure the tool works fine and once you are used to working with it, you can make it do all sorts of neat tricks. However, when I have a WSDL URL, I?d like to point my IDE to the WSDL and say ? go generate skeleton code for my new service. I didn?t see anything like that in WCF, which leads me to feel that the top-down approach is relegated to second class status in .NET. However, remember again that WCF deals with multi-bindings and the service code itself doesn?t know or care that it is doing SOAP or .NET binary. Top-down development is about using a contract to drive development of consumers and services. In an all .NET world, a top-down contract approach probably isn?t going to be an option (no WSDL to leverage there).

REST

Formal REST support is something added to WCF with the latest release (.NET 4.0). Frankly, it kind of looks like it was added recently.  For example, a number of configuration simplifications were made for "normal" services in .NET 4.0.  However, RESTful Web services must use the older form of configuration.  Further, the WCF templates in Visual Studio 2010 may still require a few reference updates and configuration changes when creating a RESTful service project.  These are minor issues, and I think we can all presume that things will be better and different in a future release of WCF.  However, WCF is the framework for any type of "communications" - REST or otherwise.  So again, when building a service using WCF, you can create a simple class that performs some sort of offering and you can make it available as a Web service, .NET named-pipe, or RESTful Web service all with the same framework.  Java's RESTful API (JAX-RS which is relatively young itself) is a separate API (and implementation) from its other service types (notably JAX-WS).  While it might be possible to have a class implement both JAX-WS and JAX-RS simultaneously, you are really talking about two different frameworks and two APIs for Java Web vs. RESTful services.

Security

WCF leverages Microsoft's Role Based Security system for most in-house (.NET to .NET) types of services.  This makes security slick and easy for service providers and consumers.  The API for determining who is the caller and what access they have is built into the API as well as a declarative model that makes securing services pretty easy.  For externally facing services, authentication and authorization are, like Java, a bit more manual (generating, handling and passing credentials and/or certificates in the message), and takes a bit more work on the part of the service provider/consumer to setup.  However, WCF applications can leverage the SQL Membership Provider API.  The SQL Membership Provider API, for non-.NET developers, is an auto-generated custom database (at runtime) for registering users and granting access.

Proxy API

In both Java and WCF, proxy classes are generated for the consumer developer.  The proxy makes communicating with the service easy and abstracts away the details of the protocol being used or even the fact that it is distributed computing going on.  Working with a WCF proxy is so simple, as they say in the commercials, even a caveman can do it.

BasicMathClient proxy = new BasicMathClient();

Console.WriteLine("1 + 1 = {0}", proxy.Add(1, 1));

proxy.Close();

In Java, there are actually two types of proxies.  Using the dynamic proxy client (a generated proxy), is very similar to using the WCF proxy.  I think JAX-WS client proxy coding is a bit more complex, but also offers the ability (in theory) to use different ports on the service (e.g. SOAP vs. RMI). 

BasicMathService service = new BasicMathService();

BasicMath port - service.getBasicMathSOAPPort();

System.out.println("1 + 1 = " + port.Add(1,1));

Java also offers the Dispatch Client.  This client requires more work (a lot more work), but allows the developer to have more direct control of the raw message (typically SOAP).

More That's The Same Than Different

As mentioned, there is really more that is similar between Java and .NET's Web service frameworks than is different.

Services as Simple Classes

Both rely on objects that come from simple classes dictated by interfaces for implementing services.  Plain old Java, C#, or VB objects are running the SOA world!  In fact, I even found it interesting that both environments encourage but do not require the use of an interface for defining the service.  Of course, services can contain complex logic and complex calls to other classes to get business done, but the service structure itself is simple and easy to understand.

Annotations or Attributes

Both rely on metadata (Annotations in Java and Attributes in .NET) to demarcate the service, its operations, and much of its runtime behavior.  Its fun to see that there is almost a one-to-one correspondence in the metadata tags in both worlds.  If you were a Java developers, I dare say you could pick up a C# Web service and translate it into Java code with only a little assistance.  And of course the opposite holds true for .NET developers.

//C# attributes

[ServiceContract]

public class ServiceTypeAsContract

{

[OperationContract]

public void SomeMethod() { /* Some interesting code. */ }

[OperationContract(IsOneWay = true)]

public void AnotherMethod() { /* Some interesting code. */ }

}

//Java annotations

@WebService

public class ServiceTypeAsContract

{

@WebMethod

public void SomeMethod() { /* Some interesting code. */ }

@WebMethod

@OneWay

public void AnotherMethod() { /* Some interesting code. */ }

}

Serialization/Deserialization

The frameworks are largely responsible for the creation of the request and response messages and marshalling/unmarshalling data to the applications.  The days of manipulating raw XML, JSON, or other formatted requests and responses are over in any language.  Let the framework do the grunge work of distributed communications and data formatting. 

WS-* and WS-I adherence

Both Java (JAX-WS) and WCF are now fully WS-I compliant.  This is good news for everyone.  While you can certainly use annotations/attributes or configuration to construct non-interoperable services, it requires work (and presumably acknowledgement on your part) to implement only for a certain platform.  There are still many gotchas in Web service interoperability, but developers now have a fighting chance of making things work with other platforms without having to know every detail about the other platforms.

Exceptions as faults

Both WCF and the Java frameworks translate language exceptions into faults.  Both provide a similar means of creating application specific faults that can contain more details about what went wrong to the client.

Filters vs. Channel

Both the Java frameworks and WCF provide for pre and post processes to operate on in bound and out bound messages at both the consumer and service provider levels.  They have different names, but provide similar capability to alter the message on the way to and from its destination and even to alter message flow under the right circumstances (say authentication failure).  In Java, these processes are called handlers.  In .NET/WCF they are called channels, but they serve the same general purpose.

I am sure a more experienced practitioner in both the Java and .NET SOA worlds can provide you with more detailed and better comparisons than I have here.  Hopefully, you get the idea that the software community is more united in its approach to SOA than divided - at least when it needs to be.  Sure, you can write applications in Java or C# that just need to communicate with their ilk and then things often get simpler.  But the design, patterns and approach to building services, no matter the platform, is starting to get more similar and that's good news for everyone.

Sign up today for Complete WCF or Complete Java Web Services to learn more about SOA in any environment.

By Jim White (Director of Training and Instructor)

This is the first of a two part blog post on considering Windows Azure for your applications.  See the 2nd posting next week.

Cloud computing, and in particular Microsoft Windows Azure are hot topics in IT circles today.  A report on CNN has even suggested that Internet users will live in the cloud by 2020 (see here).  Why is cloud computing ?the next big thing? in IT? Here are five reasons you should explore Windows Azure ? Microsoft?s cloud computing platform.

1. Save money

In fact, I really wanted to name this blog post 10 reasons to consider moving an application to the cloud and have #1 ? 5 be about money. As that would be unfair to the reader, I kept it to five, but the importance of saving money via cloud computing and Azure should not be understated. Buying, building, and operating a data center, no matter how small it is, is an expensive endeavor. The initial costs for hardware, network, and software give managers sticker shock. Operating costs (electricity, heating/cooling, and personnel to operate it) are growing expenses. Just about the time you have it up and running efficiently, it (hardware, networks, OS, etc.) need to be upgrade. Because the demands on the data center do not stay constant, most of the time your data center is either over or under utilized. If your business takes off, you may not have enough computing resources to meet the need. If stay in front of resource demand, you have long periods of excess capacity.

Windows Azure affords organizations data center resources (and more) in a pay-for-use model. Cloud computing is called utility computing because like water or electricity, you pay for what you use and not what you think you might use ? or for having to build the entire water pump house or electric generator all on your own. Don?t take my word for the savings. Prove it for yourself. In fact, so confident are Microsoft and others about the savings in Azure that there are two return on investment (ROI) calculators that allow you to size up your savings. Microsoft?s own, very detailed and thorough ROI calculator is here. You can also check out Neudesic?s calculator (itself a cloud application) out for a simpler-big-picture ROI report here.

2. Scaling

Most organizations have a hard time building an application or data store that must ultimately support incredible scale. Most applications and data stores start out relatively small, and through success take on more and larger needs. How do you plan to take that garage web site to the top ten most visited sites of the Internet? Azure allows you to scale by adding more resources in support of your application on demand. Whereas it might take days or months to provision new hardware, networks, software, etc. to support increases of demand on your applications and data stores today, you can provision what for all practical purposes is an infinite supply of computing resources in Azure in a matter of minutes or hours. Remember, scaling computing resources is often a two way street. You may need extra storage and computing resources today, but you do not want to pay for that extra forever do you? Say you have an application that you know is going to achieve a spike in utilization during a short period (think Dominos Pizza on Super Bowl weekend ? they are in fact a user of Azure ? see here) but after that, it?s back to normal computing. Azure allows you to take down those same resources as fast as you put them up.

3. High Availability

No one likes to have to answer the beeper or cell phone go off in the middle of the night ? especially when it?s to learn that a server, network device, database, or application has gone haywire. Software engineers like to code and solve business problems. Baby sitting equipment typically comes with the territory, but it can hardly be classified as satisfying work. Let someone else manage the environments that run and support your applications and data store! Azure provides a service level agreement (SLQ) backed environment (computational resources are guaranteed at 99.95% up time ? see here). If you doubt the SLA is being achieved, you can see an Azure data center dashboard that tells you what the up-time of the Microsoft cloud is today (see here).

In Azure, if the server box running your application or data store dies or an application running on an Azure virtual machine falls over, the Azure Fabric Controller brings it back up automatically. Furthermore, all data stored in Azure (Azure storage or SQL Azure) is replicated three times. So, applications and more importantly users should never see unavailable applications or data. Geographical redundancy is something Azure developers have requested and may be available in future releases. That is, your application and/data may be made available in multiple Microsoft data centers located across the world to provide expanded availability. Even if one data center were down, the other would still be up and take on the requests. With Azure, organizations can focus on their core business solutions and not on keeping a data center operational.

4. Rapid Application Development/Testing

If you have ever worked in a relatively large organization and started on a new project, you have probably experienced the team down-cycles at the beginning of a project when new equipment, development environments, etc. have to be approved, then ordered, setup and made operational. What a drag on the ?rapid? part of RAD development. If someone in your organization has an idea about how to make the company more money or improve operations, how long does it take to get that idea in front of customers or decision makers? If the answer is too long, perhaps you need a better way to provision the RAD environments and get product to market faster. Azure offers a ready and waiting environment with developer tools to allow teams to get prototypes and early versions of applications up and running quickly and cheaply. Moreover, since Azure is .NET based, a lot of the tools and existing .NET skills can be applied and reused in cloud computing. If the project fails or needs to be moved to a more tightly managed environment, the cloud resources can be shed just as quickly with no wasted and unused equipment standing around. Azure can serve as an incubator to hot ideas that can help businesses move and react quicker.

5. Geographical Distribution

Who are your customers today? Are they all in your city? Your state? Your country? Increasingly, applications, content and data is shrinking the world. However, your applications and data are still probably located where you are. Is this a problem? Maybe. If your customers are around the world, you may be required to have your applications and data where the customers are and not where you are. Increasing legal and regulatory demands from governing bodies (local, national and international) make it necessary to put applications and data within certain geopolitical boundaries. Tax laws may encourage you to host your application and data in certain areas of the world while avoiding others. And even though the speed of light that pushes data through fiber optic cable is good, it may not be enough when that data has to travel half way across the world in a time-critical transaction. As many organizations ?go global?, they need to find a way to distribute applications and data geographically (without the expense and trouble of building their own data centers in several locations across the world). Microsoft has already done that for you. Azure is hosted in data centers around the world. When you build your application for any one Azure site, you can easily deploy it to an ever-increasing set of Azure data centers with no changes ? free (except for the actual resources you use in the cloud) geographical distribution.

If you would like to learn more about Windows Azure, check out our training course here. If your consultants can help you ?navigate in the clouds?, please contact Ryan McCabe for assistance. Also, I invite you to join the Windows Azure User Group ? it?s a virtual users group ? where you?ll find some great educational material and virtually meet people discussing Azure.

By Jim White (Director of Training and Instructor)

Last week, my fellow Intertech colleague and Microsoft MVP, Tim Star, and I presented the Windows Azure Bootcamp for the Twin Cities.  According to Microsoft reps, we broke the record for the most attended bootcamp in the US with nearly a hundred people at the event.

A common question that I received during and after the bootcamp was "Why would I want to use Windows Azure Table Storage versus Windows SQL Azure to store my application data?"  A good question with the answer dependent on your application and data needs.

Table Storage and SQL Azure Defined

First, allow me to backup and set the stage a little for this discussion.  SQL Azure is essentially SQL Server in the Microsoft cloud computing environment known as Azure.  That is not quite true in that SQL Azure currently has a number of limitations and unsupported features that SQL Server 2008 has (here is a starter list of limitations:  http://msdn.microsoft.com/en-us/library/ee336245.aspx).  I like to say that SQL Azure is either SQL Server 2008 minus or SQL Express plus depending on how you want to view it.  Table Storage is one of three alternate storage mechanisms built into Azure that is collectively called Windows Azure Storage Services.  The other two being queues and blobs.  Table Storage allows you to store serialized entities in a table, but the term table here  is not a relational database table.  To provide people with some analogy they can use to get their arms around Table Storage, I like to tell people to think of Table Storage as a fancy spreadsheet.  You can store the state of your entities in the columns of the spreadsheet.  However, there is no linkage or relationship (therefore joins) between entities - at least none that is automatically managed and maintained by Azure.  There are no custom indexes - at least not today.

Interestingly, when Azure was first introduced in 2008, SQL Server was not part of the original picture.  Because of developer negative reactions, SQL Azure was added to the next preliminary release in 2009.  There is a growing faction that is trying to get the software community to look at SQL alternatives.  The "No-SQL" community (see here and here), to some extent, has influenced part of the Azure cloud computing platform through the Table Storage option, but not enough to eliminate it from the Microsoft cloud.

While both SQL Azure and Azure Table Storage provide data persistence via table structure, there are a number of differences between them.  The sections below outline some of the key differences and factors you want to weigh before building an application for Azure that requires some form of table persistence.

Scale and Performance

When looking at sheer volume, Table Storage is today far more scalable than SQL Azure.  Given a storage account (storage accounts hold blobs, queues and tables) is allowed to be 100TB in size, in theory your table could consume all 100TB.  At first glance, a 100TB chunk of data may seem overwhelming.  However, Table Storage can be partitioned.  Each partition of Table Storage can be moved to a separate server by the Azure controller thereby reducing the load on any single server.  As demand lessens, the partitions can be reconsolidated.  Reads of Azure Table Storage are load balanced across three replicas to help performance.

Entities in Table Storage are limited to 1MB each with no more than 255 properties (3 of which are required partition key, row key, and timestamp).  That seems like an absurd number, and it is, but remember that there are no relationships and joins in Table Storage.  Therefore, you might need some wide tables to handle associated data.

Today, SQL Azure databases are limited to 1GB or 10GB.  However, sometime this month (June 2010), a 50GB limit is supposed to be available.  What happens if your database is larger than 10GB today (or 50GB tomorrow)?  Options include repartitioning your database into multiple smaller databases or sharding (Microsoft's generally recommended approach).  Without getting into the database details of both of these database design patterns, both of these approaches are not without issue and complexity, some of which must be resolved at the application level.

Data Access

Data in the cloud, be it in SQL Azure or Azure Table Storage, can be accessed from in or out of the cloud.  To access data in SQL Azure, all the standard tools and APIs apply that work with SQL Server.  Meaning, your existing .NET/SQL Server knowledge and experience can be heavily leveraged.  ADO.NET and ODBC APIs can be used by application code to access the SQL Azure database.  Tools like SQL Server Management Studio and Visual Studio can be pointed to the SQL Azure instance and manipulate the schema and data just as you do today with SQL Server. 

Access to Azure Table Storage is accomplished either via REST API or Storage Client Library provided with the Windows Azure SDK.  Using the REST API allows client applications to communicate and use data from Table Storage without having detailed and specific knowledge of an Azure API, but it is more complex and difficult to work with.  The Storage Client Library (which leverages LINQ to Objects) provides a layer of convenience but requires the application reference the Storage Client Library APIs.  REST and the Storage Client Library incur a learning curve that is typically not there when using SQL Azure.

Portability

As mentioned, data in SQL Azure and Table Storage can be accessed from applications in and out of the cloud.  That means applications can be moved in or out of the cloud and still deal with the data in the cloud in the same way.  However, one question that may need to be considered is whether the data must always live in the cloud?  Applications generally view data in SQL Azure similar enough to data in a normal SQL Server database as to allow the data to migrate back and forth between the cloud and on-premise databases.  In fact, there are even migration tools to help move data between instances of SQL Server and SQL Azure. 

However, given the unique nature and access APIs of Table Storage, portability of the data is not as straight forward.  Table Storage tightly couples your data to the cloud.  Moving the data out of the cloud would require an on-premise data storage alternative, a data migration strategy, and likely require application code changes.

Transactions and Concurrency

SQL Azure supports typical ACID transactions for work within the same database.  Transactions across databases are not supported.  SQL Azure allows for typical optimistic and pessimistic concurrency strategies.

Table Storage supports transactions for entities in the same table and table partition, but not across tables or partitions.  Additionally, only 100 operations or less (what is called a batch in Azure Table Storage) can be part of the transaction.  Only one operation can be performed on each entity in the batch, and the batch must be limited to 4MB.  Table Storage abides strictly by an optimistic concurrent strategy.  If, on commit of the transaction, data has been changed by another process the whole transaction must be rolled back and retried.  Due to this single concurrency strategy, a built-in retry option is provided with the Storage Client Library.

Queries

Using Table Storage, queries are limited to 1000 entities by default.  If more than 1000 entities are found, a continuation token is returned and must be used by the application to retrieve the next set of entities.  Queries that take longer than 5 seconds also return a continuation token.  Queries that take longer than 30 seconds are cancelled.  Data in Table Storage is organized by partition key and indexed by row key.  Because there are no custom indexes in tables, queries by partition key and row key are fast, but queries that do not use partition key and row key are slow.

Generally speaking, SQL Azure has no limitations, issues or special programming requirements to work with large queries.  Good database and index design can help improve performance of queries; especially large ones.

Column types

Columns in Table Storage are limited to the types in the table below.

Cost

Perhaps the most unique aspect to designing and architecting applications for the cloud is that it requires developers to think like businessmen.  Each technical choice often has direct costs associated with it when developing for the cloud.  The choice in data storage can have a huge impact on the cost of running an application.

Azure Table Storage costs 15? per GB of storage per  month.  Additionally, you pay 1 cent per 10,000 transactions with Table Storage.  SQL Azure costs are $9.99 for 1 GB of storage per month ($99.99 for 10GB). 

See Microsoft's sight for more details and specifics on costs here.

Bottom Line

Chris Hay and Brian Prince in their forth coming book Azure in Action (published by Manning - see here) provide a synopsis of the SQL Azure vs. Table Storage in a few paragraphs.  "If size is the issue, that would be the first flag that you might want to consider Azure Tables. As long as the support Tables has for transactions and queries meets your needs. The size limit surely will, at 100TB."  Further they suggest sophisticated transactions, or a complex authorization model might require the services of SQL Azure.  And as shown by the cost table above, "The final consideration is cost. I can store a lot of data in Azure Tables for a lot less money than I can in SQL Azure. SQL Azure is giving me a lot more features to use (joins, relationships, etc.), but it does cost more."

Future

We are given every indication by Microsoft that SQL Azure will have far more capability in the future - akin to the SQL Server you might find in your data centers today.   So some of the comparison above may be moot or less important over time.  Additional functionality is also being proposed to Table Storage as well.  For example, support of secondary (non-key) indexes is already been suggested for a future release (see here).  However, key architectural differences between SQL Azure and Table Storage will remain and leave application designers having to pick the best option for their systems.  Welcome to cloud computing.  There is a lot of ROI to be had by running in the cloud, but only with proper application design and architecture.

If Intertech can help you  negotiate the issues of cloud computing, please contact Ryan McCabe at ryan.mccabe@intertech.com.

By Jim White (Intertech Director of Training and Instructor)

Have you started to explore Spring 3!  It came out at the end of 2009 (December to be exact).  You can check out one of the easier features - formatting annotations - to add to your applications through an article I wrote for Developer.com.  It was just published to day:  http://www.developer.com/features/article.php/3879471/Spring-Framework-30-and-Annotation-driven-Formatting.htm.

Leave me comments or send me an eval on what you think and what other features of Spring 3.0 you'd like to learn/hear about.

By Jim White (Intertech Director of Training and Instructor)

In general, Microsoft has tried to make writing Web applications for the Azure platform akin to writing for your local IIS environment.  In fact, Microsoft lists "use your existing development skills to build cloud applications" on the Azure Web site as one of its major selling points.  I think, to a large extent, .NET developers will find building or moving an application to Azure straightforward.  However, to be fair, there are also a number of areas where the application will change to deal with the reality of this new platform and, more generally, cloud computing.  One of those areas is simple file access and/or local storage.

File Access in the "Normal" ASP.NET world

For example sake, say you needed to read/write from a simple text file.  Perhaps you need to read some configuration information from the file, or perhaps some SQL that you need to execute was in the file.  Whatever the reason, accessing this file is pretty straightforward.  In a "normal" ASP.NET application, accessing a file that is stored on a virtual path on the Web server is quite simple and might look like the code below (in C#).

    //----------------------- read config contents --------------------------------
    try
    {
        string s = System.IO.File.ReadAllText(Server.MapPath("myConfigs") + "myFile.txt");
        //... do your work with s
    }
    catch (Exception myException)
    {
       ...    }

    //----------------------- write config contents --------------------------------
    if (!text.Equals(""))
    {
        System.IO.File.WriteAllText(Server.MapPath("myConfigs") + "myFile.txt", text);
    }
    else
    {
        System.IO.File.WriteAllText(Server.MapPath("myConfigs") + "myFile.txt", "no data");
    }

File Access in the Cloud

Now, how would that look in the cloud?  Well, first you must step back and consider that local storage in the cloud is not the same as that under our local IIS environment.  Local storage, is assumed under an ASP.NET application running on a local IIS server.  In the Azure world, you must first configure your role to request local storage as it is deployed.  This can be done with the Role Editor in VS 2008.  The Local Storage tab on the editor allows you to specify the name, size and clean/role policy for the storage as shown below.

The information from this editor is stored in the service definition file of the role and used to configure the Azure environment when the application is published to the cloud.

Local Storage Location

So now you have local storage, but where is it?  When you deploy your application (consisting of either a web or worker role) to Azure, a storage area is assigned to your application.  The exact location is at the Azure servers discretion.  The physical path of the folder for your assigned storage can be located through the Azure API.  In this case, request the location of your local storage through, Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.  The RoleEnvironment class represents the Azure environment that your instance of your role (web or worker) is running in.  So, reading and writing to that file might look something like the following code in an Azure world.

    //----------------------- read config contents in Azure -----------------------
    try
    {

            LocalResource myConfigsStorage = RoleEnvironment.GetLocalResource("myConfigs");

        string s = System.IO.File.ReadAllText(myConfigStorage.RootPath + "myFile.txt");
        //... do your work with s
    }
    catch (Exception myException)
    {
        ...    }

    //----------------------- write config contents in Azure------------------------
    if (!text.Equals(""))
    {

           LocalResource myConfigsStorage = RoleEnvironment.GetLocalResource("myConfigs");

        System.IO.File.WriteAllText(myConfigStorage.RootPath + "myFile.txt", text);
    }
    else
    {
        System.IO.File.WriteAllText(myConfigStorage.RootPath + "myFile.txt", "no data");
    }

Easy enough you say.  Yes, the API is straightforward enough so as to appease most .NET developers.  However, a bigger issue with regard to this local storage must be considered.

Local Storage is Temporary and Instance Relative in the Cloud

Local storage, like that just used in the example to read/write text to myFile.text is temporary in Azure!  So, if the virtual machine supporting your role dies and cannot recover, your local storage is lost!  Therefore, Azure developers will tell you, only volatile data should ever be stored in local storage of Azure.  Furthermore, I eluded earlier to the fact that the storage was per instance of a role.  Importantly, local storage is not shared across multiple role instances.  Usually, people move applications to the cloud to take advantage of the scalability and redundancy multiple instances provide.  But these instances each have their own local storage and cannot access each others.  If the data in the local storage is changing and must be shared, you need to rethink the application design.

Local Storage Alternatives

If you need to read/write data in the cloud in a non-volatile and shared way , take advantage of Azure's storage options:  blobs, table storage, queues and SQL Azure databases.  My co-worker Tim Star (Microsoft MVP) has described them in his blog post here.  This may require some application re-architecting, but in the end, your application will run better, stronger, faster in the Azure cloud.

By Jim White (Intertech Instructor and Director of Training)

Last Thursday (April 15th), I presented in our virtual classroom on RESTful Web Services in Java, an introduction to the new JAX-RS API.  You'll find links in this blog to the presentation and demo code shown in that talk.  During the talk, several attendees posted questions on RESTful Web services which I did not have time to answer during the session.  Below, I have tried to answer the remaining questions.

1.  Can you address security in RESTful services?

Since most RESTful Web services rely on HTTP, you can use HTTPS and/or existing HTTP mechanisms to secure your RESTful Web services.  By design, RESTful Web services are lighter-weight that their SOAP counterparts.  Therefore, the kinds of security standards that exist in WS-* specifications are formally available in RESTful settings.  Some RESTful advocates suggest RESTful Web services are actually more secure because they rely on the Internet's existing security infrastructure (see http://www.networkworld.com/ee/2003/eerest.html?page=1).  

In general, you pretty much have to adopt/roll your own with regard to security.  I have started to see some third party (many open source) packages that provide security options for RESTful Web services, but these are not guided by any standard.

2. How is Jersey ( JAX_RS)  different than Servlet based REST mechanism like Restlet. I can see Jersey has AdapterServlet too? Is Jersey  based on Servlet too then?

Jersey is an JAX-RS implementation.  RESTlet is a way to provide RESTful services in Java, but it is not guided by any standard.  In JAX-RS, your RESTful resource services are implemented as annotated POJO's.  In RESTlet, the resource service classes extend ServerResource so some consider this a bit of a burden and intrusive.

The RESTlet group does now have an extension package with allows implements the JAX-RS specification.  See here for more details.

For more comparisons of JAX-RS (and implementations like Jersey) to RESTlets, see the following links:

http://thestewscope.wordpress.com/2008/01/08/rails-jsr311-restlet-and-jersey/

http://stackoverflow.com/questions/80799/jax-rs-frameworks

Per part 2 of your question, yes a servlet does act as a controller to route traffic to the appropriate annotated Jersey resource service.  In that way, both RESTlet and Jersey are similar in their reliance of servlet technology.

3. What is the best way to supply the request=GetCapabilities for REST that one has in SOAP or WMS services to communicate meta-data of REST services?

Many RESTful advocates would say the "conventions" associated with RESTful services makes a capabilities listing unnecessary.  That is, the resource as noun and HTTP method as verb make the services very transparent and easy to work with.

That answer doesn't satisfy many.  There have been home grown solutions like that provided by ebay (see http://developer.ebay.com/products/shopping/) that provide a useful API/description for developers to use.  Others have found a way to wedge RESTful descriptions into WSDL.  However, a relatively new description language called Web Application Description Language (see http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1265367,00.html) is being used in the RESTful community to provide a WSDL-like alternative in the RESTful arena.

4. Can we run a rest web service using https protocol?

Yes

5. How about Spring and REST?

As of Spring 3.0, Spring offers RESTful API, but it is not JAX-RS compliant.  See here for details.  In general, Spring makes use of the annotated MVC controllers to serve as RESTful resources.

6. is there simple/lightweight authentication capabilities with restful web services?

Per #1, again nothing formal is provided, but there are some 3rd party packages sprouting up and all the standard Web authentication mechanisms could be used

7. Is there a way to override the HTTP return error and give more detail?

Yes - to some extent.  For how to modify the message returned from the Jersey implementation see https://jersey.dev.java.net/nonav/documentation/latest/user-guide.html#d4e410.

8. A lot of time was spent on exposing a service using JAX-RS from the server.  On the client, what does REST provide (or not provide) as a 'contract' to be used to define the web service..similar to the WSDL, etc in SOAP (for client-side data binding, etc.).

As mentioned and demonstrated in my talk, JAX-RS does not provide for a client API or contract.  Since REST normally operates on HTTP, one could develop a client using java.....  However, many JAX-RS implementations (like Jersey and RESTEasy) offer client side APIs.  These are non-standard, but do offer a means to more easily communicate with RESTful services independent of implementation.

9. It should be noted to get JSON to output correctly for web-applications (i.e.. {'id':12} instead of {'id':'12'} - supporting primitives as primitives, or handling of arrays properly etc, you need to setup a JAXBContextResolver and dictate the notation to user / type.  JAXB will not 100% give this to you.  You need to map your JAXB annotation to a JSON mapping using a context resolver.   Jersey website/forums do have some notes on this and I have been very successful using Natural Notation with GWT/GXT clients.

Correct and thanks for the providing the extra insight.

10. Twitter's REST API is also pretty good reference if you're trying to grow your own app and don't know where to start. http://apiwiki.twitter.com/Twitter-API-Documentation.

I agree.

11. How do we handle streaming using REST based approach?

There is nothing specific in the current JAX-RS specification about how to handle streaming content.

12. client-side data binding?  Thoughts on Spring 3 MVC as an impl?

Per #5 above, Spring 3 through MVC annotations does provide a RESTful service API but it is not Java spec compliant.  If one was using Spring heavily, I could see an attraction to using the same annotated Spring controller classes for both human Web facing and machine RESTful facing clients.

Thanks for all the great questions, comments and feedback  on our presentation.  I hope you will consider attending our Complete Java Web Services class.

If you did not have a chance to catch the free Intertech Oxygen Blast training event on April 15th (RESTful Web Services in Java), you can get the slides and code from the links below.

Slide Presentation:  http://www.intertech.com/downloads/JAXRS-OxyBlast.pdf

Code Samples:  http://www.intertech.com/downloads/JAXRS-OxyBlast.zip

Also, the presentation was recorded and can be replayed at the link here.

by Jim White (Instructor and Director of Training)

Last week, I had a group of experienced Java developers attend my Complete Hibernate class.  They had several great questions, some of which I plan to highlight with a few blog posts over the next week or so.  In today's post, I would like to address how the overloaded load( ) methods work in Hibernate (this question was posed by Chris - thanks for the great questions Chris).

Retrieving A Persistent Instance in Hibernate

First off, a bit of background.  There are two methods that can be used on a Hibernate session (org.hibernate.Session) to retrieve a single instance of persistent object:  get( ) and load( ).  In fact, both methods are heavily overloaded, meaning there are several methods with the same name but that take different parameters.  So in fact there are far more than two methods.  While both get( ) and load( ) methods retrieve a persistent object by its identifier, these two types of methods operate a little differently.

Difference Between get( ) and load( )

The get( ) methods always hit the database.  Meaning, as soon as the call to get( ) occurs, Hibernate issues an SQL statement to the database in an attempt to fetch the associated data (usually a row in the database) to rebuild the requested persistent object.  A call to load( ), on the other hand, does not immediately incur a call to the database.  The load( ) method causes a proxy object to be constructed as a stand-in for the persistent object.  It is only after some state is requested from the proxy that Hibernate issues the appropriate SQL to the database and builds the real persistent object.  When using get( ), the method will return null if no data exists for the requested identifier.  Since the load( ) method does not immediately retrieve the object, if no data exists for the identifier used to retrieve the object, an ObjectNotFoundException is thrown once data is requested of the proxy.

Overloaded get( ) and load( ) Methods

As I mentioned, both the get( ) and load( ) methods are heavily overloaded.  There are four of each methods that take the same parameters:  the class (either a Class object or String name), persistent object identifier, and optionally a lock mode (for pessimistic locking).  The four methods of each are outlined in the table below.

get(Class clazz, Serializable id)

load(Class clazz, Serializable id)

get(Class clazz, Serializable id, LockMode lockMode)

load(Class clazz, Serializable id, LockMode lockMode)

get(String className, Serializable id)

load(String className, Serializable id)

get(String className, Serializable id, LockMode lockMode)

load(String className, Serializable id, LockMode lockMode)

An Extra load( ) Method

There is an additional load( ) method that was at the heart of Chris's question.  The last of the overloaded load( ) methods takes an existing instance of the persistent class and the identifier of the persistent instance to be retrieved.

load(Object object, Serializable id)

This load( ) method will read the persistent state of the requested object directly into the existing instance provided.  In fact, since you pass in the instance whose properties are to be set with state, the method returns void.  What's more, like the get( ) method, it will cause Hibernate to issue an SQL request immediately to the database.  Care must be taken with this method in that any state that exists in the object passed to the method will be replaced by data found in the database - even the id will be replaced by the id of the persistent object retrieved!

To see how load(Class clazz, Serializable id) differs from load(Object object, Serializable id), take a look at the two sections of code below, each followed by the output issued from the code when executed.

Example of using load(Class clazz, Serializable id)

public static void main(String[] args) {
    SessionFactory sf = new Configuration().configure()
            .buildSessionFactory();
    Session session = sf.openSession();
    Contact c = (Contact)session.load(Contact.class, 1L);
    System.out.println("Before any request of the proxy or persistent object -------.");
    System.out.println("Contact retrieved ---- >" + c);
    System.out.println("After a request of the proxy or persistent object -------.");
    session.close();
}

Output from example above

Before any request of the proxy or persistent object -------.
Hibernate:
    select
        contact0_.id as id0_0_,
        contact0_.first_name as first2_0_0_,
        contact0_.last_name as last3_0_0_,
        contact0_.date_of_birth as date4_0_0_,
        contact0_.married as married0_0_,
        contact0_.children as children0_0_,
        contact0_.org_id as org7_0_0_,
        contact0_.spouse_name as spouse8_0_0_,
        contact0_.spouse_date_of_birth as spouse9_0_0_,
        datediff('yy',
        contact0_.date_of_birth,
        curdate()) as formula0_0_
    from
        Contact contact0_
    where
        contact0_.id=?
Contact retrieved ---- >Jim White(1)
After a request of the proxy or persistent object -------.

Notice how, in this example, SQL is not issued until data from the Contact object is used (as part of the toString in the println request).

Example of using load(Object object, Serializable id)

public static void main(String[] args) {
    Contact c = new Contact();
    c.setId(1234L);
    c.setFirstName("John");
    c.setLastName("Doe");
    SessionFactory sf = new Configuration().configure()
            .buildSessionFactory();
    Session session = sf.openSession();
   session.load(c, 1L);
    System.out.println("Before any request of the proxy or persistent object -------.");
    System.out.println("Contact retrieved ---- >" + c);
    System.out.println("After a request of the proxy or persistent object -------.");
    session.close();
}

Output from example above

Hibernate:
    select
        contact0_.id as id0_0_,
        contact0_.first_name as first2_0_0_,
        contact0_.last_name as last3_0_0_,
        contact0_.date_of_birth as date4_0_0_,
        contact0_.married as married0_0_,
        contact0_.children as children0_0_,
        contact0_.org_id as org7_0_0_,
        contact0_.spouse_name as spouse8_0_0_,
        contact0_.spouse_date_of_birth as spouse9_0_0_,
        datediff('yy',
        contact0_.date_of_birth,
        curdate()) as formula0_0_
    from
        Contact contact0_
    where
        contact0_.id=?
Before any request of the proxy or persistent object -------.
Contact retrieved ---- >Jim White(1)
After a request of the proxy or persistent object -------.

Using load with an existing object, you see that SQL is issued immediately (even before a request of the object is made).  The data retrieved replaces all the existing data in the Contact object (referenced here as 'c') during the load operation.

As with other forms of the load( ) method, an ObjectNotFoundException is the result when you try to retrieve an object with an identifier that does not exist.  However, because SQL is immediately issued to populated the existing object, the exception is thrown on the call to load( ).  In contrast, the ObjectNotFoundException will be thrown when accessing the proxy produced by other forms of the load( ) method.

Wrap Up

So while get( ) and load( ) methods on Hibernate's session object each have the same ultimate purpose (to retrieve a persistent instance) both behave a bit differently.  And, in fact, as you've seen there are also some differences in the behavior of various forms of the overloaded load( ) method.  If you would like to learn more about Hibernate, I encourage you to take Intertech's Complete Hibernate course.  We'd love to have you in our classroom, but you can also take the class virtually.