Gregg, My comments below:
--- In [email protected], Gregg Wonderly <[EMAIL PROTECTED]> wrote: > 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). I think this is possibly due to a herd mentality. Sun seem to think that the value of J/JS technology is in its discreet use in the systems they sell, just as IBM use TSpaces in their GRID infrastructure without giving this fact unnecessary publicity. As Sun control the Java specs, it is only natural that the average Java developer should follow their recommendations. I have been told that the latter come out of the J2xE teams in California who have successfully shut out the Jini proponents from Massachusetts. Being an outsider I can only pass this on as mere speculation. Gervas > > 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/
