Tibor Hegyi

Hi,

I have an enterprise app installed under weblogic 8.1 that uses J2EE security. We log into the web container (j_security_check), the security context (SC1) is properly propagated to the ejb container. So far so good.

From an EJB, I must call another EJB in a remote application server that is Weblogic 7.0.4. To do this I explicitely specify the parameters to open the InitialContext on the remote server. These parameters are Context.PROVIDER_URL, Context.INITIAL_CONTEXT_FACTORY, Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS.

The remote weblogic server does not know the security context in the local weblogic server (SC1), this is why I specify the principal/credentials pair that is valid on the remote server.

I can create the InitialContext, I can lookup the Home interface of the EJB in the remote server, but when I call homeObj.create() to create a Stub to an EJB instance, the remote server throws a "java.lang.SecurityException: Invalid Subject, principals=[<principals from the local weblogic server>]".

Which means that the local security context is propagated to the remote weblogic server, although I have explicitely specified it as the parameters to the InitialContext.

Can anybody help me to solve this problem?

Thanks in advance, I hope the above description is clear enough.

Tibor

After 6 weeks, I got the result which was better than what I had expected before.

Test: Sun Certified Enterprise Architect for Java 2 Platform Enterprise Edition Technology Part II (310-061)
Date Taken: 2004-06-19 23:06:12.467
Registration Number: k75dus5101
Site: hn4
Grade: P
Score: 100
Comment: This report shows the total points that could have been awarded in each section and the actual amount of points you were awarded. This information is provided in order to give you feedback on your relative strengths on a section basis. The maximum number of points you could have received is 100, minimum to pass is 70.
Class Diagram (44 maximum) .......................... 44
Component Diagram (44 maximum) ...................... 44
Sequence/Colloboration Diagrams (12 maximum) ........ 12

Short comments:
1. I followed the "minimalist" direction, this means I tried to keep the design simple and to the point. Don't waste time on the very details.

2. An appropriate list of assumptions was very important for me. I specified here how I interpreted the business case and the major terms (Segment, Flight, Seat, etc) and the use cases, and lot of other aspects that had not been detailed in the specs.

3. I had one class diagram which as very simple and clear. I provided one component diagram that I tried to keep moderate by documenting those components that were not drawn. And I created one sequence diagram per use case (all the seven use cases), two of them were broken down to pieces otherwise the diagram would have been too huge.

4. Beside the assumptions, I documented the design decisions, the NFSRs in detail, the classes, components and relationships, and of course the design patters I used. It was all about 10 pages.

Good luck for everyone!

Tibor

Thank you very much for sharing your thoughts!
I think I got the picture.
Tibor

I pick this thread up, maybe a few SCEAs or UML experts share some thoughts of theirs on the issues mentioned in the first post.
This would be very much appreciated.

Hi Thomas,
Concerning Sequence Diagrams, what I meant was whether the objects, they show to express the interactions fulfilling a use case, correspond to components or to classes.
I also lack a good documented Component Diagram Example espacially from the perspective of an architect. The UML spec is also quite brief on Component Diagrams.

I think I will treat as a component each:
- at least one shared JAR of server related classes,
- at least one shared common JAR (for server and client),
- each JAR of each EJB,
- the ServiceLocator,
- the BusinessDelegates (depends on ServiceLocator)
- each Factory
- each WebCommand/Command pair
- each JSP or Servlet,
- the Java-client in total,

More or less this is the current case with my Component Diagram too. Factory/Command are also in this one as components. For the time being, I have not shown JARs as groups of components but individual components only.
Let's see if anybody else can clarify our doubts.
Thanks again!
Tibor

Hi Thomas,
First I thank you for your detailed reply. All you wrote sounds reasonable
and correct.
Although I don't think I'd submit as many diagrams as you listed, but one question occured to me. I wonder whether your Component Diagram will contain components based on your Detailed Class Diagram or on your Raw Class Diagram. I guess the former is true.
I think all my concerns arise from one point: What to put into the Class Diagram? Only a fixed BDM + several controllers or quasi everything (including Command, Factory as well)?
As simplicity is emphasised overall in this forum, I prefer the first approach, but then the some questions needs to be answered. (see my questions in the original post)
I understand that there might be different levels of abstraction in the diagrams, what I'm not totally sure of is what Sun expects from us in an Architect exam.
Still looking for a consistent approach in the light of the requested deliverables (1 Class Diagram, 1 Component Diagram and several Interaction Diagrams)...
Tibor

Hi,
I have read through a couple of hudreds of threads in this forum to gain consistent understanding on
approaches to creating diagrams for Part II.
Unfortunately, I could not resolve the ambiguties I found.
So my questions are:
1. What exactly should be drawn in the class diagram? I have drawn my extended, slightly changed BDM with some controller classes
a'la Cade.
2. What about classes not directly related to the business case but rather to the implementation details? I mean classes like
Command or Factory? Shall these go into the Component Diagram? If so, in form of classes or of components?
3. Which diagram is the sequence diagram built on? Some on this forum said it should be built on the Class Diagram showing
messages sent between classes. Some said (along with Cade) it should be built on Components showing interaction of components.
4. If the sequence diagram is based on the class diagram, do we have to specify all the classes in the Class Diagram that will become a
technology specific component/class in the Component Diagram? E.g. I have a Business Controller (EJB) component that does not
manage business objects directly but rather interacts with Facades. Shall I add a corresponding class to the Class Diagram in order to use it
the sequence diagram? I'm not talking about Home/remote etc interfaces...
To put it short, does each component have to have a corresponding class in the Class Diagram?
I tend to think this is not true and the sequence diagram should be based on the Component Diagram because this way it can direct
developers on the interaction of the components matching the use cases.
As you see, I'm a bit confused but I think these questions occur to many of us preparing Part II, so any help is very much appreciated!
Thanks,
Tibor

Originally posted by Leonardo Penha:
Hi,
I am currently designing my component diagram, and I feel the ServiceLocator component is cluttering it. Every EJB dependency relationship has to use the service locator to lookup the bean. In my case I have 3 Session Facades plus a few other Entity Beans. If every EJB dependency needs a service locator then I have too many lines crossing each other in the diagram.
I was thinking about providing just one example of an EJB lookup via service locator in a separate component diagram and saying in my assumptions document that every EJB dependency relationship in the main component diagram uses the service locator.Would anyone think this is acceptable?

IMHO:
Could that be that the ServiceLocator is a class but not a component?
Component diagrams should contain components (EJB, JSP, etc) but not classes.
Tibor