Adam,
If this is a route worth taking, I think it indicates a need for a Cloud
Profile separate and apart from Java EE and certainly the Web Profile.
It's an awful lot of stuff to mark "optional". I guess to reiterate my
underlying concern, I am just not that sure of the prevalence of
"cloudy" vs. "sunny" applications after the marketing dust settles, so
I'd hate to put in a lot of stuff into the platform that is only used
for edge cases (just like EJB remoting back in the bad old days).
Cheers,
Reza
On 6/17/2011 4:40 AM, Adam Bien wrote:
> JSR-88 was pruned, because it was not that interesting for a single server deployment. It becomes more interesting for Continuous Installation / Deployment and Clouds. Instead of re-inventing something new, I would rather reactivate or at least copy-paste parts of an older spec.
>
> IMHO even a primitive deployment / management / monitoring API should be a part of an every cloud and so Java EE 7....
> On 17.06.2011, at 04:50, Jason T. Greene wrote:
>
>> No I mean that we the EG (including you) marked JSR-88 as pruned in EE6 (will no longer be required for vendors in EE7 provided we don't change our minds). I thought we did the same for 77, but apparently we did not.
>>
>> On 6/16/11 9:32 PM, Reza Rahman wrote:
>>> Jason,
>>>
>>> Yep -- we did the same :-).
>>>
>>> Cheers,
>>> Reza
>>>
>>>
>>> On 6/16/2011 9:57 PM, Jason T. Greene wrote:
>>>> We pruned those two, since they are significantly out of date (did not
>>>> handle annotations), and had little interest (ask an EE developer
>>>> about these and you get silence followed by blinks). IMO If we did
>>>> want to introduce a management / deployment spec, it should be a fresh
>>>> take from scratch.
>>>>
>>>> On 6/16/11 7:44 PM, Reza Rahman wrote:
>>>>> Bill,
>>>>>
>>>>> For what it is worth, I agree with you that some of this looks like it
>>>>> is putting the horse before the cart :-). I'd like to see the existing
>>>>> developer APIs improve first and perhaps a basic outline of resource
>>>>> layer multi-tenancy before adding too many new APIs geared towards PaaS
>>>>> vendors. I think in the interim, JSR-88 and JSR-77 are the way go to
>>>>> even if they are less than ideal, maybe augmented by vendor-specific
>>>>> server APIs.
>>>>>
>>>>> Cheers,
>>>>> Reza
>>>>>
>>>>>
>>>>> On 6/16/2011 5:54 PM, Bill Shannon wrote:
>>>>>> Jevgeni Kabanov wrote on 06/15/2011 11:21 AM:
>>>>>>> I'm still catching up with the reading and some research, but here
>>>>>>> are in no
>>>>>>> particular order some things I'd ideally want to see from this:
>>>>>>> 1. App servers should abandon the notion that they are only managed
>>>>>>> by their own
>>>>>>> consoles. Their should be a generic way to start/stop/deploy/etc. I
>>>>>>> haven't
>>>>>>> looked into JSR-77 yet, maybe that's the one. But I'd propose to
>>>>>>> standardize on
>>>>>>> the command line instead of the Java API, which is hugely cumbersome
>>>>>>> in a
>>>>>>> heterogenous environment the apps commonly live in.
>>>>>> We tried to standardize some of this in JSR-77 and JSR-88. They have
>>>>>> not been
>>>>>> a success. While we'd like to do more here, it's a tremendous amount of
>>>>>> effort, and not something we're planning to do for EE 7.
>>>>>>
>>>>>>> 2. Also, please let me pass parameters to the JVM, e.g. managing
>>>>>>> Glassfish
>>>>>>> through scripts is impossible. Being able to tune the app server and
>>>>>>> its JVM
>>>>>>> centrally is a must for the cloud.
>>>>>> To make standardizing this really useful, we'd want standardized JVM
>>>>>> parameters. There are none. A standardized way to pass non-standard
>>>>>> parameters isn't as interesting, and encourages non-portable
>>>>>> applications.
>>>>>>
>>>>>> Passing JVM parameters with an application when you deploy the
>>>>>> application
>>>>>> to the cloud assumes a certain deployment model (one application per
>>>>>> JVM)
>>>>>> that we're unlikely to require.
>>>>>>
>>>>>> If people think there's value in standardizing a way to pass
>>>>>> non-standard
>>>>>> JVM parameters, with no requirement that the application server do
>>>>>> anything
>>>>>> with them, I suppose we could consider that.
>>>>>>
>>>>>> Oh, and you *can* set JVM parameters for GlassFish using a script so
>>>>>> I'm
>>>>>> not sure what your issue is there.
>>>>>>
>>>>>>> 3. REST API layered over JMX API for deployment, configuration
>>>>>>> management and
>>>>>>> app management. Can't stress that enough.
>>>>>> JSR-77 is an EJB API for management. It gave us a standardized protocol
>>>>>> for management that wasn't Java specific. Still, JMX proved more
>>>>>> popular.
>>>>>> There is still no cross-platform standardized protocol for management
>>>>>> using JMX. We've been asking for years for a Web Services / SOAP
>>>>>> mapping
>>>>>> for JMX. Today, using a REST-based protocol might be a better choice.
>>>>>>
>>>>>> Again, this is a ton of work that we won't be able to do for EE 7.
>>>>>>
>>>>>>> 4. A jvm-instance-per-app model (better called process per app model)
>>>>>>> for app
>>>>>>> servers as an alternative to the current classloader per app model
>>>>>>> and way to
>>>>>>> manage those apps. At least as an option to be standardized on down
>>>>>>> the line.
>>>>>> I don't think we'll standardize this, but this is definitely one
>>>>>> implementation
>>>>>> strategy that we intend to allow.
>>>>>>
>>>>>>> 5. Session API/SPI (probably through the same JMX/REST combination)
>>>>>>> that allows
>>>>>>> to migrate data without relying on the app server and also keep
>>>>>>> session in the
>>>>>>> super-effective datagrids/caches.
>>>>>> I'm not sure I understand your use case here.
>>>>>>
>>>>>> Our focus has been on APIs that applications need. Applications
>>>>>> shouldn't
>>>>>> be migrating data.
>>>>>>
>>>>>> In some cases we've provided SPIs that allow servers to be extended, or
>>>>>> allow multiple implementations of a facility to be provided
>>>>>> independently
>>>>>> of a server vendor. An SPI to allow pluggability of session state
>>>>>> storage and migration mechanisms might be interesting.
>>>>>>
>>>>>>> 6. Oh, and an API for provisioning app servers, though that's
>>>>>>> probably too much
>>>>>>> to expect :)
>>>>>>>
>>>>>>> Generally I think the main thing PaaS support requires is to expose a
>>>>>>> bunch of
>>>>>>> scripting APIs and make the app server consoles to be consumers of
>>>>>>> the APIs the
>>>>>>> underlying server exposes. This will create a great ecosystem to
>>>>>>> complement the
>>>>>>> existing tooling instead of requiring app servers to catch up one by
>>>>>>> one.
>>>>>> That's not our current plan.
>>>>>>
>>>>>> We're trying to enable application server vendors to provide a full
>>>>>> cloud
>>>>>> platform.
>>>>>>
>>>>>> We're not trying to turn application servers into a component that
>>>>>> someone
>>>>>> else would use to construct a full cloud platform.
>>>>>>
>>>>>>
>>>>>> -----
>>>>>> No virus found in this message.
>>>>>> Checked by AVG - www.avg.com
>>>>>> Version: 10.0.1382 / Virus Database: 1513/3707 - Release Date: 06/16/11
>>>>>>
>>>>>>
>>>>
>>
>> --
>> Jason T. Greene
>> JBoss, a division of Red Hat
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1382 / Virus Database: 1513/3708 - Release Date: 06/16/11
>
>
>