Lets all give a big howdy to Paul Monday, author of Web Services Patterns: Java Edition. Paul will be with us all week to talk about his book and discuss web services. On Friday we will be awarding a copy of Paul's book to four lucky winners. Visit the Book Promotion Page for information on how to win a book!
Welcome Paul, and congrats for your book which is really interesting and different from others related to web services
/ JeanLouis<br /><i>"software development has been, is, and will remain fundamentally hard" (Grady Booch)</i><br /> <br />Take a look at <a href="http://www.epfwiki.net/wikis/openup/" target="_blank" rel="nofollow">Agile OpenUP</a> in the Eclipse community
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 ;-)
Paul B. Monday<br />Author, Web Service Patterns: Java Edition
Welcome Mr. Paul Monday! Yup, Web Services is really hot right now in the industry... Could you provide an example (sample service / product for a fictitious company) of when to use web services?
Joined: Aug 28, 2003
Originally posted by Unnsse Khan: Could you provide an example (sample service / product for a fictitious company) of when to use web services?
In the book, I do provide an example of a "fictitious" company (one based on my grandfather's tiny coffee company). This example would be an example of a company that has the "luck" of being able to build a new application "from scratch". What's interesting and what many people don't think about is that the use of Web Services is not for your "primary" architecture job, its for your integration requirements. So, for example, if I want to build a large distributed supply chain that integrates my bean suppliers with my own bean requirements, I would want to use Web Services as a technology since I cannot predict the architectures and platforms of the clients that will participate in the distributed supply chain. My choice of Web Services does not relieve me of having to choose a component architecture (J2EE) and web technologies (also a part of J2EE). There are, of course, many efforts to move Web Services to a full application platform (BPEL, Orchestration, and some others come to mind) but, for now, be aware that you have multiple technologies floating around. In my own experience you RARELY have the opportunity to architect and design from scratch. So in this sense you are in a perpetual job of updating systems. Here, I think Web Services serve as a way to "open up" a stovepipe system. By introducing a "mediating" architecture and design in Web Services that is accessible by ALL types of systems, you can go a long way to figuring out how to integrate your systems. In this sense, the power of Web Services are really in the "simple" technologies used at the core (XML, HTTP, etc...). Then, you could open the discussion to talk about the general uses for Service-oriented Architectures (of which, obviously, Web Services are a big one). We use a "home grown" SOA as a way to add structure to the Java language for the storage product I work on, without incurring the "weight" of a full EJB solution...though, EJB is coming closer and closer to our needs these days. Does that answer your question? I tend to shy away from the "uber" dynamic trading partner examples. I think trading partners are a lot more organic than the "let Web Services find a supplier on the fly" mechanism. I would think that where the directory structures will come in handy is with separate management applications that aid in location of trading partners when your currently configured partners fail to supply.
If you want to go the "available" on the net route, Sun is an excellent place to start. There is a ton of information running around the Sun sites. The tutorial you point out has the "technology first" flavor I mentioned in another post. Think about starting here: http://java.sun.com/blueprints/webservices/using/webservbp.html as a beginner, this gives you a quick high level view of what Web Services really are at the heart before you dive into the XML ;-) Then, of course, I would run out and buy my book when you make a ton of money with your new found Web Service knowlege. Paul
Originally posted by Unnsse Khan: Could you provide an example of when to use web services?
Pardon me for jumping in here but there are real companies already doing real business with Web services. Right off hand, Dell computers and Amazon.com are two with pretty good visibility that make heavy use of Web Services. And did you know that Google has a toolkit and API for Web services? Regards,
Howard Kushner<br />IBM Certified Enterprise Developer - WebSphere Studio Application Developer V5.0<br />IBM Certified Advanced System Administrator - WebSphere Application Server V5.0<br />IBM Certified Solution Developer - Web Services with WebSphere Studio V5.1<br /><a href="http://www.amazon.com/exec/obidos/tg/detail/-/1931182108/" target="_blank" rel="nofollow">Developing J2EE Applications with WebSphere Studio</a> my Certification Study Guide for IBM Test 287
Joined: Aug 28, 2003
Howard, good points...why go with examples/samples when you can do the real thing? I did play with the Google Web Services last year, very cool stuff and free for the download :-) I can't remember off the top of my head where it is, but aren't there a few good web sites that document available Web Services and tips for use?