Hi, I'm working on a J2EE Web Services book. While I'm still at the beginning of the project, I'd like to solicit some comments and hopefully start some discussions about web services. This list has been a great source of informative dialog in the past and I hope that I'll be able to invigorate some responses. I'm also happy to offer some of my own opinions and expertise as part of the discussion. While I hope to meet some of my own objectives with this thread, I truly believe that this discussion is of value to the overall community and hope others will participate.
My conversation starter has turned out to be lengthy, but I hope that some people will feel compelled to respond to parts even if you don't have the time to read the whole post completely ;-) First, let me tell you about the book. It's intended to be a hype-free guide to building large J2EE systems that have a significant web services component. Instead of emphasizing the "front side" of web services -- HTTP, XML, SOAP, WSDL and UDDI -- this book focuses on how you integrate existing J2EE technologies with the emerging web services-centric standards (JAXP, SAAJ, JAX-RPC, JAXR, JAXB, JAXM). Since web services is moving beyond the prototype stage, the book also focuses on software development lifecycle issues. How do you plan for reusability, how do you employ the pragmatic programmer's Don't Repeat Yourself (DRY) principle (BTW, can we call that code normalization?), how do you write business logic that serves both a traditional GUI and a web service, etc., etc. Since I'm a software developer myself, I'm planning to use lots of code examples and I'm hoping that my examples are as "real world" as possible. Okay, so that's what I'm trying to do. Now, I'm hoping that you'll provide me some feedback to help me accomplish my goals. In the spirit of Andy Oliver, I'll try to be as provocative as possible.... If I don't incite some disagreement and flames, I've failed. * What are you tired of hearing about web services? At this point, web services is pretty far along the hype curve. What hype-messages out there do you find misleading or tiring? What messages hit the mark? * What do you need to know about web services right now? Even better, what will you need to know next spring when the book comes out ;-) * What's the silliest use of web services you've seen thus far? (I have a whole chapter devoted to "when not to use web services." I'd love to have some more examples. As with all contributions to this thread, I'll acknowledge the source as appropriate.) * What are your favorite web services resources, books, articles, journals, web sites, etc. * Service Oriented Architecture (SOA): What do you think about it? - SOA is yet another attempt to codify the basic principles of distributed computing. As with all previous attempts, SOA will be muddied by vendors, ignored by practitioners, and do nothing to improve the design and quality of large distributed systems. - SOA is cat-skinning method #652. - SOA is yet another over-hyped paradigm that is being exploited to sell tools, services and training. - Why do people keep coming along trying to tell me how to do my job? - SOA will be the primary distributed computing paradigm by 2006. - I've been developing SOA systems since 1943. Stop bothering me. - What's SOA? * Technology integration vs. business integration. I see web services being used at a technology level -- "I have these two software packages that need to work together, so I use web services to bridge the gap" -- as well as at a business level -- "BusinessA is setting up a web services based electronic interchange with BusinessB." At a plumbing level, the challenges are mostly the same, but at a design level they are different. For instance, business level integration really needs highly visual and declarative artifacts like the ERD for databases to enable good planning, negotiating and decision making. In fact, I think that a lot can be learned by looking at how databases are designed and how the database schema plays a crucial role for both technology and business design. Your thoughts? * At my most cynical, I proffer that web services is popular because most all firewalls have the HTTP and HTTPS ports open. Thus, project teams can deploy application code "under the radar" of the enterprise security folks and without having to suffer through a full security audit. Of course, this means that web services open up the enterprise's mission critical systems to profound attack. As with all security matters, you really need to design up front rather than bolt security on after the application is developed. This is especially important when you are orchestrating business processes across many disparate web services implementations located across many enterprises. Security and authentication issues are fundamental to the success of web services. Do you think the current standards and paradigms are up to the challenge? * Web services implementations are usually just one face to an application. Often, it also has a traditional UI. But both are really presentation-level technologies. In my book, I suggest a couple of ways to design systems that isolate web services to a presentation layer while maximizing reuse between a traditional UI and a web services interface. I also cover ways to refactor a pre-web services app so that it can cleanly support both a web services and traditional UI front end. Thoughts? * Portability and interoperability. Web services is all about interoperability. But /porting/ a web services implementation from one J2EE server to another can be troublesome. The question of J2EE portability can be really tough because, officially, there aren't any portability problems between J2EE servers. There are portability issues -- what are your experiences? * It's one thing to say what a technology is, the problems it solves, etc. But let's face it -- all technologists are gamblers. We are gambling that the skills/technologies/methodologies/approaches that we are developing expertise in now are going to matter in five years. We go to monster.com, we type in our keywords, and we hope that we hit a jackpot. When something like web services comes along, I think that it is most important to understand the underlying forces that are driving it. Technology paradigms often follow the "winner take all" rules of scale-free networks or the "law of increasing returns." By understanding the underlying forces, you may be able to avoid buying an Edsel, a Beta VCR or a NeXT computer. (I once had a professor that bought all three. I now consult him on all technology decisions and do the opposite.) Thus, the best discussion we could have is "will (or, what part of) web services will matter 5 years from now and why?" To start that discussion, I'll offer that web services is a simple messaging paradigm uses HTTP for transport and XML for semantics. (Note: SOAP allows you to choose the underlying transport and other protocols, such as SMTP, can be used.) Both technology providers and practitioners have coalesced around this model. It's the Reese's cup of our time -- "you got XML in my HTTP! You got HTTP in my XML!" As with the web itself, the simplicity of the model is its greatest advantage. It has tons of room to evolve and is evolving in an open manner. If nothing else, the lessons we're learning about web services now /will/ matter in 2008. That said, there are a couple of huge hurdles for web services that I see. - There isn't a standard for optimizing XML. Though it isn't really true, many will tell you that XML is text. In practice, web services XML has to travel the wire in a way that is understandable by both parties, which usually means text or encrypted text. This is great when you are Amazon or Google and your primary focus is satisfying interoperability use cases. However, web services isn't going to beat an equivalent RMI, IIOP and/or EJB-based implementation in a foot race. Not even close. There is some work being done in standardizing an optimal wire line format for XML, but it is a controversial endeavor. Without such a standard, attempts to optimize the XML format will result in a higher coupling of web services producers and consumers. Such a development would be ironic because web services modus operandi is to provide a framework for loosely coupled, highly interoperable interactions. - Security/authentication. Security and authentication issues make web services more complex. For simple point-to-point web services, you can overcome a lot of these issues with SSL. But as you get into BPEL4WS territory and you are orchestrating web services across many enterprises, security and authentication get hard. I like to use UPS as an analogy. The UPS truck drives on your property. The driver takes your package, confirms your identity, gives it to you, and you sign for it. You take delivery on another package, even though it is really meant for someone else in your organization and you don't have any business opening it. You don't have access to any of the other packages on the truck, even though some of the packages may be interesting to you because they are bound to customers, suppliers or partners. Just for fun, implement that process using web services. - Distributed computing is hard, but web services /seems/ easy. Web services, like HTTP/HTML, is really easy for the simple problems. For the medium-sized problems, it is still serviceable. But at some point, the intrinsic complexities of the problems reveal themselves and you need a higher order paradigm to guide you. With HTTP/HTML, that moment often comes when a development team goes, "we're not just hacking servlets and JSP pages anymore. We're building a content management system/inventorying system/e-commerce portal. We should step back and think a minute..." I've seen a lot of examples that show you how easy it is to web services enable your code. One of these shows you how to expose the add/subtract/multiply/divide functionality of your calculator object. Though a great way to demo basic web services plumbing, it really represents a distributed computing anti-pattern. It contradicts Jim Waldo's (et al) statement from their 1994 paper, "A Note on Distributed Computing": "work in distributed object-oriented systems that is based on a model that ignores or denies [the differences between local and remote objects] is doomed to failure, and could easily lead to an industry-wide rejection of the notion of distributed object-based systems." Without fully expounding the fine-grained vs. coarse-grained argument, let me just say that the lessons of SOA are way more important than the lessons of web services. However, poor use of web services is very likely to tarnish the acceptance of web services, SOA and general distributed computing. Thanks for reading, and I hope that you'll contribute some of your own thoughts. --------------------------------------------------- Michael D. Thomas -- Software Developer, Author "Oracle XSQL" in bookstores now "Practical J2EE Web Services" available Spring 2004 _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
