On Tue, Jul 12, 2011 at 04:02, Marina Vatkina <marina.vatkina_at_oracle.com>wrote:
> Hi Antonio,
>
> Antonio Goncalves wrote:
>
>> Hi
>>
>>
>> On Wed, Jul 6, 2011 at 01:02, Marina Vatkina <marina.vatkina_at_oracle.com<mailto:
>> marina.vatkina_at_oracle.**com <marina.vatkina_at_oracle.com>>> wrote:
>>
>> Dear Experts,
>>
>> Before we go any further on the discussions of the spec
>> improvements, we need to close on several issues with the current
>> version:
>>
>> 1. Vote on the optionality of the Entity Beans and JAX-RPC based
>> Web Service Endpoints (and the split of the spec into 2 parts, but
>> the split is the secondary issue). I have only 3 votes (positive)
>> so far.
>>
>>
>> You have my +1
>>
>
> thanks.
>
>
>>
>> 2. Close on the items marked by Linda as XXX in the drafts.
>>
>>
>> I've been following the XXX marks threads and agreed on most of them
>>
>
> Which ones you do not agree on?
>
>
>
>> 3. Define *deterministic* rules in the EJB spec about EJB Lite vs.
>> EJB Full list of features in regards to the EJB support in a Web
>> Profile container. In addition to be very flexible (contrary to
>> the regular Java EE approach, and the expectations of the EJB
>> TCK), the current wording in the spec does not make it clear a)
>> what is expected and what is not in the Web Profile, and b) if we
>> keep it flexible, how a user (at deployment and/or runtime) can
>> determine if a specific feature outside EJB Lite is
>> available/supported.
>>
>>
>> This is a bit tricky. Let me go a bit further. Let's say (and I emphasis
>> my 'let's day') PAAS/SAAS features in Java EE 7 are put into a seperate
>> profile (not into EE 7 itself), this would mean that we would have 3
>> different flavours of EJBs : EJB Full, EJB Lite and EJB Cloud (BTW, EJB Full
>> doesn't seam a good name to me). What are the differences between a EJB Full
>> vs EJB Lite vs EJB Cloud ? How to make it clear to the reader and
>> implementor what to use when ?
>>
>> Two posisble approaches :
>> * we define everything (all the services) in the EJB spec and in
>> the same spec have a chapter defining what services apply to EJB
>> Full, EJB Lite, EJB Cloud
>> * we define everything (all the services) in the EJB spec. In
>> fact, we could even rename it to Enterprise Java Services
>> (instead of Enterprise Java Bean). Then, in the EE spec we
>> define what services are available in EE, in the Web Profil
>> spec we define what services are available in the Web Profile,
>> and in the Cloud Profile spec we define what services are
>> available in the Cloud Profile
>>
>> I have a preference with the second approach
>>
>
> EJB spec can't change to be something completely different than what it is
> today and services described in other specs can't become part of the EJB
> spec 3.2 (at least for backward compatibility). What can be done, is extract
> (or at least start on that path) common services and either create separate
> docs or create a common Java EE services doc (under the Platform spec or
> under the EJB spec - most probably the platform EG needs to decide on that).
>
> That said, it will still leave a question of if say, services A and B that
> are not required to be supported in the EJB Lite (or Web Profile), can a
> provider Z still support only A in their EJB Lite implementation? If the
> answer is yes, we have a problem. Besides explaining how to detect that, we
> need to describe how can it be tested that such service behaves correctly as
> expected in the EJB Full set? Current CTS suite is not available in a la
> carte mode, and it's not an easy task to create one out of existing tests
> (where the assumption always was that you can test either all or none).
>
Correct me if I'm wrong, but that's what happening with JBoss 6 (and Resin I
guess). Both implement the Web Profile and they both add JAX-RS (which is
not Web Profile) and JBoss 6 goes even further by adding JMS (and JAX-WS I
think). The EE 6 EG brought that at the time. The question was : "if there
is a RESTService in your war file and you deploy it to a Web Profile app
server, should the deployment fail?". The answer was clearly no. If service
A and B are not required in EJB Lite, these services shouldn't be tested in
the CTS (and the provider can still add them).
But that being said, I do not know how the CTS suite is made and how it
works.
Antonio
>
> Best,
> -marina
>
>>
>> Antonio
>>
>>
>>
>> The same applies to the Embeddable EJB Container.
>>
>> Thank you,
>> -marina
>>
>>
>>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect and Java Champion
>>
>> Web site <http://www.antoniogoncalves.**org<http://www.antoniogoncalves.org>>
>> | Twitter <http://twitter.com/agoncal> | Blog <
>> http://feeds.feedburner.com/**AntonioGoncalves<http://feeds.feedburner.com/AntonioGoncalves>>
>> | LinkedIn <http://www.linkedin.com/in/**agoncal<http://www.linkedin.com/in/agoncal>>
>> | Paris JUG <http://www.parisjug.org>
>>
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
Blog <http://feeds.feedburner.com/AntonioGoncalves> |
LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
JUG <http://www.parisjug.org>