For all of you who are constantly writing and debugging your
persistence code, have I got a tool for you.

Check out Firestorm.

Firestorm can reverse engineer just about any database out there and
generate Core J2EE Pattern compliant DAO, 
JDO and Hibernate code. The
latest version even supports Dynamic Inserts.

Here’s a blurb from their web site:

“FireStorm/DAO adopts a pragmatic
approach of generating Java source
code for data persistence that is a direct mapping of a particular
relational database schema. It is also possible to define complex
multi-table queries and to leverage existing database logic contained
within stored procedures.”

This is a very cool tool.

Check it out!

We’re in the process of renovating our kitchen.  In our kitchen
design, we’re actually constructing a new structure to extend the
current kitchen. If any of you have gone through this, I’m sure you
have lots of war stories. But, as my wife and I go through this
process,  I keep seeing similarities between renovating a kitchen
and building a SOA.  To understand what I’m talking about, 
I’ll start by making some role comparisons:

When renovating a kitchen there are usually four key roles; home owner,
kitchen designer, architect and construction crew. In SOA, there are
similar key roles; business manager, business analyst, SOA
architect and development team. These four roles tend to have similar
responsibilities as shown below.

The most important person in a kitchen renovation is the home owner.
In SOA, the most important person is the business owner, who is
usually the business manager.  Essentially, it’s who owns the
budget and writes the check.

You can renovate a kitchen without a kitchen designer, but I don’t
recommend it. Kitchen designers have the best  understanding of
the
requirements and features of a kitchen. Even building architects will
tell you to bring in a kitchen designer to insure good flow, appliance
placement, cabinetry, flooring, zoning, etc.

Similar to a kitchen designer is the SOA business
analyst. Just as you can renovate a kitchen without a designer, you
can build a SOA without a business analyst.  But, I also don’t
recommend
this. The business analyst understands the business and business
requirements and acts as a liaison between the SOA architect and the
business unit. It’s the business analyst who translates business
requirements into information to help the SOA architect design the
system. Kitchen designers tend to act as a liaison between the home
owner and the building architect. Just like the business analyst is
driven by the business unit
has to support the
business objectives, the kitchen designer supports the home owner’s
objectives.

Then there’s the building architect who is core to the overall kitchen
design. He/she is the one who has to take all the requirements of the
kitchen designer and the home owner and turn that vision into a
set of architectural blueprints. These blueprints are used for
permits, cabinet sizing/layout, construction cost estimates and
eventually
become the master construction plans. If the blueprints are wrong or
incomplete it trickles down to all levels and eventually ends up
costing the home
owner much, much more.

Finally, there’s the kitchen construction team. The construction
company
bids on a project based on the complexity of implementing the
blueprints, material and labor costs and a slew of other cost factors.
You can probably imagine what can and will possibly go wrong in this
model if all parties aren’t aligned. If the homeowner changes the
requirements mid-stream, change order costs incur. If the kitchen
designer mis-calculates the cabinet dimensions and the cabinets don’t
fit, it delays the overall schedule, which translates to added costs.
You get the idea. So much can go wrong if all stakeholders are not in
complete sync in both the kitchen renovation and SOA world.

Here’s probably the first best practice you should put into place when
building a SOA:

Build a SOA with the business unit!

Here’s what I mean. I keep seeing IT groups defining and building
a SOA without engaging the business unit. Who, by the way, is their
customer.  An example is an IT group building a SOA common
services infrastructure (management, registry, policy, etc) as a set of
services for the business unit to run their applications. But, they are
building it without the business unit. Which leads me to:

Build a SOA without the business
unit and watch them \*not\* come!

Seems so obvious, but it really isn’t. IT groups have grandiose
plans as to what infrastructure services they will provide and
build  without even really knowing what the business unit needs.
Why build 101 management features into the management service if the
initial business unit application only needs 3.

Don’t get caught in this trap. Get the business unit involved from the
start and build the services based on their requirements. And most
importantly:

Build the SOA incrementally!

I think companies are starting to see the amazing impact SOA can have
on their overall business value proposition.

Think about Amazon.com. Most people would say that Amazon.com is a site
to buy lots of products. In their mind,  Amazon.com’s website and
Amazon.com the company are the same. But, Amazon doesn’t appear to see
it that way….

As an Amazon outsider (which means I’m hypothesizing to make a point),
I bet it went something like this:

Amazon.com,
the beginning:
    \* Business Unit:
Leverage this thing called the Internet and create a website to sell
books to the world. Make tons of money. Build an easy-to-use website so
people of all ages can buy books. Track their buying patterns and let
them rate the books so others can see.

    \* IT: Ok, we
can build an awesome, intuitive web site and a commerce engine to
support it.

So, basically, Amazon.com the website and Amazon.com the commerce
engine were one. In other words, the commerce engine needed to support
one channel; the Amazon.com website.

But, as time went on, the smart people at Amazon.com started
recognizing the web services potential. They provided REST and SOAP
apis so developers/companies could access their services outside of the
Amazon.com website. Developers liked this and were amazed at the
simplicity and power in being able to access Amazon.com’s powerful
commerce engine. But, there was something else happening.

A few years ago I did a search for a product on Amazon.com and it
showed me the same product from partners at a lower cost than
Amazon.com was offering. I thought I found a bug and tried it again.
Same thing happened. Amazon.com was revealing partner products at lower
prices on the same page as their higher price. From the periphery, this
made little business sense. But, thinking about it, it become genius.

It looked like Amazon.com had begun treating Amazon.com the website and
its partners as close equivalents. But,  more importantly, if
Amazon.com’s  commerce engine was actually separated  from
Amazon.com the website, then it sounds like their business model
changes from selling products on Amazon.com, to generating revenue from
their commerce engine. And this is my point and the value SOA can bring
to radically (and rapidly) change a business. You can already see this
happening at eBay and Google.

Think about this. What if AOL didn’t have a web presence anymore, but
offered (probably) the world’s largest digital asset management system
(picture, video, music, etc) as services so others could build business
on them. Sounds like a SOA opportunity to me. Why didn’t AOL build the
worlds best digital picture SOA for others to build a business. If they
had, Snapfish, Ofoto (now Kodak Gallery), etc could have built their
business on it and AOL would have reaped big rewards.

Is WebEx a web-based meeting company or do they provide a web-based
meeting infrastructure. WebEx just opened their APIs  as web
services and already companies are sprouting up which run on the WebEx
services. Wait until ISVs start picking up on the fact that everyone
needs web-based communication within their applications. Are they going
to build their own or access WebEx’s services. In the future, I predict
WebEx makes more money on it’s SOA communication services than the
actual WebEx brand offering.

I want to finish up with a graphic of what I think will be the way we
think about how SOA can open up new and amazing business opportunities.
Not just for existing companies, but new companies which build on these
services. I like to call this new type of company, the Composite Company.
Imagine the opportunity when companies such as AOL, Google, eBay, etc
all open up their services and have a uniform identity scheme. The
types of Composite Companies
who aggregate and provide a service on top of these rich services will
provide services not available today.  It’s mind-boggling to think
what will happen when businesses provide SOA services as their core
competency and Composite Companies
begin to arrive.

Just finished the California leg of the U2 tour with Mary and Danny. That’s right, the U2
tour! Unbelievably, the  TED
prize granted Bono three wishes and we (Sun) are delivering on one of
the wishes. The wish is: Bono wants to
utilize technology to enlist his fans into his army against AIDS and
poverty.  You can check out the video on One.org

So, driven by Mary, with Danny as the technical lead, we
built a SMS solution for Bono to enlist his fans into the ONE Campaign during the Vertigo
tour. We built a really cool SOA infrastructure to support the SMS
solution. It’s made up of a series of loosely coupled services all
centered around consuming SMS messages and displaying the fan names on
the screen during the concert.

Below is a pix of the Sun team on stage with Bono and Brad Pitt during
a recent press conference.

Interestingly, one of the most debated SOA architectural aspects 
(at least in architecture
and development teams) is the granularity
of a SOA Service. In the past year, I’ve tried a few different
strategies with customers and fellow architects to describe the
appropriate SOA service granularity. I started out saying “a SOA
service must be coarse grained”. “How large grained?”, many would ask.
“Very coarse grained”, I would answer. Then I would say; “definitely
not fine grained”.

As you can see, this is a pretty poor definition. So, I thought about
it and discussed it with Danny
Malks and tried to make it more SOA-like. So, I started talking
more about SOA services as  business services and
thus having business service
granularity. Sounds a bit subtle, but has a strong intent. As I
mentioned in a prior blog, we want SOA to take a top-down (problem to
architecture to solution) approach. This means that the business unit
(user) drives the requirements and essentially (but, not directly) the
service granularity. So, one way to think about a  SOA business
service is to be able to put it in business speak. For example, we may
talk about the  Insurance Quote
Service and Inventory
Service. We can talk to business people about services using
this granularity and not get into tech speak. Notice that we refer to
the services as nouns, not verbs. I’ve seen many services defined by a
verb, such as Add Employee Service. Focusing
on the actions (verbs) rather than the service (nouns) creates fine
grained services and should be avoided.

A few days ago, Dave Brillhart commented
on my earlier blog on the SOA Shift for aligning IT and the business
unit. This is a response/explanation to my thinking…

So what’s the big deal with making the business unit so prominent when
talking about SOA. It’s not about being one big happy family. 
It’s about the organizational structure which needs to support what we
really want to do; have
business drive the requirements for SOA. That’s what we mean when we
say SOA is a business-driven architecture, not a IT driven
architecture. 
If the business unit and the IT team don’t work together to achieve a
SOA, you will be very hard pressed to get the requirements necessary to
drive the proper service granularity and process definitions.

What does this really mean? It means that for SOA to be successful, it
must be a “top-down” approach. And top-down, means problem to
architecture to solution. It does not mean, working from what we have
and just wrapping it with new technologies just because we can. This
bottom-up approach is quite natural and easy and is the perfect recipe
for a SOA failure.

This isn’t just me thinking aloud. This is based on many discussions
with customers citing why their initial attempts to use webservices and
create SOA
solutions failed. Many of our customers cite the “just wrap it
in a web service” approach as a simple and natural way to create a the
SOA service layer.  So simple (from a tools perspective), and
natural (wrap what’s there),  they thought it was worth a try. The
problem, is taking an existing asset/system and making it a web service
is a completely bottom-up approach and creates an immediate mismatch
between the new web service interaction style and the existing
system.  More about this in future blogs.,,

Below is a page from one of my presentations to help visualize these
thoughts.

Gesture Muting

One of my favorite comics is the one where two dogs are sitting at the
computer and the tag line reads “On the Internet, no one knows you’re a
dog.”  But, I think we need a comic relevant to
“generation flex” who like the flexibility of working from anywhere and
doing conference calls at home, in the
car, on the treadmill, while feeding the kids, going to the bathroom
and even while changing poopie diapers. Not that I do any of these
;>, but I know others do. How? I can hear them. How can I hear them?
Because, today’s cell phone mute button technology sucks! That’s right,
let’s start innovating in the least addressed feature of the cell
phone; the mute button.

I have a nokia 82xx phone and it requires me to press a button, toggle
down to “mute” and then select it. That’s three steps! Plus, pressing a
button is not conducive to how we mute. We mute out of necessity
and we mute quickly and often. Pressing a button, let alone one which
requires three steps is all wrong. So, here is what I propose:
Gesture-based cellphone muting. Here’s a few ideas:

1. The High-speed Wave gesture:

Basically, I wave the phone to the right and then to the left and it
goes to mute.  I reverse the process to turn off mute. Note: this
is best suited for headsets and not hand-holders.

2. The Pressure gesture:

This method works for both headsets and hand-holders. Very simply, you
squeeze the phone to place it in mute. You press again to turn off
mute. This works best for the headset-ers who hold the phone. Of
course, there is a pleasant audible to tell you if you’re in mute mode.

3. The Scream gesture:

This is my favorite and very consistent with what happens right before
you need to mute.  Your daughter walks in the room and says;
“Daddy, mommy says you need to stop working or she’s leaving you…”.
Since, this is not something new and you know its dinner time, your 6th
sense detects  your daughter coming and right before she says a
word, you yell out; “MUTE!”. Instantly, your phone goes into mute mode.
Maybe you can program in something better than “MUTE”, such as “LOVE”,
“YOU LOOK GREAT”, “I DON’T DESERVE YOU” or  “HAVE YOU LOST
WEIGHT”. Your choice, but any of these will have the same muting
effect, but can also help relationships at the same time. I’d call this
a double win!

Hopefully, someone from Motorola, Nokia or Ericsson will read this blog
and grant my wish. If you have other ideas, please comment!

SOA means a lot of things to a lot of people. And, now that the money
is flowing to SOA, even more of us are interested. The reality is that
SOA is much more than just a buzzword. It is an architectural style
which tends to be best realized using Web Service and open standards.
It’s not the only way to implement SOA, but sure does seem to be the
most popular lately.

We’re finding that there are some key “shifts” that have to take place
in an organization to be successful with SOA. Today, I’ll talk about
the first of these “SOA Shifts”.

• Shift #1 – SOA requires a combined effort between IT and the
  Business Unit

The point of this shift is that we cannot do SOA without a mutual
effort between IT and the BU. Gone are the days of throwing the
requirements over the fence and hoping it hits. Not only do these two
groups have to work together, they have distinct roles and
responsibilities. Basically, the BU runs the show and owns the business
drivers, use-cases and processes. IT implements the BU requirements and
owns the service definitions.  It’s unfortunate that we really do
have to refer to this as a “shift”, because we should be doing this
anyway. But, the reality is that IT and BU typical function as
disparate groups and rarely work together to have the business
use-cases drive the process and service definition. More about this
later, but if you get the gist of this shift, I think we can begin the
journey to SOA….

Hi all, my name is John Crupi and I am the CTO of the Enterprise Web Service Practice at Sun Microsystems. And, this is my very first blog.

This is very timely because today, Sun just announced a great joint partnership between Sun, data.org and Bono from U2.

Press Release

This is turning out to be one of the most gratifying things I’ve done at Sun.

So, here are my interests which I’ll be blogging about in the future:

1. Patterns – Bringing patterns to the next level…

Core J2EE Patterns

2. SOA – Service Oriented Architecture isn’t just a buzz word, it really has potential to change the way we do integration (in an open standard way)…

3. Cool tech stuff – Things which make my life easier…

4. University of Maryland Terps – Big sports fan…

UM Terps

5. Electronic drumming – What I really wish I got paid to do…

Roland V-Drums