Thomas Taeger

Ranch Hand
+ Follow
since Dec 16, 2002
Merit badge: grant badges
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Thomas Taeger

- Is'nt there really any RPM?
- How to install from ZIP? [...]

I just had forgotten that e.g. JBoss comes with JavaEE installed for being an application server.
Well explained by Akshay Sahu in
For the JavaEE 7 installation I can not find a RPM, just a ZIP:
- Is'nt there really any RPM?
- How to install from ZIP? I downloaded and unzipped - but then (scriptable ...)? Is there any step-by-step explanation? Oracles "installation guide" is none.

Vasilis Souvatzis wrote:You need the 32bit version of the JRE. ....

For a 64 bit Windows - strange - but thanks a lot!
Today (2014-08-31) the same problem persists with
java_ee_sdk-7-jdk7-windows-x64-ml.exe (JavaSE deinstalled)
as well as with jdk-8u20-windows-x64.exe (JavaSE),
both downloaded today.
System: Win 7 Ultimate 64bit, autoupdating

I agree. Here's the link:

This Link does not help at all.
Thank you for providing your examples of 5 services. Each of your services provides more than one operation.

Originally posted by Johnty Rhodes:
BusinessDelegate pattern is not for providing coarse grained service...i think it is the fuction of Facade.

It is not for, ok. But what I want to show is: Business Delegate does best decouple if you apply it in a coarse grained way.

The cited description of a Business Delegate
- mentions the technical lookup, ok
- but leaves undecided how this hiding of the underlying implementation details is designed (and later implemented).

Originally posted by Johnty Rhodes:
So for all these service, I will have BusinessDelegates.

... or as you said before "If there are N services, then there will be N business delegates." So you would provide 5 Business Delegates here.

I agree that this is one way to apply the Business Delegate pattern correctly. But is it the best way or even the most adjacent / natural / usefull one?:

In big projects having a client developer team and a server developer team the Business Delegate is designed and coded by the server team and passed as a .jar to the client team. This is the praxis of decoupling here! The client team needs not and can not care about what methods should be provided by the Business Delegate. The server team does that because they best know how to minimize server turn-arounds. The client team just adds the jar and calls the methods of the Business Delegate provided by the server team (though running in the client).

If the server team has to decide
a) which operations to provide in which Business Delegate and
b) how many Business Delegates to provide,
then they most naturally think in what they provide in the Session Facade(s) and provide the same in the Business Delegate(s). That is where my "thinking in pairs of Business Delegate and Session Facade" comes from. It is just practical.

I even would say that Sun's description of a Business Delegate should also mention this practical pairing of Business Delegate and Session Facade as a strategy of the Business Delegate pattern.
P.S.: The "Delegate Proxy Strategy" (Core J2EE Patterns, p. 253) is most similar: "In this strategy, a Business Delegate provides proxy function to pass the client methods to the session bean it is encapsulating".

And for the assignment this pairing makes life easier. Business Delegate and Session Facade implement the same business interface! So in Sequence diagrams
- you can show this interface where the Business Delegate is needed and
- you can show this interface where the Session Facade is needed and
- you never need to worry that Business Delegate and Session Facade could get out of sync with each other.

[ July 01, 2006: Message edited by: Thomas Taeger ]
How do we define "Service"?
- Pretty sure not each usecase-level business operation.
- Maybe a largest-most remote business method callable in one single server turn-around.
- Maybe even more coarse grained, like "everything concerning to ordering", i.e. preselecting and selecting and sending an order and getting a confirmation and ...?
Do you know an exact definition of the term "Service"?
Or what is yours?

Originally posted by Johnty Rhodes:
If there are N services, ...

I assume you talk about business services here.

Originally posted by Johnty Rhodes:
... then there will be N business delegates.

Our vision of a Business Delegate differs.
For me a Business Delegate usually comes in pair with a Session Facade. Because Session Facades conceptually are coarse grained, in my thinking the Business Delegate is coarse grained too. There for decoupling reasons may be two Session Facades, e.g. one for miles (should be argued ...) and one for the rest, or just one Session Facade for all. So for my thinking in "pairs" there might be two or one Business Delegate in the client.

Before answering the rest I should wait for your definition of "Service".

[ July 01, 2006: Message edited by: Thomas Taeger ]

Originally posted by Johnty Rhodes:
If I put Business Delegates for all services, My Seq. diagram is becoming big ...

You probabely have N business Sequence diagrams? All using the same 1 BD&SL classes?
In such N:1 cases consider to construct 1 additional technical Sequence diagram (not the comon business sd I talked about in a previous post) in which you show
- the one interface of all the clients with a note "can be any of ..."
- the client-side Business Delegate used by all clients
- the client-side Service Locator
- the Session Facade and / or ...
- ... the business / workflow Session EJB (or the one interface of multiple Session EJBs) ...
- ... and / or business handlers ...
- ... with a note "can be any of ..."
- the server-side Business Delegate(s)
- the server-side Service Locator(s)
- server-side proxies, DAOs, etc. like for payment, external systems etc.
- and whatever you think is worth to be shown in between.

You need not and should not show these technical details in each business SD. But in my opinion you should show them in one. Maybe using ref, or even (without ref) as a technical overall view in parallel to what your business SDs show.

Originally posted by Johnty Rhodes:
Can I avoid putting BD and just attach notes saying 'Business Delegate and Service Locator is used to get the Sevice'?

The next idea could be to just show one client and one server-side do-what-I-mean component and providing the logic in notes instead of in sd messages - in extreme.
I think that is not a good idea, and hopefully it would cost points, because SCEA exam is not just a Business Architect exam but an "Enterprise Architect for J2EE Technology" exam, even if later some will specialize as Business Architect, some for security, some as Technical Architects, some more for Servlet techniques, some more for GUI techniques, etc. .

[ July 01, 2006: Message edited by: Thomas Taeger ]
Thank you for translating the BEA Weblogic term "JNDI authentication".

Up to here I understood two differences between container based authentication and JAAS:
1. In container based authentication we need to provide two parameters (INITIAL_CONTEXT_FACTORY and PROVIDER_URL).
. In JAAS we need to provide one parameter (JAAS authentication module name).
2. In container based authentication you may provide the parameters a) in a config file or b) hard coded (as in your example).
. In JAAS we [always] provide the parameter in a config file.

Are there any more differences?

Following what I did in my own assignment:
- Candidate Name should be first name and last name, not only Srinivas
- Candidate ID: SP9305599 (mine)
- Registration Number: ...
- Test Date: ... (of part I)
- File: scea-sp9305599.jar (including the index.html and all the image files)

Hope that this has been right.

Hello Raj,

Originally posted by Raj Nerurkar:
However I am concerned that this appraoch will make my solution
container dependent and will need considerable amount of
effort while porting to another container.

Pretty sure you have much more experience in EJB design, deployment, porting and maintenance than I have.

I wunder where container dependency could come in for CMP except for
- the way of deployment, i.e. the vendor specific deployment tool - ok
- using proprietary container extensions - necessarily?

Does for CMP any container dependency also come in for
- the deployment descriptors being vendor specific, and in what degree? (not just including an [additional] vendor specific jar)
- any vendor specific code changes needed?
- what else ...?


Originally posted by Saritha ventrapragada:
Actually I was thinking of one more layer of POJO classes (like facade classes) ...

Ok. That is what I would call the Session Facade pattern between, regardless of wether POJO or Session EJB implementation.


Originally posted by tony clare:
by using reference, I understand there are 3 sequence diagrams for each use case: web client, swing client and a common shared EBJ tier. Right ?

I see a fourth between the two client types and the "common shared EBJ tier": A sequence diagram generalizing common behaviour of the two client sequence diagrams and then referencing the app server sequence diagram ("common shared EBJ tier"). It is not a must, ok, but it reduces redundant parts of the client sequence diagrams, like fetching values from the model/helper, looking up the EJB, delegating business methods to the app server, ...

[ June 28, 2006: Message edited by: Thomas Taeger ]

Originally posted by Bobby Sh:
I was referring to 'Session Facade' of SUN to 'Facade' of GoF , based on their behavior.

Ok, interesting, now that the assignment relevance has been clarified provide us with your thoughts and doubts, please.


Originally posted by Maris Orbidans:
We are discussing authentication of SWING clients.

You are right in that the term "form-based authentication" is reserved for web clients, sorry.

However for application clients there is a kind of authentication between the client application container and the EJB container, normally popping up a login dialog, aside from JAAS. As I wrote: "For client logins, i.e. from a client application container to a EJB container there is no standard but a "must" that the provider of an EJB container and of the according client.jar must support container based authentication somehow." As I mentioned the way how this is implemented is vendor specific, i.e. not standardized, but the fact of the existence of this container-to-container-authentication is standard. Therefore JASS may be the only standard implementation of this authentication but JAAS is not the only standard mechanism that we can trust on.

That is why I would like to hear some reasons why it is worth for me to learn more about JAAS.
Especially what are the reasons why or when JAAS necesseraly must be used?
I would prefere to read some reasonings as I try to provide short reasonings too - not only links (though links can additionally be very helpfull for digging into later).

Originally posted by Maris Orbidans:
Of course, in practice we often use vendor specific JNDI authentication, but it's not ideal.

To be honest, the term "JNDI authentication" (or "vendor specific JNDI authentication") is new to me.
What I know is authentication via LDAP and accessing the LDAP server through JNDI as usual. Is this what you mean?

Why do you think authentication through LDAP (via JNDI) is not ideal? What are the reasons?

[ June 28, 2006: Message edited by: Thomas Taeger ]

Originally posted by Saritha ventrapragada:
If both the Web and Swing components are using same business logic why cant we have a generic Actor called UI, ...

Even if we had such a "generic Actor called UI" or "double-roled '...OrAgent' actor": As Tony Clare noted the sequence diagrams for both are "not 100% equal since the sequence for web users includes the servlets in web tier, and the sequence for Swing users doesn't includes the servlets." - and other controllers for the Swing GUI.

Originally posted by Saritha ventrapragada:
... generic Actor called UI, which initiates business logic

An actor should not (at least not directly) initiate any business logic, not for technical but for design pattern reasons. The needed conjunction is a web-server-side frontcontroller/helper and a client-side GUI/Swing controller/model.

These then can re-use the same common logic proposed by you.

Originally posted by Saritha ventrapragada:
We can draw seperate sequence diagrams for Swing and Web application.
In these diagram for the business part logic we would refer to the above sequence diagrams.

If you mean Swing and Web sequence diagrams referencing the same common logic sequence diagram: Yes.

And this common logic sequence diagram then can refer to a common app server logic sequence diagram.