Jan, If J2EE is not the right tool for the job, then POJO or whatever has always been the available alternative. The revival I tend to associate with POJO now (don't know if that is what JP referred to) is the simplification of enterprise bean types to more closely resemble JavaBeans.
As for the acronym soup, I guess it is its high visibility, which contributes to Web services being perceived as overly complex. Indeed, application developers, in my view, have to know way too much to create manageable, intelligent endpoints with the current level of infrastructure available, although things are getting better and in due time the acronyms will be the domain of infrastructure providers (like the relatively complex APIs of the earlier EJB and container specs). Complexity is certainly not a virtue, but sometimes it is a necessity. Even seemingly simpler things than integration can be exceedingly complex. I can't resist to point you to presentation [1], brought up by Radovan in his blog [2] at one point. Daniel [1] http://intertwingly.net/slides/2004/devcon/ [2] http://radovanjanecek.net/blog/archives/000182.html -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jan Algermissen Sent: Wednesday, June 15, 2005 11:55 PM To: [email protected] Subject: Re: [service-orientated-architecture] Business case for SOA On Jun 15, 2005, at 12:43 PM, Daniel Feygin wrote: > POJO is making a revival, because all the complexity is being > transferred from user code to deployment environment. Hmm...I thought POJO is increasingly attractive because it throws out complexity (J2EE) where it is not needed. Sort of like: using the right tools for the right job. > I am optimistic that the developments around WS-* (particularly WS- > Policy, WS-MetadataExchange, WS-Trust, WS-Security, WS-Addressing, > UDDI, WSDM) will eventually enable that sort of transformation to > occur in distributed computing. As infrastructure will be getting > smarter, distributed application development should be getting > simpler. To be frank: I am highly suspicious of everything that produces heaps acronyms in such a short time. Some portions of the WS-* complexity may well bring a benefit for certain cases, but I doubt that complex problems (e,g, enterprise integration, B2B) need complex solutions. Jan > Daniel > > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of > JP Morgenthal > Sent: Tuesday, May 24, 2005 6:46 PM > To: [email protected] > Subject: RE: [service-orientated-architecture] Business case for SOA > > Steve, > > > > I, like you, am not an SOA-biggot in that I'm fine if > engineers want to use Web Services as a design methodology for their > application, however, it is my belief that what that companies are > doing is not proving SOA, you're proving Web Services. SOA would > require that you design re-usable business services that have > well-defined management and security models and that defines the > policy for usage. That's not to say that this doesn't have value, but > realize that SOA is an infrastructure movement that defines the > framework that services are deployed and managed within. Otherwise, > it's a component-based systems- engineering model, or just plain-old > Distributed Computing (which, BTW, I'm leaning heavily toward based on > WS interfaces). After all POJO is really making a revival, can't > PODC? > > > > JP > > > > > > Check out my latest blog entry > > > > JP Morgenthal > Managing Director > > Ethink Systems, Inc. > 12110 Sunset Hills Road, Suite 450 > Reston, VA 20190 > > [EMAIL PROTECTED] > IM: chiefethink (AIM) > http://www.ethinksystems.com > > tel: > fax: > mobile: > > (703) 648-1520 > (703) 648-1520 > (703) 554-5301 > > > > Add me to your address book... > > Want a signature like this? > > > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of > Steve Schaffer > Sent: Tuesday, May 24, 2005 8:59 AM > To: [email protected] > Subject: [service-orientated-architecture] Business case for SOA > > > > I work with Insurance companies, and they are proving the value of > SOA on a daily basis. They use SOA to process application information > from a 3rd party web site. They are already re-using an SOA component > to integrate with other web-services. The cost savings are obvious, > the business need is clear. SOA is an architecture that standardizes > re-use across business units. > Yes, it is modular programming rehashed. However, the (public) > stage and cross-BU focus of SOA gives more focus, and more benefit to > this latest attempt to apply accepted Systems Engineering rules to an > area that is too often left to unstructured systems building. > > Steve Schaffer > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today - it's > FREE! > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > > > > > ________________________________________________________________________ ____________________ Jan Algermissen, Consultant & Programmer http://jalgermissen.com Tugboat Consulting, 'Applying Web technology to enterprise IT' http://www.tugboat.de Yahoo! Groups Links
smime.p7s
Description: S/MIME cryptographic signature
