Michael, Not sure if you have seen the Enterprise Integration Patterns web site (book just got released -- authored by (RTP and TriJUGs own) Bobby Woolf and Gregor Hohpe)
I created an example and wrote a chapter on using synchronous predictive web services to integrate applications that exposed web services. The specific example here ... http://www.eaipatterns.com/ComposedMessagingWS.html The entire web site is pretty cool for integration patterns. http://www.eaipatterns.com/index.html I understand from Addison-Wesley's web site the book was published last week. If Bobby W. is reading can you confirm? I will ponder some of the points you have raised in the message and share some thoughts. One of the projects I am working on is 100% Apache- Axis base ... and we are also test driving a .NET client calling a service implemented in Apache-Axis (J2EE). So depending on our tests I will be able to share some insights ... especially with regards to interop between .NET and Axis. Conrad "Michael D. Thomas" wrote: > 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 _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
