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.

I have been working with Java and its related technologies since 1997 - the first two years managing a team using the pre-release, 1.0, and 1.1 versions (primarily for the cross-platform benefit to make new front ends for a Unix/C++ system) and the remainder years as a consultant with Intertech. One of my favorite things about Java is its ecosystem, having watched a number of things form (and fade!) during that time.

Recently I had another conversation about its amazing ecosystem, commenting on the various facets of it - such as the JVM, community, products, support, maturity. With the community, it is mind blowing how many free-open-source (FOS) framework and tool products exist and continue to emerge. Yes, many are junk, unfinished, or just interesting (or not!) experiments. However, there are some very useful, successful, proven, well-adopted, and supported ones. We talk about some of them in everyday conversation - Spring, Hibernate, Tomcat, Maven, Ant, Eclipse, et al - almost taking them for granted. The Java ecosystem has enabled many successful new, and expansion of existing, companies.

At the onset, FOS software were few, far-between, and disorganized. Out of chaos emerges organization. Forges, such as SourceForge, emerged to provide some organization and aggregation. Curators such as Apache emerged to help foster higher quality, support, and consistency levels. More recently, Google established Google Project Hosting. Java FOS is very alive and well - thriving in fact. SourceForge reports over 43,000 Java projects.

The community around the FOS products is very large. Most of the products, particularly active ones, will have one or more email lists for help and discussion of the product, and I've seen this support exceed some of the commercial product support! Some products have individuals and/or organizations also offering commercial support contracts for escalated support response and priority for new features and correcting defects. Additionally, organizations using well-adopted FOS products also have an easier time finding people with existing skillsets in them - often learned from and participating in the FOS community.  Just look at some of Intertech's Java training offerings - Eclipse, Spring, Hibernate, iBatis, Struts...!

Another interesting facet of FOS in general is the corporate involvement in creating and supporting it. Besides individuals donating their time and talent, companies such as Google open source their free products that their employees create. Many of us use the Eclipse IDE.  IBM initiated this product and subsequently donated it to the newly established Eclipse Foundation (Eclipse has a very impressive release track record - the processes, tools, and coordination required to is a topic of its own!).  I have had a number of business people ask me about this - fascinated that companies and we developers would do this - and this is yet another topic of its own! :-)

The core enabler of Java's ecosystem is the JVM. It is highly performant, stable, and many languages can run on it. Besides the Java language, better-known ones are Groovy, Scala, JRuby, and Jython. Even ColdFusion has migrated to a JEE application that runs the CF apps. An interesting browse is the VM Languages blog - this site has listed over 300 languages that run on the JVM as of Feb 22, 2010: http://www.is-research.de/info/vmlanguages

Targeting the JVM with your language(s) of choice provides a flexible runtime environment. Most of us also know that there are JVMs for many different platforms, such as Mobile, Windows, UNIX, GNU/Linux, and mainframes. This allows your applications to run on the correct class of hardware for needs such as scaling and operations team skills/support. It also allows developing on the developer workstation of choice, e.g. Mac, Windows, GNU/Linux Desktop, and deploying to a potentially different operations environment, such as Solaris, or a multi-platform runtime environment.

Java's innovating ecosystem expands to other platforms too. A number of its tools and frameworks have been ported to other languages/environments, particularly .Net. For example, Ant -> NAnt, Maven -> NMaven, Spring -> Spring .Net, JUnit -> NUnit, CPPUnit (and many others).

My goal in sharing this is not an in-depth essay of all the merits of Java's ecosystem, but to share some of the recurring conversational points I have had, possibly encouraging you to further explore any of them. Java is very popular and successful, and its ecosystem is simultaneously a contributor and a result of it.

As a leader, lining up what we say and what we do is imperative.  Character and integrity are measures of how closely what someone says lines up with what they do.  Retired Medtronic CEO Bill George makes this point in his book Authentic Leadership: “If you want to see employees become cynical, just watch what happens when the top executives behave in ways inconsistent with the company values.”  He’s right because leadership is all about setting a positive example for others.  There’s an Italian saying that “a fish rots from the head down.” I believe this is true in business—if things aren’t well in a company and you’re the leader, the first place to look is in a mirror—not out a window.  How does a leader exhibit true character? To me, it comes down to a lot of simple but extraordinarily important actions, such as:

• Taking the blame when you’ve made a mistake. It’s the right thing to do and it increases your credibility with your team. Jim Collins has said that “Great leaders look in a mirror when there is a mistake and look out a window when there is a success.” 
• Giving away credit. In my experience, doing so rewards you at a rate of at least ten times what you gave away. It’s amazing what can be accomplished when no one cares who gets the credit.
• Being willing to make mistakes. As my father, Ted Salonek, taught me, “if you do nothing, you’ll make no mistakes.” So don’t be afraid to try and don’t be afraid to fail.
  

The mirror and window concept of a leader is discussed in depth by Jim Collins in his definition of a “Level 5” leader, which he calls the highest level of leadership and defines as "fierce will combined with humility." This combination makes the leader put the interest of the company ahead of his personal interest.  

Tom’s Takeaway:  True leaders take the blame when they've made a mistake but are quick to give away credit to others.

A useful but not widely publicized feature of the Oracle.ODP database provider for .NET is the ability to execute SQL scripts as a single command. It's quite easy to use the capability but there are a few caveats that are worth being aware of to save time and frustration.

Let's start by looking at a simple example of executing a single SQL statement using ODP:

using System.Configuration;
using Oracle.DataAccess.Client;

namespace OracleODP
{
    public class SingleStatementSample
    {
        public static void Main(string[] args)
        {
            var sql = "INSERT INTO TEST_TABLE( NKEY, STEXT ) VALUES( 123, 'HELLO WORLD' )";

            var connString =  ConfigurationManager.ConnectionStrings["Default"].ConnectionString;
            using (var conn = new OracleConnection(connString))
            using (var command = new OracleCommand(sql, conn))
            {
                conn.Open();
                command.ExecuteNonQuery();
            }           
            
        }
    }
}
 

Nothing terribly surprising here. We get a connection string from configuration, create a new OracleConnection, and a new OracleCommand with a simple INSERT statement as the command text.

So how do we run multiple statements in a single command? Well, a reasonable first guess may be to add multiple statements directly to our SQL string and separate them with the typical ";" separator:

  var sql = @"INSERT INTO TEST_TABLE( NKEY, STEXT ) VALUES( 123, 'HELLO WORLD' );
              INSERT INTO TEST_TABLE( NKEY, STEXT ) VALUES( 456, 'HELLO AGAIN' );";
 

Unfortunately, this won't work with Oracle; try it and you'll get an error that looks something like:

  Oracle.DataAccess.Client.OracleException: ORA-00911: invalid character.
 

Informative, isn't it? Fortunately, the solution is quite simple: surround the statements in an anonymous PL/SQL block:

 var sql = @"BEGIN
            INSERT INTO TEST_TABLE( NKEY, STEXT ) VALUES( 123, 'HELLO WORLD' );
            INSERT INTO TEST_TABLE( NKEY, STEXT ) VALUES( 456, 'HELLO AGAIN' );
            END;";
 

Can it really be that simple? Well, yes ... and no. Using anonymous blocks comes with some considerations that you should be aware of.

Line Break Considerations

Surprisingly, Oracle can be quite picky about what characters it accepts as legitimate line breaks. In Windows, a line break is typically a carriage return (CR), line-feed pair (LF) pair; while on Unix and Linux platforms, line breaks are represented just by a carriage return. Unfortunately, depending on where your script content originates, you may inadvertently have CR/LF pairs in it. Most often, this would be the case if you read your SQL script from a file or an embedded resource - where the normal encoding would use CR/LF. 

Unfortunately, the error message you get from Oracle isn't very helpful if you run into this situation:

  Initialization method Tests.AnonymousBlock.TestScript threw exception:
    Oracle.DataAccess.Client.OracleException:
    Oracle.DataAccess.Client.OracleException: ORA-06550: line 1, column 6:

  PLS-00103: Encountered the symbol "" when expecting one of the following:

   begin case declare exit for goto if loop mod null pragma
   raise return select update while with <an identifier>
   <a double-quoted delimited-identifier> <a bind variable> <<
   close current delete fetch lock insert open rollback
   savepoint set sql execute commit forall merge pipe.
 

While I haven't been able to find any definitive documentation, empirical testing shows that Oracle will accept a CR as line break but not necessarily a CR/LF pair. To be safe, I replace CR/LF pairs with CRs before using them:

  command.CommandText = sql.Replace("\r\n", "\n");
  

DDL vs. DML Considerations

Another factor that can come into play is when trying to execute DDL statements in a PL/SQL block rather than DML statements. DDL consists of statements that describe or modify data structure rather than their contents. Oracle does not support executing DDL statements directly within an anonymous block. Surprisingly, some statements that you may think are DML are actually DDL - the best example of this the TRUNCATE command:

  TRUNCATE TABLE IBS_ROUTED_EVENT;
 

The above code looks like regular data manipulation language, but it's actually DDL and cannot be executed in an anonymous block. If you try you'll get something like:

 Oracle.DataAccess.Client.OracleException:  
   Oracle.DataAccess.Client.OracleException: ORA-06550: line 4, column 12:

   PLS-00103: Encountered the symbol "TABLE" when expecting one of:
     := . ( @ % ;
 

...another case of a less than helpful error message. Fortunately, all is not lost. It's possible to execute DDL within an anonymous block using the EXECUTE statement:

  EXECUTE IMMEDIATE 'TRUNCATE TABLE IBS_ROUTED_EVENT';
 

The DDL statements in Oracle include: ALTER, COMMENT, CREATE, DROP, RENAME, REPLACE, and TRUNCATE. The EXECUTE IMMEDIATE statement accepts a dynamic SQL statement as a string, hence the need for single quotes around the SQL to run.

One important consideration when executing DDL (whether in an anonymous block or otherwise) is that DDL always performs in implicit commit. This is a critical fact to keep in mind - when you execute DDL any pending work will automatically be committed. Once this happens, you cannot roll back or undo anything prior to the DDL statement. Consequently, I generally advise developers to avoid using DDL in SQL - there's usually a better alternative.

Returning Values From Anonymous Blocks

The last topic we will look at is how to return results from an anonymous block. It turns out, Oracle.ODP makes this relatively easy, if a bit unintuitive.

The OracleCommand class allows parameters to be attached to the executed statement - parameters may be either input, output, or both. Adding a parameter can be done directly through the OracleCommand object. Here's an example that uses both input and output parameters:

    public static void Main(string[] args)
    {
        var sql = @"BEGIN 
                      INSERT INTO TEST_TABLE( NKEY, STEXT ) VALUES( SEQ1.NEXTVAL, :value1 )
                        RETURNING NKEY INTO :key; 
                    END;";

        var connString = ConfigurationManager.ConnectionStrings["Default"].ConnectionString;
        using (var conn = new OracleConnection(connString))
        using (var command = new OracleCommand(sql, conn))
        {
            conn.Open();
            
            // add parameters
            var p1 = command.Parameters.Add(":value1", "Hello World");
            // make the :key parameter an output param
            var p2 = command.Parameters.Add(":key",null);
            p2.Direction = ParameterDirection.Output;
            p2.OracleDbType = OracleDbType.Int32;

            command.ExecuteNonQuery();

            // print the returned value...
            Console.WriteLine("The new record's key is {0}", p2.Value);
        }

    }

The example above uses the RETURNING ... INTO ... syntax to allow a sequence-assigned value to be returned to the caller. This is a useful technique that allows any value computed at the database to be returned to your .NET code. Sweet!

Why Execute Statements as a Script?

Now that we've looked at how we can execute SQL scripts, let's take a brief look at why we may choose to do so. Executing multiple SQL statements as a script offers a number of advantages:

• It performs all of the work in a single trip to the database
• It automatically treats all of the work as a single transaction
• It simplifies the .NET code you write to execute several commands
• It allows bind variables to apply to multiple statements
• It allows results of a computation or SQL operation to be cached
• It allows you to mix regular SQL with PL/SQL statements

Most of these benefits should be self-explanatory - but a few deserve a little more.

When code is combined into a single anonymous block, any bind variable are available in all SQL statement within that block. As a result, it's possible to reuse a single bind variable - which simplifies both the SQL code and the .NET code that prepares and executes it. If you do choose to reuse bind variable, make sure that they are input-only. Output bind variables cannot be reused.

An anonymous blocks may optional include declarations of local variables - variables that may be initialized or set by statements within the block. Not to be confused with bind variables, local variables must be defined in their own DECLARE section which appears before BEGIN:

 DECLARE
   -- declare record variable
   dept_rec dept%ROWTYPE;  
   -- declare cursor variable
   CURSOR c1 IS SELECT ename, sal, hiredate, job FROM emp;
   -- declare simple variable
   empSalary REAL(7,2);
 

Mixing SQL and PL/SQL in an anonymous block is convenient, however, generally what we want to do is repeat the same operation several times with different values. An example is inserting several records into the database in one trip. While we can do this by expanding the SQL directly into the anonymous block, a better approach is to use array binding to pass multiple parameters to the database. This technique will be the topic of a future blog post. For now, take a look at the linked Oracle article, and keep in mind that bind variables are the preferred technique to pass parameters to Oracle - they reduce SQL injection risks and allow the database to avoid parsing SQL statements over and over again.

The Wrap Up

So let's review what we've learned :

1. Oracle ODP allows you to execute multiple statements together in a single database using an anonymous block.
2. Anonymous blocks are sensitive to line-break encoding, so replace your CR/LF pairs within a single CR character to avoid problems.
3. Anonymous blocks support mixing SQL and PL/SQL statements, and can even include DDL statements using the EXECUTE IMMEDIATE.
4. Anonymous blocks can use local variables defined in the DECLARE section, allowing expensive data to be computed once and cached.
5. Anonymous blocks support both input and output parameters, allows results to be returned back to the caller.

The word “leadership” has many definitions.  For me, leadership has two primary parts—how we think and what we do.  First and foremost, as a leader, it’s our responsibility to exercise thought leadership.  Earl Nightingale made the statement, “We become what we think about.” For leaders, this means having a positive attitude, believing in what’s possible, and anticipating the future before it happens.  

When problems occur, it’s only natural for your employees to look at you and wonder how you’ll react.  If you are fearful and believe the proverbial sky is falling, don’t be surprised when your people follow suit.  On the other hand, if there are problems and you define a goal that solves the problem, have a game plan, and move quickly into executing, your people will approach problems the same way.  In times of trials, “Adversity doesn’t build character.  It reveals it.”  

Tom's Takeaway: Leadership begins in the mind.  Think positively and your actions will follow.

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 (Director of Training and Instructor)

I just finished a review of Azure in Action by Chris Hay and Brian Prince (Manning Publications).  This book is to be formally released later this summer (August 2010).  You can get an early electronic copy at www.manning.com/hay.

If you are exploring or actively developing applications for Windows Azure, this is a must have book.  Windows Azure is Microsoft's public platform as a service (PAAS) entry in the cloud computing arena.  I have already written in this blog (see here) about the potential importance and impact of cloud computing and platforms like Windows Azure on our industry.  I believe this is where our industry is headed and Azure in Action will help you navigate the "clouds"in Windows Azure form of this new atmosphere.

While this book does provide instruction on the basics of Windows Azure, the Azure SDK and API, potential readers will be happy to find that its real assistance is in getting you to think about real world design and architectural aspects of your applications running in the cloud.  Hay and Prince challenge the reader to think about how running in the Azure cloud impacts performance, organization of data and costs of operating in the cloud.  They do a good job of laying out options and providing you with the pros/cons of those options as they might apply in your application setting.

For example, in Chapter 6 (called "Scaling web roles"), they cover session management.  While you may find that porting a typical ASP.NET application to Azure is straight forward, Hay and Prince inform you that with regard to something like persisting data across requests you have to consider potential issues such as the fact that "Windows Azure does not consistently implement sticky sessions."  As you scale, session management becomes a bit more complicated.  They provide information about what session management is and how it works and then provide alternative implementation options (such as In-Process and Table Storage session management).

Azure in Action also peels back the covers on how Azure works under the covers - in the Microsoft data centers.  I found chapter 3 (titled "How it works") particularly fascinating.  The information they provide on the lengths and efforts Microsoft have taken to provide the computing foundation and data centers in which Azure runs should give all of us writing applications for this platform a bit of confidence in the platform's future.

A word of warning, the Manning Early Access Program (MEAP) version of the text is still in the midst of the editing process.  So there are still quite a few typos, grammatical issues, and even a couple of code samples that need to be corrected.  One would assume those would be taken care of before the book formally comes out this summer.

If you are looking for an API reference on Windows Azure, dial up the MSDN site on your local browser.  But if you are looking at how to design/write real world applications that scale and perform well in the Windows Azure cloud, help yourself out and download the MEAP version of Azure in Action today.

In fast-moving environments--most companies today--daily huddles can keep communication consistent and effective. We use huddles and keep them to 15 minutes max. Each team member gives an update and a "daily number" is shared, which measures the overall health of the project. If you have six data consecutive points in any direction you have identified a trend. Each member also shares a "stuck item," which highlights problematic areas early and enables the slaying of monsters while they're still small. Huddles can cascade to keep everyone on the same page. For example, it there are three project teams working on the overall project, the separate project teams have a huddle followed by a huddle of three project teams and their superior. Tom's Takeaway: It can be tempting to forgo communication tools, like huddles, especially when you're in the end game and near project completion. Don't give into this temptation because this is when clear and consistent communication is most critical to project success.

At the start of a project with the team is in place, it's time for everyone to roll up their sleeves and define the problem to be solved. This may strike some as an unnecessary step, even a waste of time. Let me assure you: it's essential. There's an adage, "a problem defined is half solved." I believe this is especially true in software development. In fact, an IBM study found that well-defined objectives were the number one factor in successful projects.

• A good project definition should include: 
• A project plan defining the vision, Critical Success Factors and areas of responsibility. 
• A requirements document defining when the project is complete. 
• A prototype, mockup or demo that provides a visual tool for clearing up misunderstandings. 
• A Gantt chart or Sprint Plan stating who, when, what and related interdependencies. 
• A risk plan defining what might go wrong and what to do if it does.

Tom's Takeaway: Beginning a project without a clear definition and plan is like building a house without a blueprint.

What should a company do if it suspects its IT provider, or any crucial vendor, isn’t working out? Look for warning signs—missed dates, misunderstood expectations -- and if a switch to another vendor is unavoidable:

• Start by getting a copy of the all project code and build information. Also obtain the project plan, functional specifications, design documents and models, and all documentation.
• Select a replacement using referrals. When interviewing potential providers, ask questions that could have eliminated your previous provider.
• Ask the prospective provider about projects that didn't go as planned.
• When you make the switch, be directly involved. In working with your new provider, be upfront about what occurred with the previous provider.
• Don't wait until the first milestone to find out that key pieces of information, components or tools don't exist. Eliminate excuses.
• Keep the new vendor delivery-focused and watch out for the dreaded "not invented here" syndrome. That can occur when the new group wants to go back and change work completed by the previous provider -- not because the work was defective but because it wasn't built the way the new group would have preferred. If the new provider is insisting on rework, ask why and be sure to separate aesthetic squabbling from real performance issues.

Tom's Takeaway: In the end, changing your IT vendor, or any vendor, midstream isn't fun. But, with preparation and foresight, changing vendors won’t cause your project to sink.