POJO is what it is, that is, it's self-describing. They are plain old java objects--just vanilla java objects. They represent generic OO programming constructs.
As for simplification through moving the complexity into the infrastructure, I say, "nice idea, we have a long way to go baby!" The problem with moving the complexity into the infrastructure is that we have no trained resources capable of managing this complex infrastructure and understanding what the heck the developers are deploying into it. There's very little in the way of manageable and portable domains, such that demand for one application can pull from a resource pool and then return the allocation to the pool when complete. If you're gonna tell me that J2EE does this, you're off your rocker. J2EE does 1/10th of what's really needed here to allow developers to develop simple application objects and deploy them into a generic field that is completely managed. In fact, so many J2EE people I speak with agree that the promise of this has been unfulfilled by J2EE and that many early applications that bought into this are now undergoing re-writes to support the need for better scaling. That is, the application had to be rewritten to scale, isn't this what the infrastructure was supposed to do automatically? Until we have an infrastructure that truly manages the complexity required by large-scale application and the trained resources to manage such an environment, the complexity must be shared across the application and the infrastructure. This balance is what will make SOA difficult to really deliver over the next 10 years because the services will have to eventually absorb what the infrastructure cannot. JP -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Feygin Sent: Thursday, June 16, 2005 11:36 AM To: [email protected] Subject: RE: [service-orientated-architecture] Business case for SOA 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
