JP Morgenthal wrote: > 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.
Spec'd APIs such as Jini can, though, provide enough containment in features to focus the efforts of the developers into tractable designs. The complete set of features that Jini provides cover the complete set of things that distributed, scalable applications need. Certain applications need to make use of such features (Jini provided or otherwise) in specific ways to truely enable complete scaleability. There is no silver bullet distributed system implementation yet, which provides true autoscaling and QOS. But, the RIO project, with its QOS features including auto redeployment(http://rio.jini.org) provides a fair amount of satisfaction to its users it appears. > 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. The primary feature required of a distributed system which allows dynamic assignment of resources, is some means for recovery and tracking of those resources. Jini's distributed leasing service and APIs along with the closely associated distributed transaction service make it possible to easily manage the resources of a distributed system. Lost users of a resource will fail to renew leases and thus allow the recovery of those resources. The 2P transaction manager allows mutual agreement between services to proceed to a concluded state for roaming resoures. > 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? The J2EE design has many issues. I appreciate your thought provoking comments here. > 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. POJO is empowering. The J2SE platform is very empowering when you can exploit all of its features. Those that choose to ignore Jini are only destined to recreate its features at some point. So I am still wondering why people don't choose to start out ahead and use the power of the Jini platform for their SOAs that use Java (or which could use Java and be even better). Gregg Wonderly Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
