Re: AW: accessing EJB components from a Struts application?

[Vic Cekvenich]

And, and, and another thing.
Open source is explained by "the Cathedral and the Bazaar best ( a book).
The more choices and competition lead ot better software. Monolithic is 
keep in the dark. Just look at Linux security issues (open source) vs 
Monolithic (MS security issues).
MS is just not secure to run anything. (sort of Democracy and capitalism 
vs Monolithic; democracy sucks, but relative to everything else, it is OK)

When you purchase software, you typically negotiate that you can 
purchase the source code if the Vendor goes out of business. Struts just 
saves you that step. Everyone can see and suggest improvements and find 
out how it works,
And if you use WebLogic and change it they should own the code. 
(Sort of drinking Coke and adding Lemon, you do not have the rights to 
Coke formula now?) Struts... ditto. If you write an applications that 
uses WebLogic, you own the application. If you write an application that 
uses Struts, you own the application code. (Everyone but lawyers knows 
the diff. between System and Application code right?)
Did you ever find a product you like, only to find that the vendor no 
longer supports it?

Is there better support for any $ then Struts mail list?

The Bazaar approach is leading and stretching the lead to date.
Here are some stats:
http://www.netcraft.com/Survey/Reports/0111/bydomain/com

And the trump card! Who amongst you would purchase a proprietary portal 
framework?

And doing JSP / or JSP tag / or JSP JDBC / or JSP SQL code or anything 
much in the view is just bad and slow productivity. JDBC should go 
in the Model!

Vic

or even see:
http://news.cnet.com/news/0-1003-200-7720536.html



Cakalic, James wrote:

>If I had more time I would comment on this more fully as it seems some of
>the ideas being expressed here are off-the-mark and short-sighted.
>
>I don't mean to go on a rant here, but my job would be much easier if we
>just used JSPs and JDBC. To heck with those creative types; if they can't
>read our Java code then they shouldn't have a role in development. If they
>want to change the look and feel of the application, let them just try to
>work around my code. And why should I care about extensibility, flexibility,
>maintainability, robustness, and scalability? I'm being measured on whether
>I deliver the system by a specific date. Let the maintenance team figure out
>that other stuff. I mean, don't they have the other 80% of the software's
>life to do that? All I have is the first 20%! Model-View-Controller -- what
>is up with that anyway? Aren't web applications just about displaying
>something in a browser? If the user can't see it, it doesn't matter. All
>that pattern garbage is just wasteful muttering. How often do application
>requirements really change anyway? I think those guys at Prentice-Hall just
>made it all up because they wanted to sell more books. All that stuff about
>transactions and security. Isn't that why I buy a database? And why should I
>let the people deploying the application make any decisions? They didn't
>help me when implementing the application. Why should I care whether it is
>easy to deploy and administer? Oh yeah, while I'm on the topic, this whole
>open source thing is really worrisome. I mean, how can I trust that code?
>And those licenses -- don't they say that I have to open up and give away
>everything that I write if even one line of open source is in my
>application? And why is that there seem to be multiple solutions to the same
>problem? Jeez -- Jakarta even has two different regular expression
>implementations. I wish one vendor would step in and give me just one way to
>do everything on one hardware platform in one development environment with a
>fixed set of services. Don't all good ideas come from one place anyway?
>Excuse me, I've got some JSP/JDBC work to do -- or was that ASP/ODBC? See!
>Now you got me all confused!
>
>;-)
>
>Best regards,
>Jim Cakalic
>
>
>
>>-----Original Message-----
>>From: Chris Smith [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, December 19, 2001 8:21 AM
>>To: Struts Users Mailing List
>>Cc: [EMAIL PROTECTED]
>>Subject: Re: AW: accessing EJB components from a Struts application?
>>
>>
>>I like MVC as per : http://www.basebeans.com/struts.jsp (and just the 
>>summary part)
>>
>>Here is Sun's approach, which I think just sells more hardware, from 
>>their web site:
>>"The key design pattern used in the Java Pet Store demo is the 
>>Model-View-Controller architecture, which separates three 
>>distinct forms 
>>of functionality within the application. To learn more about the 
>>Model-View-Controller architecture in the Java Pet Store demo, read 

Re: AW: accessing EJB components from a Struts application?

[Vic Cekvenich]

//Are you trying to upset me?
Ahhh.
If you don't get productivity out of Java, you would move to whatever, 
and I think most of use would. After all, all we want to do is build a 
business application to solve a business problem, and not solve 
technology problem, only apply technology.

I put forth that the fastest way to develop any, including personalized 
portal applications is in Java, using Struts for MVC and applying OO. 
(only a side benefit is that if you do J2EE you can change to a better / 
faster / cheaper container anytime your Vendor drives up in a new BMW)

Example: PIM application "design":

I.
1.call action to search names
2.call action to list names
3.call action to zoom a name
4.call action to list detail contacts for the name via FK.
5.call action to zoom a single contact
(set up struts.xml to find action classes)


II.
Each action goes to a JSP page . ( 5 pages in this case)

III.
For each page create a FormValidateBean with getters and setters for the 
fields on JSP. (5 FromBeans) Set a property of RowSet on each form bean 
for CRUD (RowSet has a simple 1 line update() method that updates to DB).

IV.
Add Tiles layout so it looks all nice. (Change struts.xml to call 
definitions instead of JSP)

V.
Change actions to call FormBean.validate() method on update. ( Set up 
validate.xml with reg. expresions)

VI.
Add container security (via JDBC realms)

VII.
Centralized Menus are trivial

See how MVC OO is the most productive way to leverage and reuse and be 
productive. Nothing is more productive.

Alternative approach: Let client hire some fast and inexpensive typists 
to crank out lots of code, maybe overseas development. (That would be 
like LA Lakers hiring cheap bastketball players, to save money)

I assure you you will outcode a big group of them. The 2nd time you do a 
"simple" but realistic 5 screen application like above, it should take 
you days, not weeks.
So... 5 screens in a few days, not bad!
The benefits to OO reuse on a biger application OO gets more 
porudctive the bigger the app.

Vic
(in fact I know a public class that teaches you to do a 5 screen Struts 
application in 3 days)



Cakalic, James wrote:

> If I had more time I would comment on this more fully as it seems some of
> the ideas being expressed here are off-the-mark and short-sighted.
> 
> I don't mean to go on a rant here, but my job would be much easier if we
> just used JSPs and JDBC. To heck with those creative types; if they can't
> read our Java code then they shouldn't have a role in development. If they
> want to change the look and feel of the application, let them just try to
> work around my code. And why should I care about extensibility, flexibility,
> maintainability, robustness, and scalability? I'm being measured on whether
> I deliver the system by a specific date. Let the maintenance team figure out
> that other stuff. I mean, don't they have the other 80% of the software's
> life to do that? All I have is the first 20%! Model-View-Controller -- what
> is up with that anyway? Aren't web applications just about displaying
> something in a browser? If the user can't see it, it doesn't matter. All
> that pattern garbage is just wasteful muttering. How often do application
> requirements really change anyway? I think those guys at Prentice-Hall just
> made it all up because they wanted to sell more books. All that stuff about
> transactions and security. Isn't that why I buy a database? And why should I
> let the people deploying the application make any decisions? They didn't
> help me when implementing the application. Why should I care whether it is
> easy to deploy and administer? Oh yeah, while I'm on the topic, this whole
> open source thing is really worrisome. I mean, how can I trust that code?
> And those licenses -- don't they say that I have to open up and give away
> everything that I write if even one line of open source is in my
> application? And why is that there seem to be multiple solutions to the same
> problem? Jeez -- Jakarta even has two different regular expression
> implementations. I wish one vendor would step in and give me just one way to
> do everything on one hardware platform in one development environment with a
> fixed set of services. Don't all good ideas come from one place anyway?
> Excuse me, I've got some JSP/JDBC work to do -- or was that ASP/ODBC? See!
> Now you got me all confused!
> 
> ;-)
> 
> Best regards,
> Jim Cakalic
> 
> 
> 
> 
>>-Original Message-
>>From: Chris Smith [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, December 19, 2001 8:21 AM
>>To: Struts Users Mailing List
>>Cc: [EMAIL PROTECTED]
>>Subject: Re: AW: accessing EJB components from a Struts application?
>>
>>
>

RE: AW: accessing EJB components from a Struts application?

[Keith Bacon]

Hi james,
woo hoo! That'll start some fun!
If you want to a system that will run for 10 years
where core parts of it will be enhanced dozens of
times, user interfaces re-vamped & written on new
platforms etc... then your company/client will benefit
from all these disciplines.
More money is spent on enhancing & debugging big
systems than developing them - it's the aim to get
these costs down.
Beleive me I work in a company where the
shortsightedness of client server developers is
costing huge amounts.
Keith.


--- "Cakalic, James" <[EMAIL PROTECTED]>
wrote:
> If I had more time I would comment on this more
> fully as it seems some of
> the ideas being expressed here are off-the-mark and
> short-sighted.
> 
> I don't mean to go on a rant here, but my job would
> be much easier if we
> just used JSPs and JDBC. To heck with those creative
> types; if they can't
> read our Java code then they shouldn't have a role
> in development. If they
> want to change the look and feel of the application,
> let them just try to
> work around my code. And why should I care about
> extensibility, flexibility,
> maintainability, robustness, and scalability? I'm
> being measured on whether
> I deliver the system by a specific date. Let the
> maintenance team figure out
> that other stuff. I mean, don't they have the other
> 80% of the software's
> life to do that? All I have is the first 20%!
> Model-View-Controller -- what
> is up with that anyway? Aren't web applications just
> about displaying
> something in a browser? If the user can't see it, it
> doesn't matter. All
> that pattern garbage is just wasteful muttering. How
> often do application
> requirements really change anyway? I think those
> guys at Prentice-Hall just
> made it all up because they wanted to sell more
> books. All that stuff about
> transactions and security. Isn't that why I buy a
> database? And why should I
> let the people deploying the application make any
> decisions? They didn't
> help me when implementing the application. Why
> should I care whether it is
> easy to deploy and administer? Oh yeah, while I'm on
> the topic, this whole
> open source thing is really worrisome. I mean, how
> can I trust that code?
> And those licenses -- don't they say that I have to
> open up and give away
> everything that I write if even one line of open
> source is in my
> application? And why is that there seem to be
> multiple solutions to the same
> problem? Jeez -- Jakarta even has two different
> regular expression
> implementations. I wish one vendor would step in and
> give me just one way to
> do everything on one hardware platform in one
> development environment with a
> fixed set of services. Don't all good ideas come
> from one place anyway?
> Excuse me, I've got some JSP/JDBC work to do -- or
> was that ASP/ODBC? See!
> Now you got me all confused!
> 
> ;-)
> 
> Best regards,
> Jim Cakalic
> 
> 
> 
> > -Original Message-
> > From: Chris Smith [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, December 19, 2001 8:21 AM
> > To: Struts Users Mailing List
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: AW: accessing EJB components from a
> Struts application?
> > 
> > 
> > I like MVC as per :
> http://www.basebeans.com/struts.jsp (and just the 
> > summary part)
> > 
> > Here is Sun's approach, which I think just sells
> more hardware, from 
> > their web site:
> > "The key design pattern used in the Java Pet Store
> demo is the 
> > Model-View-Controller architecture, which
> separates three 
> > distinct forms 
> > of functionality within the application. To learn
> more about the 
> > Model-View-Controller architecture in the Java Pet
> Store demo, read 
> > Building Blocks of a J2EE Application from the
> previous release.
> > [Java[tm] Pet Store Demo]
> > JavaTM Pet Store Demo
> > 
> > New in Release 1.3
> > The Java Pet Store represents a typical e-commerce
> application, 
> > presenting views of products and services for
> sale, including cats, 
> > dogs, fish, exotic iguanas, and reptiles. The
> application 
> > incorporates 
> > the following technologies:
> >  * The JavaServer PagesTM (JSPTM) framework
> >  * Java Servlet APIs, including filters and
> listeners
> >  * The Java Message Service (JMS)
> >  * Enterprise JavaBeansTM (EJBTM) components,
> including 
> > container-managed persistence (CMP), message
> driven beans 
> > (MDB), and the 
> > EJB Query La

RE: AW: accessing EJB components from a Struts application?

[Cakalic, James]

If I had more time I would comment on this more fully as it seems some of
the ideas being expressed here are off-the-mark and short-sighted.

I don't mean to go on a rant here, but my job would be much easier if we
just used JSPs and JDBC. To heck with those creative types; if they can't
read our Java code then they shouldn't have a role in development. If they
want to change the look and feel of the application, let them just try to
work around my code. And why should I care about extensibility, flexibility,
maintainability, robustness, and scalability? I'm being measured on whether
I deliver the system by a specific date. Let the maintenance team figure out
that other stuff. I mean, don't they have the other 80% of the software's
life to do that? All I have is the first 20%! Model-View-Controller -- what
is up with that anyway? Aren't web applications just about displaying
something in a browser? If the user can't see it, it doesn't matter. All
that pattern garbage is just wasteful muttering. How often do application
requirements really change anyway? I think those guys at Prentice-Hall just
made it all up because they wanted to sell more books. All that stuff about
transactions and security. Isn't that why I buy a database? And why should I
let the people deploying the application make any decisions? They didn't
help me when implementing the application. Why should I care whether it is
easy to deploy and administer? Oh yeah, while I'm on the topic, this whole
open source thing is really worrisome. I mean, how can I trust that code?
And those licenses -- don't they say that I have to open up and give away
everything that I write if even one line of open source is in my
application? And why is that there seem to be multiple solutions to the same
problem? Jeez -- Jakarta even has two different regular expression
implementations. I wish one vendor would step in and give me just one way to
do everything on one hardware platform in one development environment with a
fixed set of services. Don't all good ideas come from one place anyway?
Excuse me, I've got some JSP/JDBC work to do -- or was that ASP/ODBC? See!
Now you got me all confused!

;-)

Best regards,
Jim Cakalic



> -Original Message-
> From: Chris Smith [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 19, 2001 8:21 AM
> To: Struts Users Mailing List
> Cc: [EMAIL PROTECTED]
> Subject: Re: AW: accessing EJB components from a Struts application?
> 
> 
> I like MVC as per : http://www.basebeans.com/struts.jsp (and just the 
> summary part)
> 
> Here is Sun's approach, which I think just sells more hardware, from 
> their web site:
> "The key design pattern used in the Java Pet Store demo is the 
> Model-View-Controller architecture, which separates three 
> distinct forms 
> of functionality within the application. To learn more about the 
> Model-View-Controller architecture in the Java Pet Store demo, read 
> Building Blocks of a J2EE Application from the previous release.
> [Java[tm] Pet Store Demo]
> JavaTM Pet Store Demo
> 
> New in Release 1.3
> The Java Pet Store represents a typical e-commerce application, 
> presenting views of products and services for sale, including cats, 
> dogs, fish, exotic iguanas, and reptiles. The application 
> incorporates 
> the following technologies:
>  * The JavaServer PagesTM (JSPTM) framework
>  * Java Servlet APIs, including filters and listeners
>  * The Java Message Service (JMS)
>  * Enterprise JavaBeansTM (EJBTM) components, including 
> container-managed persistence (CMP), message driven beans 
> (MDB), and the 
> EJB Query Language
>  * Java Foundation Classes/Swing GUI (J.F.C./Swing) 
> components for a 
> rich client user interface launched via Java Web Start software
>  * Java APIs for XML
>  * Extensible Style Sheets for Transformation (XSLT)
>  * Reusable web application framework
> 
> The application takes and processes orders, managing credit card 
> information, user logins, shipping information, and shopping 
> cart sessions.
> "
> Do you see how this is to complex? This is why I think people give up 
> and go to Microsoft .NET. I would say a large majority of clients are 
> moving to .NET.
> 
> KISS. (Keep it simple)
> To me alternative is Struts as implementation of a MVC Frame 
> work, which 
> is a sweet spot, productively applied to a business 
> application. (There 
> are others who like coding just to get fun technology). To me 
> EJBs were 
> for distributed applications. I think less then 5% of 
> applications out 
> there need to be distributed, hence I ask a question why do 
> you need an 
> EJB? (Does anyone deploy client side Java?).
> 
> Or even this: http:/

Re: AW: accessing EJB components from a Struts application?

[Chris Smith]

I like MVC as per : http://www.basebeans.com/struts.jsp (and just the 
summary part)

Here is Sun's approach, which I think just sells more hardware, from 
their web site:
"The key design pattern used in the Java Pet Store demo is the 
Model-View-Controller architecture, which separates three distinct forms 
of functionality within the application. To learn more about the 
Model-View-Controller architecture in the Java Pet Store demo, read 
Building Blocks of a J2EE Application from the previous release.
[Java[tm] Pet Store Demo]
JavaTM Pet Store Demo

New in Release 1.3
The Java Pet Store represents a typical e-commerce application, 
presenting views of products and services for sale, including cats, 
dogs, fish, exotic iguanas, and reptiles. The application incorporates 
the following technologies:
 * The JavaServer PagesTM (JSPTM) framework
 * Java Servlet APIs, including filters and listeners
 * The Java Message Service (JMS)
 * Enterprise JavaBeansTM (EJBTM) components, including 
container-managed persistence (CMP), message driven beans (MDB), and the 
EJB Query Language
 * Java Foundation Classes/Swing GUI (J.F.C./Swing) components for a 
rich client user interface launched via Java Web Start software
 * Java APIs for XML
 * Extensible Style Sheets for Transformation (XSLT)
 * Reusable web application framework

The application takes and processes orders, managing credit card 
information, user logins, shipping information, and shopping cart sessions.
"
Do you see how this is to complex? This is why I think people give up 
and go to Microsoft .NET. I would say a large majority of clients are 
moving to .NET.

KISS. (Keep it simple)
To me alternative is Struts as implementation of a MVC Frame work, which 
is a sweet spot, productively applied to a business application. (There 
are others who like coding just to get fun technology). To me EJBs were 
for distributed applications. I think less then 5% of applications out 
there need to be distributed, hence I ask a question why do you need an 
EJB? (Does anyone deploy client side Java?).

Or even this: http://java.sun.com/products/ejb/index.html
What is the business case?
Is it:
"Enterprise JavaBeans servers reduce the complexity of developing 
middleware by providing automatic support for middleware services such 
as transactions, security, database connectivity, and more.
". Is this true, based on your experience with developing EJB? CMP with 
transactions, this comes in handy? Should I only use it when I need 
middleware? What is middleware? I must need it.

I think we all make our choices for our applications and what I chose 
may not be correct for your application.

/* Flame: How can I change the business requirements spec for this 
application so I could use message driven beans? (if you do not get it, 
don't worry */

I would use Action as just an application controler.
Maybe you can just do a FormBean as just a bean and do a DAO by puting a 
  on it for DAO. (And if you go Swing use the same FormBean, Swing 
knows RowSet).

Vic
the FormBean dude.

Stefan Frank wrote:

> Hi,
> 
> i'm not very fond of these Helper-Classes: Most of the time, they only add
> an additional Layer which just proxies calls to the SessionBeans: The
> benefit you get is mostly, that you can wrap all ejb-related errors inside
> the Helpers. This saves you some coding, but most of the time you want to
> react on a RemoteException in a different way the than on a finder
> Exception.
> 
> We code the EJB-Access driectly in the Actions and try to keep the Actions
> small by keeping most of the Code inside SessionBeans (which is a generally
> a good idea, as you can reuse this code in context's where Struts is not
> applicable, eg. with a Swing-Client). In order for this to work, it's a good
> idea, to use a
> SessionFacade(http://java.sun.com/blueprints/patterns/j2ee_patterns/session_
> facade/index.html) to avoid having to code against numerous ejb's in your
> action - in our experience, this is sufficient: A helper-class just doubles
> the Methods of the Facade.
> 
> Check out, if portability from an ejb-Architecture to a pure-jdbc
> Architecture is really a requirement, or if it even is possible: I'm not
> really sure, wether it pays to code independently of the j2ee-architecture,
> as it means to wrap most of the main-features (EntityBean, SessionBean, MDB,
> jndi and so on) - with applicationspecific classes that abstract out the
> functionality: I think in projects under high pressure you throw away all
> the benefits of j2ee with this approach.
> 
> So, by keeping the code in the actions small, we us Actions in a
> "Command"-way: which works quite nicely for us: As there is not so much code
> in the action, we don't have problems with writing new ones or changing the
> old ones.
> 
> hope this helps
> greetings
> stf
> 
> ---
> vierundsechzig.de
> friedensallee 7-9
> 22765 hamburg
> telefon +49 (040) 306033 -43
> telefax +49 (040) 3

AW: accessing EJB components from a Struts application?

[Stefan Frank]

Hi,

i'm not very fond of these Helper-Classes: Most of the time, they only add
an additional Layer which just proxies calls to the SessionBeans: The
benefit you get is mostly, that you can wrap all ejb-related errors inside
the Helpers. This saves you some coding, but most of the time you want to
react on a RemoteException in a different way the than on a finder
Exception.

We code the EJB-Access driectly in the Actions and try to keep the Actions
small by keeping most of the Code inside SessionBeans (which is a generally
a good idea, as you can reuse this code in context's where Struts is not
applicable, eg. with a Swing-Client). In order for this to work, it's a good
idea, to use a
SessionFacade(http://java.sun.com/blueprints/patterns/j2ee_patterns/session_
facade/index.html) to avoid having to code against numerous ejb's in your
action - in our experience, this is sufficient: A helper-class just doubles
the Methods of the Facade.

Check out, if portability from an ejb-Architecture to a pure-jdbc
Architecture is really a requirement, or if it even is possible: I'm not
really sure, wether it pays to code independently of the j2ee-architecture,
as it means to wrap most of the main-features (EntityBean, SessionBean, MDB,
jndi and so on) - with applicationspecific classes that abstract out the
functionality: I think in projects under high pressure you throw away all
the benefits of j2ee with this approach.

So, by keeping the code in the actions small, we us Actions in a
"Command"-way: which works quite nicely for us: As there is not so much code
in the action, we don't have problems with writing new ones or changing the
old ones.

hope this helps
greetings
stf

---
vierundsechzig.de
friedensallee 7-9
22765 hamburg
telefon +49 (040) 306033 -43
telefax +49 (040) 306033 -64

http://www.vierundsechzig.de
mailto:[EMAIL PROTECTED]







> -Ursprungliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 19. Dezember 2001 01:01
> An: Struts Users Mailing List
> Betreff: accessing EJB components from a Struts application?
>
>
>
> Hi all,
>
> after browsing the FAQ and searching the mailing list archive,
> I have not yet found a 'premium way' to go for EJB business logic
> integration into a Struts application.
>
> It's pretty clear that the EJB stuff should go into the action classes.
> I also saw hints that it might be useful to add another layer between
> the action classes and the entity/session beans in order to keep the
> action classes small and independent from the underlying business logic
> tier architecture.
>
> So the recommended architecture would be
>
> action class <-> ejb 'helper' class <-> EJB Session/Entity Bean
>
> which allows for e.g. replacing the EJB tier by direct JDBC
> database access without having to modify the action classes.
>
> Is the presented view correct/recommendable, or have I probably missed
> some important developments concerning the Struts<->EJB issue?
> Besides selected threads of this mailing list, are there any
> instructive resources/links regarding the topic?
>
> Regards,
>
> --
> Thomas Corte
> <[EMAIL PROTECTED]>
>
>
>
>
> --
> To unsubscribe, e-mail:

For additional commands, e-mail:



--
To unsubscribe, e-mail:   
For additional commands, e-mail: