From the perspective of our customers Cloud is more about automated deployment, provisioning and configuration management than anything else. If we could at least get the resource definitions into Java EE 7, that'd be hugely helpful. I'm much less concerned about multi-tenancy, as I think that it's not as easy to standardize and will probably end up too limited anyway. And of course, since we're talking about automation, I'd still love to see some Configuration API, that I mentioned a couple of time before, so that apps and containers could both be configured and deployed automatically.
I understand that Bill's worry that I'm proposing to lift the job of container to the app, but the reality is that deployments always operate in the context of legacy services, apps and data. Therefore, having flexible and easily scriptable deployment and configuration is key for customer satisfaction. Even a recommendation as per scripting and API type and location (Java, JMX, REST) would be hugely helpful if majority of container vendors would follow them.
As for modularity -- just as a thought experiment, isn't it possible to split the spec into conceptual modules independent of any specific module system to make our job easier down the line? I understand that the basic principles of the Java SE 8 module system is quite well laid out? Alternatively, it'd be possible to ship two versions of the spec (again, just thinking out loud), one based on Java SE 7 and the other based on Java SE 7 + modules. This would allow to both have a smooth transition path and to accommodate early adopters to test out the spec. This means more work for us, but not necessarily much more than doing the modules anyway.
--
Jevgeni Kabanov
Founder & CTO of ZeroTurnaround
@ekabanov | Skype: ekabanov | http://www.linkedin.com/in/ekabanov
+372 53 411 869
On Thursday, 29 September 2011 at 09:38, Bill Shannon wrote:
> Jason T. Greene wrote on 09/28/2011 08:32 PM:
> > On Sep 27, 2011, at 4:57 PM, Bill Shannon <bill.shannon_at_oracle.com (mailto:bill.shannon_at_oracle.com)> wrote:
> >
> > > Jason T. Greene wrote on 9/27/11 1:51 PM:
> > > > On 9/27/11 2:56 PM, Bill Shannon wrote:
> > > >
> > > > -snip-
> > > >
> > > > > We have considered several
> > > > > alternatives moving forward, including delivering Java EE 7 with the
> > > > > remaining content as planned, or splitting the Java EE 7 release into
> > > > > smaller Java EE 7 and Java EE 8 releases, with only a small time gap
> > > > > between those two releases, and with Java EE 8 containing only
> > > > > modularity support and any remaining original content from Java EE 7.
> > > > >
> > > > > I know this will be a disappointment to all of us, but I'm sure you'll
> > > > > understand the constraints and agree that alignment with the upcoming
> > > > > Java SE module system is essential.
> > > >
> > > > Hi Bill,
> > > >
> > > > I definitely think this was the right decision to make, and relay Red Hat's
> > > > support. Due to the massive impact modularity will have I think it's more
> > > > important that EE and SE be cleanly aligned, then for us to be early.
> > >
> > > Thanks for the support.
> > >
> > > > The idea you mention above of fast tracking EE7 is interesting. Does this imply
> > > > revisiting the main goals? We would love to see some more work on unifying the
> > > > specs (e.g. common services like tx, sec, and so on), and that seems more
> > > > achievable in a short time frame.
> > >
> > > At this point we're just collecting input.
> > >
> > > It sounds like you're suggesting that we scale back some (unnamed) goals
> > > and doing more work to unify specs. We're still considering the resource
> > > impact of the various possibilities but at this point we think we'd likely
> > > have to remove more than just modularity to make a significant difference
> > > in the EE 7 schedule.
> >
> > That's correct. I was assuming that a shortened schedule would mean shifting or
> > splitting other major items. For example, perhaps some of the PAAS work could be
> > split between 7 and 8?
>
> The only obvious choice there is to defer the limited SaaS support we're
> planning to EE 8. I'd be a little worried about doing that, however,
> since we've already seen that there's an interaction between the metadata
> we need for PaaS and the metadata we need for SaaS. The nice simple
> solution we envisioned for PaaS can become quite complicated when we
> factor in the SaaS requirements. I'm concerned that if we don't
> consider them from the beginning we'll end up with a mess if we have
> to retrofit them later.
>
> > > Still, I'm interested in what additional spec unification you'd like to see.
> >
> > Well I think we could continue to build on the "unified component model" notions
> > we introduced in 6. More specifically taking things like EJB transactional
> > annotations and making them common EE services that can be consumed by managed
> > beans, and by extension any EE framework.
>
> Doing that for transactions is already on our list.
>
> Anything else?