• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

HF Master Mock Exam Q-18

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi


For the question ...

What's true about the client's view of security? (Choose all those that apply)
Options A and B are correct. But For ...

Option C: Transactional requests within a single transaction cannot arrive from multiple clients.

I am not sure why it is not true as well. Since this question is not for any specific bean type My take on it is ...

a. For Message Driven Beans since there is no client view, this option is not applicable
b. For Stateless session beans transaction has to either rollback or commit before function returns so multiple clients coming calling into single transaction is not possible. so ture again
c. For Stateful session beans only serve one specific client. Even though they are allowed to span transactions beyond one method, calls are always made by only single client, So c option is again true.
d. For Entity beans even though single enity bean can serve multiple clients internally since entity beans are container managed, their transactions either rollback or commit before function returns so multiple clients can't again arrive within a single transaction. so C is true again.


Please let me know where am i going wrong here?

Best,
Rahul
 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It says in the specification that:


If transactional requests within a single transaction arrive from multiple clients (this could happen
if there are intermediary objects or programs in the transaction call-chain), all requests
within the same transaction must be associated with the same security context.



Page 450

And As I can infer that means that the calls to getCallerPrincipal() should be the same. So I think you will not deem the third option "c" as true because it is not complete i.e. it should say with same security context or not. Does that sound like correct explanantion?. I am no expert here and so please do tell me.
 
Rahul Goyanka
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Seemapanth,

There are two things that I am not clear here.

1.What are the scenarios where there can be multiple clients that can arrive in a single transaction? I can only imagine of a bean calling other bean for some services in a same transaction. (Let me know if there are others too). If that is the case usually the security context passed by the initial client may be retained until the transaction is over.
2.In context to above, a bean can change its security context by using the <run-as> element in DD and becoming a different principal than the calling client�s principal. This means that that in the same transaction it is possible to change the security context by different calling clients.

In options C:
�Transactional requests within a single transaction cannot arrive from multiple clients.�

It is not mentioned that the multiple clients have same security context or different. If the option C was

�Transactional requests within a single transaction cannot arrive from multiple clients having different security context�

Then the option C should be false as per the specification stated above by you. And if C was

�Transactional requests within a single transaction cannot arrive from multiple clients having same security context�

Then C is true.

But as in point 1, beans can change there security context within a single transaction, so either the specs is wrong or the <run-as> element has something more to it that I am missing.

Thanks,
Rahul
 
seemapanth Joshi
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rahul,

Your point number 1:


1. What are the scenarios where there can be multiple clients that can arrive in a single transaction?



I lack the market experience to relate to a real world example of such a scenario. But according to the spec this could happen if there are intermediary objects or programs in the transaction call-chain. This is same as what you have referred to:

a bean calling other bean for some services in a same transaction.



For point number 2:


2. In context to above, a bean can change its security context by using the <run-as> element in DD and becoming a different principal than the calling client�s principal.



The specifications are probably asking you not to do exactly that. It come under "Client's responsibility" and it says:


This section defines the rules that the EJB client program [B]must follow to ensure that the security context passed on the client calls, and possibly imported by the enterprise bean, do not conflict with the EJB Server�s capabilities for association between a security context and transactions.[B]


Spec: Page 449

Does that sound like a logical explanantion???

[ August 05, 2005: Message edited by: seemapanth Joshi ]
[ August 05, 2005: Message edited by: seemapanth Joshi ]
 
Joel Salatin has signs on his property that say "Trespassers will be Impressed!" Impressive tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic