Jay Sam

Greenhorn
+ Follow
since Feb 27, 2005
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jay Sam

Hi,

this question is directed to those who are familiar with the subject.doAs(subject, action) way of calling business methods on EJBs.

How can I pass parameters with this construct ?!? What if my client has to call a method on the EJB, encapsulated with the ACTION class, which requires parameters ?!

Also: how does this way of calling business methods on beans fit with the service locator pattern ? After all, service locator will at least create the bean and pass the reference. All later calls on the stateful session bean from the client will have to hand this reference to the Action helper classes...

Somehow I think there is another construct which is useful for this.

Are there any other incompatibilities between ServiceLocator and this way of calling the EJBs ?

Thanks for any help,

Jay
18 years ago
Hi,

does JAAS authentication on the client somehow knock off the need for a ServiceLocator pattern?

Scenario:
1) I request reference to a stateful session ejb via ServiceLocator
2) ServiceLocator authenticates with user "anonymous" and creates that ejb and returns the reference to it, as well as my "subject" object.
3) I make some calls using Subject.Doas
4) at some point, I decide to switch identity, therefore re-authenticating to the server
5) I do method calls on the same ejb as before

Doubts about ServiceLocator pattern integration with JAAS:
a) in this scenario, ServiceLocator looks up the bean for me. Have I got to provide any URL for logging in also ? I guess I must somehow decide - just as with EJBs - where to find the server to authenticate to, am I right ? If yes, will I need to write servicelocator functionality for looking up the "URL" of the service/server to authenticate to ?
If I need no URL for logging in, then this doubt is of no importance
b) in step 4, I decide to switch identity by re-authenticating to the server. Well - same problem: ServiceLocator gave me the proper EJB reference. So I guess it should also know - and _only_ ServiceLocator should know - where to re-authenticate to.


The most important doubt:
c) to call methods on EJBs in this way, I have to use the Subject.doAs(subject, action) construct. This means that I will have to define one action object for each method which can be called on the stateful sessoin EJB by the client. For creating my stateful session EJB, then, I could create a "create" action right away, without the ServiceLocator needing to be involved. That "create" action would hand me back the reference to the EJB, and I could authenticate prior to doing that. In fact, only the "create" action needs to access ServiceLocator functionality with this design. So - is it still useful for anything ?

How would you combine ServiceLocator pattern with JAAS, in the case of the above scenario ?

Thanks,

J
18 years ago
Hi,

does JAAS authentication on the client somehow knock off the need for a ServiceLocator pattern?

Scenario:
1) I request reference to a stateful session ejb via ServiceLocator
2) ServiceLocator authenticates with user "anonymous" and creates that ejb and returns the reference to it, as well as my "subject" object.
3) I make some calls using Subject.Doas
4) at some point, I decide to switch identity, therefore re-authenticating to the server
5) I do method calls on the same ejb as before

Doubts about ServiceLocator pattern integration with JAAS:
a) in this scenario, ServiceLocator looks up the bean for me. Have I got to provide any URL for logging in also ? I guess I must somehow decide - just as with EJBs - where to find the server to authenticate to, am I right ? If yes, will I need to write servicelocator functionality for looking up the "URL" of the service/server to authenticate to ?
If I need no URL for logging in, then this doubt is of no importance
b) in step 4, I decide to switch identity by re-authenticating to the server. Well - same problem: ServiceLocator gave me the proper EJB reference. So I guess it should also know - and _only_ ServiceLocator should know - where to re-authenticate to.


The most important doubt:
c) to call methods on EJBs in this way, I have to use the Subject.doAs(subject, action) construct. This means that I will have to define one action object for each method which can be called on the stateful sessoin EJB by the client. For creating my stateful session EJB, then, I could create a "create" action right away, without the ServiceLocator needing to be involved. That "create" action would hand me back the reference to the EJB, and I could authenticate prior to doing that. In fact, only the "create" action needs to access ServiceLocator functionality with this design. So - is it still useful for anything ?

How would you combine ServiceLocator pattern with JAAS, in the case of the above scenario ?

Thanks,

J
Hi,

I am using JAAS to authenticate to the EJB tier.

I will then, from the client, call: Subject.doAs(subject, action);

Now imagine the following scenario:
1) client calls servicelocator and gets reference to stateful session ejb
2) client authenticates with security credentials through jaas, with user "anonymous"
3) client invokes methods on stateful session ejb using "Subject.doAs", some conversational state has been built up on behalf of the client in the stateful session ejb
4) client decides to authenticate as a new, more privileged user
5) client authenticates as new user, gets new subject this way
6) client continues to invoke methods on the OLD stateful session ejb with the NEW subject

Questions:
1) is all of this possible ?
2) is the way I use the service locator correct, or should I design this differently ?
3) is it possible to use the conversational state of the OLD stateful session EJB with the NEW subject ?
4) with this form of authentication, will I always have to invoke methods with doAs(subject, action) lines ?

Regards,

Jay
Hi,

this is my scenario:

1) client authenticates via JAAS
2) gets reference to stateful session EJB
3) calls some methods
4) at some point, client decides to re-authenticate, because he needs to call more privileged methods. So he authenticates as a more privileged user.
5) client calls methods on stateful session EJB with new, more privileged status

My questions:
a) will I be able to use the same EJB reference, although having switched security context by reauthenticating to JAAS ?
b) will state in the stateful session EJB still be bound to me, or will I have to transfer state to a new session EJB ?
c) do I - as authenticated user with JAAS, have to call every method on the EJB with the doAS(Subject, EJBHandle) syntax ?

Regards,

Jay
Hi,

a) I want several applications/services (java+non-java) to access the same user base. The service providing the user base also should provide authentication mechanisms. The ejb container should be able to access this structure. Ideally, a client calls the ejb, and is at the beginning associated with an "anonymous" user, until the client decides to authenticate. Is this possible ? What kind of architecture would you recommend ? What I definitely do NOT want is : use a web container for this, or servlet functionality. I do want to do authentication at EJB container level, or EJB level.

b) When the client decides to authenticate, how can I make the stateful session ejb be aware of the client�s new security identity ? I guess it must be stored in a context variable to do that. Also, the ejb - I guess - will have to make calls for this (programmatic). what do those calls look like ? How can I do that ?

c) Imagine I want to create a new user at runtime, and associate the client with the security context of that new user. How is all of this best done ?

My personal guess is: LDAP user base with authentication mechanism. EJB accesses that tree. EJB stores new sec identity in its own context variable, so it aquires the new sec identity (is this possible and allowed for an EJB ?). But all other questions still remain open for me.

Regards,

Jay
Hi,

a) I want several applications/services (java+non-java) to access the same user base. The service providing the user base also should provide authentication mechanisms. The ejb container should be able to access this structure. Ideally, a client calls the ejb, and is at the beginning associated with an "anonymous" user, until the client decides to authenticate. Is this possible ? What kind of architecture would you recommend ? What I definitely do NOT want is : use a web container for this, or servlet functionality. I do want to do authentication at EJB container level, or EJB level.

b) When the client decides to authenticate, how can I make the stateful session ejb be aware of the client�s new security identity ? I guess it must be stored in a context variable to do that. Also, the ejb - I guess - will have to make calls for this (programmatic). what do those calls look like ? How can I do that ?

c) Imagine I want to create a new user at runtime, and associate the client with the security context of that new user. How is all of this best done ?

My personal guess is: LDAP user base with authentication mechanism. EJB accesses that tree. EJB stores new sec identity in its own context variable, so it aquires the new sec identity (is this possible and allowed for an EJB ?). But all other questions still remain open for me.

Regards,

Jay
[ March 28, 2005: Message edited by: Jay Sam ]
18 years ago
Hi - this is to anyone who already passed Part 2.

I guess you did use Servlet Filter pattern (as in the petstore example) for signing users on to protected areas.

Well anyhow, I do.

My question: did you mention and show the filter in the sequence diagrams ?
Did you show generation of value objects etc. in the sequence diagrams ?

I wonder if that level of detail is necessary. I would like to mention the servlet filter in the text, and not show it in the sequence diagrams.

Regards,

Jay
We dont know it.

We have to make assumptions for this.. alternatively, you can discuss different scenarios for this in your document I guess.

Unfortunately, the requirements are very unprecise - so.. you have to make guesses and show that even if you�re wrong with your guesses, you can solve the problem.
Hi,

I guess you did use Servlet Filter pattern (as in the petstore example) for signing users on to protected areas.

Well anyhow, I did.

My question: did you mention and show the filter in the sequence diagrams ?
Did you show generation of value objects etc. in the sequence diagrams ?

I wonder if that level of detail is necessary. I would like to mention the servlet filter in the text, and not show it in the sequence diagrams.

Regards,

Jay
Hi Yong,

I guess you did use Servlet Filter pattern (as in the petstore example) for signing users on to protected areas.

Well anyhow, I did.

My question: did you mention and show the filter in the sequence diagrams ?
Did you show generation of value objects etc. in the sequence diagrams ?

I wonder if that level of detail is necessary. I would like to mention the servlet filter in the text, and not show it in the sequence diagrams.

Regards,

Jay
Hi Yong,

well ad c) - I really tried to find that in the use cases - can you give me a hint ?

There is another issue: did you make use of the timer service ? (if yes, I know what kind of seat-booking policy you have been using)

Regards,

Jay
Hey Ho,

well - I am not wondering about the technical issues - there are other things that somehow worry me.

a) do I have to provide sequence diagrams for every alternative flow ? I hope written text will be sufficient if I provide one sequence diagrams, and then specify how alternative flows will alter the sequence diagram. Example:
"Prepare Itinerary" - there are different flows here, depending on if you formulate a new itinerary in cooperation with the system, or if you formulate a new version of an old itinerary, when you preivously chose to change an itinerary.
b) what about the policies that you chose for seat booking and cancellation of seats ? This pretty much determines how you handle payment, preparation and change of itineraries.
c) what did you chose to do, if the new version of the itinerary was not more expensive, but cheaper than the older one ?
d) I will have 5 sequence diagrams
one for Prepare Itinerary (whether you come from change itinerary or not), 3 for Pay for Itinerary (one coming rom prepare use case, one that starts with listed itineraries, another one to explain how award travel is handled), and one for "change itinerary". Why did you have 6 ?

Regards,

Jay
[ March 15, 2005: Message edited by: Jay Sam ]
Hi,

our mission is to design a classic web/servletcontainer + ejbserver + database application.

In order to provide maximum future flexiblity for support of multiple client types, maximum interoperability, I chose to represent all services provided on the EJB container as web services. The "normal" way to do this, is by publishing th web services backed by the ejb�s at servlet-container level.

Now: imagine we want to change web server in the future, and the server doesnt support servlets. It is a
php-based framework, whiclh can only access web services to integrate J2EE
applications. So, now, we have 2 choices: the first solution is to have a
free web server with servet container, and to publish web services with
the servlets. The other choice we have is not to use the free
servlet-enabled web server, but to use web services which are directly
provided by the ejb-container from the start ! What would you say is a better choice ? I think directly using web services from the ejb-container is a better choice from the start. What would you say ? The only I thing I am not sure about is whether Sun has clerly made it a requirement for ejb-containers to support webservices. Have they ? If yes, web services directly provided from the ejb container are the right choice for the most flexible framework !! And in this case, I think XML is the right choice right away, for communication between webserver/servletcontainer and ejb-container.
What would you say ? Would you use XML ? XML is so flexible, we can do the
whole use cases with one XML type of document. If the requirements change,
in the future, we will most likely only have to modify this document, if
at all - because it is very flexible from the start.
I know it is not part of the requirements to think that far, but :
- using this XML approach is simplifying so many things, and even sequence
diagrams, that I want to use it.

Best regards,

Jay
Hi,

our mission is to design a classic web/servletcontainer + ejbserver + database application.

In order to provide maximum future flexiblity for support of multiple client types, maximum interoperability, I chose to represent all services provided on the EJB container as web services. The "normal" way to do this, is by publishing th web services backed by the ejb�s at servlet-container level.

Now: imagine we want to change web server in the future, and the server doesnt support servlets. It is a
php-based framework, whiclh can only access web services to integrate J2EE
applications. So, now, we have 2 choices: the first solution is to have a
free web server with servet container, and to publish web services with
the servlets. The other choice we have is not to use the free
servlet-enabled web server, but to use web services which are directly
provided by the ejb-container from the start ! What would you say is a better choice ? I think directly using web services from the ejb-container is a better choice from the start. What would you say ? The only I thing I am not sure about is whether Sun has clerly made it a requirement for ejb-containers to support webservices. Have they ? If yes, web services directly provided from the ejb container are the right choice for the most flexible framework !! And in this case, I think XML is the right choice right away, for communication between webserver/servletcontainer and ejb-container.
What would you say ? Would you use XML ? XML is so flexible, we can do the
whole use cases with one XML type of document. If the requirements change,
in the future, we will most likely only have to modify this document, if
at all - because it is very flexible from the start.
I know it is not part of the requirements to think that far, but :
- using this XML approach is simplifying so many things, and even sequence
diagrams, that I want to use it.

Best regards,

Jay
19 years ago