Hi There! Sorry I'm late to the party...life gets a little nutty in the job once in a while. Nonetheless, I'm here and have been busy posting to threads for quite a while this evening .... so I guess let's get started!
(whenever I see this dude I feel like someone should be yelling "LET'S RAISE THE ROOF")
Let me give a very brief background of my life, then some thoughts on the "why" I did the Web Service Patterns: Java Edition book and the "how" it ended up like it did.
WHO AM I?
Throughout my career I've bounced around database projects (DB/400), object-oriented projects (SanFrancisco, System Object Model), component architectures (EJBs, JavaBeans, SanFrancisco Beans), service architectures (Jini, Jiro, Web Services), and end user products and interactions. Today, I work with software architecture for Sun's Enterprise Storage Manager (a blend of a component/service/object architecture) that just shipped its 2.0 release.
WHY and HOW?
I feel like Web Services are so interesting because they span all "expertise" levels. A beginning programmer can "grasp" the concept and even the technologies at play. In fact, you can build "Hello World" with Web Services in a few minutes and actually read and understand
SOAP. This simplicity can be a trap though...writing Hello World with Web Services does not really teach you WHY or WHEN to use Web Services, or even their potential.
I felt a book that grew out of my roots spanning all of my "platform" experiences would be useful to a group of people out there. For example, at one point in my career I was taking the very rich object-oriented patterns and structures in the SanFrancisco Framework and turning them into
EJB components. What a humbling experience and brain teaser it is to teach someone who has lived in objects all of their lives the differences between their beloved object hierarchies and the relatively flat world of of components. Dare I say its like taking someone from Colorado and turning them loose on a ski hill in Minnesota (before I upset anyone...I learned to ski in Lacross, WI while in college at Winona State University in Minnesota ;-)
So, I set out with a few messages that I wanted to get across in the book:
- Web Services are in a service-oriented architecture and the implications of this are that
you SHOULD think differently. In fact, if you are going to use Web Services, I believe you should go into your application design up front being very careful about your component interfaces and allowing the Web Services to be an acknowledged force in your component or object designs.
- The goal of Web Services are business processes and conducting business in enterprise and distributed environments. This is an important jump for people to make because you usually "start" in Web Services at the Business Object level or doing "Hello World".
- Be careful that you don't believe that merely by using Web Services will you solve the problem of how you interact with your clients. Its the MODEL that matters and Web Services are merely a facilitating technology.
At some point the book started to write itself. I started out with a very lofty goal but found many of the patterns I was thinking about were not really patterns but simply "ideas" that were not proven. Further, very early on aPress and J. Zukowski held me up as I tried to tackle the traditional pattern format. They, instead, wanted a much "warmer" book... At that point, I fell into a very interesting "building" flow where I dissected the Web Service platform in three easy patterns, and then started to build structures on top of it.
The rest, at this point, is history.
AT ANY RATE
Thanks to the ranch for having me on board for the week and I HAVE to apologize again for my late entry into the forums. I hope I can pick up the slack over the next couple of days!
A few notes on me...I LOVE constructive criticisms. There are so many things to learn out there and a good debate helps clear the air. So many of my beliefs and thoughts are based on my experiences with different programming paradigms and the SOCIAL aspects of technologies that I sometimes have perspectives that fly in the face of the technically elegant and complex solution.
Take care and let's be safe out there in the forums ;-)