Re: Architecture advice....

[Peter A. J. Pilgrim]

Greg Hess wrote:
> Hi,
> 
> I have designed our service layer using normal classes, I initialize the
> service layer on application start up and place them in the ServletContext.
> I have been looking at this strategy and considering using Static methods as
> well, as the only state in these classes is the jdbc driver and base data
> source. My persistency layer implementation handles concurrency issues and I
> don't think I would run into any issues having the application distributed
> to more than one server.
> 
> Wish I could offer more help, but I am in the same boat.
> 
> Greg
> 

In the past I have build a persistence layer interface or an abstract class
and then extended with a concrete implementation that talks to a database.

interface PersistenceLayer {
public OrderDetail  processOrder()
...
}

class OraclePersistenceLayer extends PersistenceLayer {
public OrderDetail  processOrder()
...
}

class SybasePersistenceLayer extends PersistenceLayer {
public OrderDetail  processOrder()
...
}

I used a factory to connect to right persistence layer at start up time.

The bad thing thing I built or we built up huge Java source
class 1000s of lines long over time.
Now I would divide up the persistence layer using
a mini BusinessDelegate patterns. I would refactor parts or factor
the application into essential delegate parts. This helps reduce
expensive RMI throughput in a EJB application. Have a look a Floyd
Marinescu EJB patterns for more ideas

Have a look Chuck Cavaness book has a IStoreFrontSecurity interface
for user login. I would do the same with many interface for each
part of the business application.

ICustomerDetails

IProcessOrders

IShipping

IConfirmation


-- 
Peter Pilgrim +-\ +-+++++
Java Technologist | | | ||||| 'n' Shine
   |  O  | | ||  --+| ---+
 /\| ._  / | | \  \ ||
/  \   | | \ \ | |+--  || ---+ A new day
   /_  _\  "Up"| | | | | ||||| is coming
 ||+-+ +-+ +-+++++
http://www.xenonsoft.demon.co.uk/"; />


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

Re: Architecture advice....

[Michael Delamere]

Thanks Graham,

I think I will stick with your advice.  It has certainly convinced me; now I
just have to convince the guys at work :-) !

Regards,

Michael


- Original Message -
From: "David Graham" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 30, 2002 12:02 AM
Subject: Re: Architecture advice


>
> Naming services is certainly a great way to do configurable factory
methods
> but I think what you want is still the facade.
>
> >From: "Michael Delamere" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >Subject: Re: Architecture advice
> >Date: Tue, 30 Jul 2002 00:04:48 +0200
> >
> >near bottom :-)
> >
> >- Original Message -
> >From: "Eddie Bush" <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >Sent: Monday, July 29, 2002 11:37 PM
> >Subject: Re: Architecture advice
> >
> >
> > > David Graham wrote:
> > >
> > > > Now we're onto "how to design a factory method" :-).  So if you have
> > > > many different service objects you could just compose your
> > > > ServiceFacade of these objects and publish their interfaces.  This
is
> > > > the true use of the facade pattern so your code doesn't need to know
> > > > about all of the objects behind the facade.  You would do this like
> >so:
> > > > ServiceFacade{
> > > > private SpecialServiceClass special;
> > > >
> > > > public doService(){
> > > >   special.doService(); //delegate call to internal service object
> > > > }
> > > > }
> > > >
> > > > Notice that all interaction with SpecialServiceClass is done through
> > > > the facade leaving you free to rip out SpecialServiceClass in the
> > > > future and replace it with something else.
> > > >
> > > > If you really want to do the factory thing you have 2 options:
> > > > 1.  A factory method for each service class
> > > >  public SpecialServiceClass createSpecialServiceClass()...
> > > >  public SpecialService2 createSpecialService2()...
> > > >
> > > > 2.  One factory method with parameter telling which type of service
> > > > class to return.  public Object create("SpecialServiceClass")
> > > >
> > > > I would go for the facade pattern so most of your code only knows
> > > > about the facade and not the implementation classes.
> > > >
> > > > I hope this helps.
> > >
> > > Why not name your services.  Then, use a properties file to figure out
> > > what the actual class is.  If all you ever programmed to was an
> > > interface, you could switch implementations out very easily.  Just
edit
> > > the properties file and restart you app!
> > >
> > > Ex:
> > >
> > > services.serviceName=com.mycompany.services.ServiceClass1
> > >
> > > ... then ...
> > >
> > > public ServiceInterface create("serviceName")
> > >
> >
> >wow, nice one Eddie.  The discussion is getting better and better!
Christ,
> >there is so much to look up in order to implement your ideas (which I
think
> >are great!).
> >
> >Regards,
> >
> >Michael
> >
> >
> >
> > > U - I believe that addresses any concerns you may have, but I sure
> > > welcome suggestions! ;-)
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> > >
> >
> >
> >--
> >To unsubscribe, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> >
>
>
>
>
> _
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Architecture advice....

[Michael Delamere]

- Original Message -
From: "David Graham" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 11:51 PM
Subject: Re: Architecture advice


> Sorry Michael, it seems that I've confused the issue with this factory
> method business.  Forget everything about the factory, just make one
facade
> class (call it ServiceFacade) that hides your other service objects (which
I
> showed in the last post) and has this code to get the singleton instance:
>
> public class ServiceFacade{
> private ServiceFacade instance = new ServiceFacade();
>
> // protect constructor so clients must go through getInstance()
> protected ServiceFacade(){
>
> }
>
> // get the singleton instance of the facade
> public static ServiceFacade getInstance(){
>   return instance;
> }
> ...
>
> That should be what you're looking for.  Now, in case you care about this
> other factory stuff you can look in the Design Patterns book by Erich
Gamma
> et al. for these patterns "Abstract Factory", "Factory Method", and
> "Facade".
>

Thanks,

now I _really_ do understand what you are getting at.  That´s the way I
think.  Incidentally, I have had a design pattern book open all along whilst
reading everybodies replies and am well aware of what is being discussed :-)

Thank you very much!

Regards,

Michael



> >see below:
> >
> >----- Original Message -
> >From: "David Graham" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Monday, July 29, 2002 11:11 PM
> >Subject: Re: Architecture advice
> >
> >
> > > Now we're onto "how to design a factory method" :-).  So if you have
> >many
> > > different service objects you could just compose your ServiceFacade of
> >these
> > > objects and publish their interfaces.  This is the true use of the
> >facade
> > > pattern so your code doesn't need to know about all of the objects
> >behind
> > > the facade.  You would do this like so:
> > > ServiceFacade{
> > > private SpecialServiceClass special;
> > >
> > > public doService(){
> > >special.doService(); //delegate call to internal service object
> > > }
> > > }
> >
> >That was actually our general idea; i.e. to use a kind of facade you
> >describe here.  The problem we were faced with was how we would implement
> >it.  The two major ideas were to use static methods or normal classes but
> >creating many instances didn´t seem like the solution.  That´s why I
quite
> >liked your singleton idea.
> >You also suggested using some kind of a factory which would be something
> >like ServiceFactory.getInstance();  I thought that this would be a way to
> >check if the instance already existed or not, and return one accordingly.
> >Are you now talking about the facade pattern without the singleton
concept?
> >
> >
> >
> > >
> > > Notice that all interaction with SpecialServiceClass is done through
the
> > > facade leaving you free to rip out SpecialServiceClass in the future
and
> > > replace it with something else.
> > >
> >Yes.  I like it :-)
> >
> > > If you really want to do the factory thing you have 2 options:
> > > 1.  A factory method for each service class
> > >   public SpecialServiceClass createSpecialServiceClass()...
> > >   public SpecialService2 createSpecialService2()...
> > >
> > > 2.  One factory method with parameter telling which type of service
> >class
> >to
> > > return.  public Object create("SpecialServiceClass")
> > >
> > > I would go for the facade pattern so most of your code only knows
about
> >the
> > > facade and not the implementation classes.
> >
> >Just to be really ackward:  what if the facade consisted of singletons
> >which
> >were returned by a factory?  Would that be an option or is that not
ideal?
> >Sorry but I´m just trying to get the picture and you started with the
idea
> >:-).
> >
> > >
> > > I hope this helps.
> > >
> >
> >Yes, thank you very much.  I think this will be the last set of questions
I
> >have for you.
> >Thanks for your time.
> >
> >Regards,
> >
> >Michael
> >
> > >
> > > >Graham,
> > > >
> > > >there´s just one more question that I have concerning your method.
> > > >
> > > >Obviously there will be many different objects which make up the
> >service
> > > >f

Re: Architecture advice....

[David Graham]

Naming services is certainly a great way to do configurable factory methods 
but I think what you want is still the facade.

>From: "Michael Delamere" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Subject: Re: Architecture advice
>Date: Tue, 30 Jul 2002 00:04:48 +0200
>
>near bottom :-)
>
>- Original Message -
>From: "Eddie Bush" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Sent: Monday, July 29, 2002 11:37 PM
>Subject: Re: Architecture advice
>
>
> > David Graham wrote:
> >
> > > Now we're onto "how to design a factory method" :-).  So if you have
> > > many different service objects you could just compose your
> > > ServiceFacade of these objects and publish their interfaces.  This is
> > > the true use of the facade pattern so your code doesn't need to know
> > > about all of the objects behind the facade.  You would do this like 
>so:
> > > ServiceFacade{
> > > private SpecialServiceClass special;
> > >
> > > public doService(){
> > >   special.doService(); //delegate call to internal service object
> > > }
> > > }
> > >
> > > Notice that all interaction with SpecialServiceClass is done through
> > > the facade leaving you free to rip out SpecialServiceClass in the
> > > future and replace it with something else.
> > >
> > > If you really want to do the factory thing you have 2 options:
> > > 1.  A factory method for each service class
> > >  public SpecialServiceClass createSpecialServiceClass()...
> > >  public SpecialService2 createSpecialService2()...
> > >
> > > 2.  One factory method with parameter telling which type of service
> > > class to return.  public Object create("SpecialServiceClass")
> > >
> > > I would go for the facade pattern so most of your code only knows
> > > about the facade and not the implementation classes.
> > >
> > > I hope this helps.
> >
> > Why not name your services.  Then, use a properties file to figure out
> > what the actual class is.  If all you ever programmed to was an
> > interface, you could switch implementations out very easily.  Just edit
> > the properties file and restart you app!
> >
> > Ex:
> >
> > services.serviceName=com.mycompany.services.ServiceClass1
> >
> > ... then ...
> >
> > public ServiceInterface create("serviceName")
> >
>
>wow, nice one Eddie.  The discussion is getting better and better!  Christ,
>there is so much to look up in order to implement your ideas (which I think
>are great!).
>
>Regards,
>
>Michael
>
>
>
> > U - I believe that addresses any concerns you may have, but I sure
> > welcome suggestions! ;-)
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
> >
>
>
>--
>To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>
>




_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Architecture advice....

[Michael Delamere]

near bottom :-)

- Original Message -
From: "Eddie Bush" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 11:37 PM
Subject: Re: Architecture advice


> David Graham wrote:
>
> > Now we're onto "how to design a factory method" :-).  So if you have
> > many different service objects you could just compose your
> > ServiceFacade of these objects and publish their interfaces.  This is
> > the true use of the facade pattern so your code doesn't need to know
> > about all of the objects behind the facade.  You would do this like so:
> > ServiceFacade{
> > private SpecialServiceClass special;
> >
> > public doService(){
> >   special.doService(); //delegate call to internal service object
> > }
> > }
> >
> > Notice that all interaction with SpecialServiceClass is done through
> > the facade leaving you free to rip out SpecialServiceClass in the
> > future and replace it with something else.
> >
> > If you really want to do the factory thing you have 2 options:
> > 1.  A factory method for each service class
> >  public SpecialServiceClass createSpecialServiceClass()...
> >  public SpecialService2 createSpecialService2()...
> >
> > 2.  One factory method with parameter telling which type of service
> > class to return.  public Object create("SpecialServiceClass")
> >
> > I would go for the facade pattern so most of your code only knows
> > about the facade and not the implementation classes.
> >
> > I hope this helps.
>
> Why not name your services.  Then, use a properties file to figure out
> what the actual class is.  If all you ever programmed to was an
> interface, you could switch implementations out very easily.  Just edit
> the properties file and restart you app!
>
> Ex:
>
> services.serviceName=com.mycompany.services.ServiceClass1
>
> ... then ...
>
> public ServiceInterface create("serviceName")
>

wow, nice one Eddie.  The discussion is getting better and better!  Christ,
there is so much to look up in order to implement your ideas (which I think
are great!).

Regards,

Michael



> U - I believe that addresses any concerns you may have, but I sure
> welcome suggestions! ;-)
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Architecture advice....

[David Graham]

Sorry Michael, it seems that I've confused the issue with this factory 
method business.  Forget everything about the factory, just make one facade 
class (call it ServiceFacade) that hides your other service objects (which I 
showed in the last post) and has this code to get the singleton instance:

public class ServiceFacade{
private ServiceFacade instance = new ServiceFacade();

// protect constructor so clients must go through getInstance()
protected ServiceFacade(){

}

// get the singleton instance of the facade
public static ServiceFacade getInstance(){
  return instance;
}
...

That should be what you're looking for.  Now, in case you care about this 
other factory stuff you can look in the Design Patterns book by Erich Gamma 
et al. for these patterns "Abstract Factory", "Factory Method", and 
"Facade".

>see below:
>
>- Original Message -
>From: "David Graham" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Monday, July 29, 2002 11:11 PM
>Subject: Re: Architecture advice
>
>
> > Now we're onto "how to design a factory method" :-).  So if you have 
>many
> > different service objects you could just compose your ServiceFacade of
>these
> > objects and publish their interfaces.  This is the true use of the 
>facade
> > pattern so your code doesn't need to know about all of the objects 
>behind
> > the facade.  You would do this like so:
> > ServiceFacade{
> > private SpecialServiceClass special;
> >
> > public doService(){
> >special.doService(); //delegate call to internal service object
> > }
> > }
>
>That was actually our general idea; i.e. to use a kind of facade you
>describe here.  The problem we were faced with was how we would implement
>it.  The two major ideas were to use static methods or normal classes but
>creating many instances didn´t seem like the solution.  That´s why I quite
>liked your singleton idea.
>You also suggested using some kind of a factory which would be something
>like ServiceFactory.getInstance();  I thought that this would be a way to
>check if the instance already existed or not, and return one accordingly.
>Are you now talking about the facade pattern without the singleton concept?
>
>
>
> >
> > Notice that all interaction with SpecialServiceClass is done through the
> > facade leaving you free to rip out SpecialServiceClass in the future and
> > replace it with something else.
> >
>Yes.  I like it :-)
>
> > If you really want to do the factory thing you have 2 options:
> > 1.  A factory method for each service class
> >   public SpecialServiceClass createSpecialServiceClass()...
> >   public SpecialService2 createSpecialService2()...
> >
> > 2.  One factory method with parameter telling which type of service 
>class
>to
> > return.  public Object create("SpecialServiceClass")
> >
> > I would go for the facade pattern so most of your code only knows about
>the
> > facade and not the implementation classes.
>
>Just to be really ackward:  what if the facade consisted of singletons 
>which
>were returned by a factory?  Would that be an option or is that not ideal?
>Sorry but I´m just trying to get the picture and you started with the idea
>:-).
>
> >
> > I hope this helps.
> >
>
>Yes, thank you very much.  I think this will be the last set of questions I
>have for you.
>Thanks for your time.
>
>Regards,
>
>Michael
>
> >
> > >Graham,
> > >
> > >there´s just one more question that I have concerning your method.
> > >
> > >Obviously there will be many different objects which make up the 
>service
> > >facade.  Does that mean that one has a "factory" for each object; i.e.
>each
> > >"factory" returns it´s type of instance,  or do you pass a parameter to
>the
> > >"factory" and return an instance accordingly?
> > >
> > >Thanks for your time.
> > >
> > >Michael
> > >
> > >
> > >- Original Message -
> > >From: "David Graham" <[EMAIL PROTECTED]>
> > >To: <[EMAIL PROTECTED]>
> > >Sent: Monday, July 29, 2002 9:59 PM
> > >Subject: Re: Architecture advice
> > >
> > >
> > > > I chose not to implement a session facade in my current project but
>have
> > > > done it this way in other applications.  I really dislike bunches of
> > >static
> > > > method calls so this solution works nicely.  I mispoke when I
>mentioned
> > >th

Re: Architecture advice....

[Michael Delamere]

see below:

- Original Message -
From: "David Graham" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 11:11 PM
Subject: Re: Architecture advice


> Now we're onto "how to design a factory method" :-).  So if you have many
> different service objects you could just compose your ServiceFacade of
these
> objects and publish their interfaces.  This is the true use of the facade
> pattern so your code doesn't need to know about all of the objects behind
> the facade.  You would do this like so:
> ServiceFacade{
> private SpecialServiceClass special;
>
> public doService(){
>special.doService(); //delegate call to internal service object
> }
> }

That was actually our general idea; i.e. to use a kind of facade you
describe here.  The problem we were faced with was how we would implement
it.  The two major ideas were to use static methods or normal classes but
creating many instances didn´t seem like the solution.  That´s why I quite
liked your singleton idea.
You also suggested using some kind of a factory which would be something
like ServiceFactory.getInstance();  I thought that this would be a way to
check if the instance already existed or not, and return one accordingly.
Are you now talking about the facade pattern without the singleton concept?



>
> Notice that all interaction with SpecialServiceClass is done through the
> facade leaving you free to rip out SpecialServiceClass in the future and
> replace it with something else.
>
Yes.  I like it :-)

> If you really want to do the factory thing you have 2 options:
> 1.  A factory method for each service class
>   public SpecialServiceClass createSpecialServiceClass()...
>   public SpecialService2 createSpecialService2()...
>
> 2.  One factory method with parameter telling which type of service class
to
> return.  public Object create("SpecialServiceClass")
>
> I would go for the facade pattern so most of your code only knows about
the
> facade and not the implementation classes.

Just to be really ackward:  what if the facade consisted of singletons which
were returned by a factory?  Would that be an option or is that not ideal?
Sorry but I´m just trying to get the picture and you started with the idea
:-).

>
> I hope this helps.
>

Yes, thank you very much.  I think this will be the last set of questions I
have for you.
Thanks for your time.

Regards,

Michael

>
> >Graham,
> >
> >there´s just one more question that I have concerning your method.
> >
> >Obviously there will be many different objects which make up the service
> >facade.  Does that mean that one has a "factory" for each object; i.e.
each
> >"factory" returns it´s type of instance,  or do you pass a parameter to
the
> >"factory" and return an instance accordingly?
> >
> >Thanks for your time.
> >
> >Michael
> >
> >
> >- Original Message -
> >From: "David Graham" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Monday, July 29, 2002 9:59 PM
> >Subject: Re: Architecture advice
> >
> >
> > > I chose not to implement a session facade in my current project but
have
> > > done it this way in other applications.  I really dislike bunches of
> >static
> > > method calls so this solution works nicely.  I mispoke when I
mentioned
> >the
> > > factory method; it would only create the singleton instance on the
first
> > > request, after that it would always return that instance.  You would
use
> > > your service layer like this:
> > >
> > > // returns same instance every time
> > > ServiceFacade sf = ServiceFacade.getInstance();
> > > sf.doSomeServiceMethod();
> > >
> > > instead of
> > >
> > > ServiceFacade.doSomeServiceMethod();
> > >
> > > Sure, it's one more line of code but it is a cleaner design to me.
> > >
> > > >Yep, that´s exactly what it sounds like :-).  I would like to
implement
> > > >something similar to the session facade used in EJB environments.
> > > >
> > > >I like the singleton idea.  Have you implemented this yourself.  What
> >are
> > > >your experiences in doing it this way?
> > > >I take it that the factory would do the job of making sure that only
> >the
> > > >existing instance is returned and if gone, create a new one.
> > > >
> > > >Have I got that right?  I certainly like the idea.
> > > >
> > > >Regards,
> > > >
> > > >Michael
> > > >
> >

Re: Architecture advice....

[Eddie Bush]

David Graham wrote:

> Now we're onto "how to design a factory method" :-).  So if you have 
> many different service objects you could just compose your 
> ServiceFacade of these objects and publish their interfaces.  This is 
> the true use of the facade pattern so your code doesn't need to know 
> about all of the objects behind the facade.  You would do this like so:
> ServiceFacade{
> private SpecialServiceClass special;
>
> public doService(){
>   special.doService(); //delegate call to internal service object
> }
> }
>
> Notice that all interaction with SpecialServiceClass is done through 
> the facade leaving you free to rip out SpecialServiceClass in the 
> future and replace it with something else.
>
> If you really want to do the factory thing you have 2 options:
> 1.  A factory method for each service class
>  public SpecialServiceClass createSpecialServiceClass()...
>  public SpecialService2 createSpecialService2()...
>
> 2.  One factory method with parameter telling which type of service 
> class to return.  public Object create("SpecialServiceClass")
>
> I would go for the facade pattern so most of your code only knows 
> about the facade and not the implementation classes.
>
> I hope this helps. 

Why not name your services.  Then, use a properties file to figure out 
what the actual class is.  If all you ever programmed to was an 
interface, you could switch implementations out very easily.  Just edit 
the properties file and restart you app!

Ex:

services.serviceName=com.mycompany.services.ServiceClass1

... then ...

public ServiceInterface create("serviceName")

U - I believe that addresses any concerns you may have, but I sure 
welcome suggestions! ;-)



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

RE: Architecture advice....

[Chappell, Simon P]

Craig,

You raise good points, but the whole point of our API class was to enforce a 
"firebreak" between the Controller/View and the Model. In the body of the application 
we have no knowledge of where requests originated. We receive a Request object 
(defined in the main app, that has no ties to Struts or the servlet API) and we return 
a Reply object. This gives us zero servlet or struts code in the main body of the 
application, while our View/Controller only knows about the API and the request/reply 
objects.

So far this is working very well and I am very pleased with it.

Simon

-
Simon P. Chappell [EMAIL PROTECTED]
Java Programming Specialist  www.landsend.com
Lands' End, Inc.   (608) 935-4526


>-Original Message-
>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
>Sent: Monday, July 29, 2002 4:10 PM
>To: Struts Users Mailing List
>Subject: RE: Architecture advice
>
>
>
>
>On Mon, 29 Jul 2002, Chappell, Simon P wrote:
>
>> Date: Mon, 29 Jul 2002 14:06:03 -0500
>> From: "Chappell, Simon P" <[EMAIL PROTECTED]>
>> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>> To: Struts Users Mailing List <[EMAIL PROTECTED]>
>> Subject: RE: Architecture advice
>>
>> Well, what we did to seperate Struts from the backend was to 
>implement
>> what we called a "Firebreak". We created an abstract Java 
>class called
>> API.java. It's whole purpose in life was to be the application API to
>> the model component. This would enable us to utilise 
>alternative views
>> and/or controllers if our needs ever took us in that direction.
>>
>
>Design pattern books call this the Data Access Object (DAO) 
>pattern.  It's
>quite commonly implemented.  The best scenaro is where your DAO object
>returns JavaBeans that represent the underlying data (like 
>customers and
>orders), instead of just providing pass-through access to the 
>connection
>pool.
>
>One of the big things I like about it is that the actual 
>technology used
>to store the persistent data (and any changes to it you make later) are
>hidden from the business logic that uses the data.
>
>For example, you might start out by embedding JDBC calls in your DAO to
>load and store the data.  Later on, your DBA might split one table into
>two (or combine two into one) to improve efficiency -- you can 
>tweak the
>JDBC calls inside your DAO and never touch the business logic that uses
>it.  Later on, you might find it necessary to switch to EJBs for
>scalability -- as long as you're not adding properties to the data
>objects, these kinds of changes are transparent.
>
>> All functionality in the application is accessable through static
>> methods in the API class. This is nice for us, we removed 
>all processing
>> logic from the actions and put it in the main application 
>space. Now our
>> actions concentrate on ActionForms and calling the API methods.
>>
>
>Servlet context attributes can be thought of like "per-webapp statics",
>because they have exactly the same memory impact.  However, 
>they provide
>slightly more flexibility because you can subtitute different
>implementations of the same API interface more easily.  The negative is
>that you have to have a reference to the ServletContext to acquire your
>DAO object.
>
>The standard J2EE approach to that is to use JNDI resources - they act
>like static variables in that you can gain access to them directly,
>without giving up the flexibility of using different 
>implementations that
>you can do with servlet context resources.
>
>> To further the break between view and logic, we use Request and Reply
>> objects to carry the data on the calls into and the return 
>values back
>> from the API.
>>
>
>Sounds a lot like another pattern, variously called "value objects" or
>"data transfer objects".
>
>> Simon
>
>
>Craig
>
>
>--
>To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Architecture advice....

[David Graham]

Now we're onto "how to design a factory method" :-).  So if you have many 
different service objects you could just compose your ServiceFacade of these 
objects and publish their interfaces.  This is the true use of the facade 
pattern so your code doesn't need to know about all of the objects behind 
the facade.  You would do this like so:
ServiceFacade{
private SpecialServiceClass special;

public doService(){
   special.doService(); //delegate call to internal service object
}
}

Notice that all interaction with SpecialServiceClass is done through the 
facade leaving you free to rip out SpecialServiceClass in the future and 
replace it with something else.

If you really want to do the factory thing you have 2 options:
1.  A factory method for each service class
  public SpecialServiceClass createSpecialServiceClass()...
  public SpecialService2 createSpecialService2()...

2.  One factory method with parameter telling which type of service class to 
return.  public Object create("SpecialServiceClass")

I would go for the facade pattern so most of your code only knows about the 
facade and not the implementation classes.

I hope this helps.


>Graham,
>
>there´s just one more question that I have concerning your method.
>
>Obviously there will be many different objects which make up the service
>facade.  Does that mean that one has a "factory" for each object; i.e. each
>"factory" returns it´s type of instance,  or do you pass a parameter to the
>"factory" and return an instance accordingly?
>
>Thanks for your time.
>
>Michael
>
>
>- Original Message -
>From: "David Graham" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Monday, July 29, 2002 9:59 PM
>Subject: Re: Architecture advice
>
>
> > I chose not to implement a session facade in my current project but have
> > done it this way in other applications.  I really dislike bunches of
>static
> > method calls so this solution works nicely.  I mispoke when I mentioned
>the
> > factory method; it would only create the singleton instance on the first
> > request, after that it would always return that instance.  You would use
> > your service layer like this:
> >
> > // returns same instance every time
> > ServiceFacade sf = ServiceFacade.getInstance();
> > sf.doSomeServiceMethod();
> >
> > instead of
> >
> > ServiceFacade.doSomeServiceMethod();
> >
> > Sure, it's one more line of code but it is a cleaner design to me.
> >
> > >Yep, that´s exactly what it sounds like :-).  I would like to implement
> > >something similar to the session facade used in EJB environments.
> > >
> > >I like the singleton idea.  Have you implemented this yourself.  What 
>are
> > >your experiences in doing it this way?
> > >I take it that the factory would do the job of making sure that only 
>the
> > >existing instance is returned and if gone, create a new one.
> > >
> > >Have I got that right?  I certainly like the idea.
> > >
> > >Regards,
> > >
> > >Michael
> > >
> > >
> > >- Original Message -
> > >From: "David Graham" <[EMAIL PROTECTED]>
> > >To: <[EMAIL PROTECTED]>
> > >Sent: Monday, July 29, 2002 8:59 PM
> > >Subject: Re: Architecture advice
> > >
> > >
> > > > Sounds like a "how to implement a facade" problem.  I would make 
>your
> > > > service layer a singleton with a factory method to retrieve the
> > >instance.
> > > > That way you avoid the static method calls and maintain the 
>symantics
>of
> > > > passing messages to objects (the singleton).  You also avoid 
>creating
>a
> > >new
> > > > object everytime you want to use a service method.
> > > >
> > > >
> > > > >Hi,
> > > > >
> > > > >I had a discussion at work today concerning the best way to 
>implement
> > >our
> > > > >application.  A very
> > > > >basic discription of the framework would be the following:
> > > > >
> > > > >1. Struts + Velocity for the view
> > > > >2. Struts ActionServlets for the controller
> > > > >3. Service layer/methods for querying persistence layer
> > > > >4. OJB persistence layer
> > > > >
> > > > >The main debate was actually about what the service layer would 
>look
> > >like.
> > > > >We thought about the following options

RE: Architecture advice....

[Chappell, Simon P]

Nicely explained. That's what I should have said! :-) And, for the record, we have no 
synchronisation anywhere in our API.

Simon

>-Original Message-
>From: Kulp, Arian [mailto:[EMAIL PROTECTED]]
>Sent: Monday, July 29, 2002 3:58 PM
>To: 'Struts Users Mailing List'
>Subject: RE: Architecture advice
>
>
>It doesn't matter that all calls go through the same method 
>since each would
>be within the context of the calling thread.  In other words, 
>each caller
>(servlet connection) is in a thread, so therefore the static 
>call is made
>from each thread (as opposed to all callers funneling through 
>literally one
>call -- remember just because the call is static doesn't 
>prevent it from
>being called from separate threads).  You would have a 
>bottleneck if it is
>synchronized or contains synchronized sections, but otherwise you'll be
>fine.
>
>-Arian
>
>> -Original Message-
>> From:Michael Delamere [SMTP:[EMAIL PROTECTED]]
>> Sent:Monday, July 29, 2002 2:30 PM
>> To:  Struts Users Mailing List
>> Subject: Re: Architecture advice
>> 
>> Thanks to you also!
>> 
>> It´s a great help to hear other peoples experiences.  What 
>we were worried
>> about is that all calls for a particular job would go via 
>the one and only
>> static method; i.e. thought it might become a bit of a 
>bottleneck.  Did
>> you
>> experience anything along those lines?
>> 
>> Thanks for your time.
>> 
>> Regards,
>> 
>> Michael
>> 
>> 
>> - Original Message -
>> From: "Chappell, Simon P" <[EMAIL PROTECTED]>
>> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>> Sent: Monday, July 29, 2002 9:06 PM
>> Subject: RE: Architecture advice
>> 
>> 
>> > Well, what we did to seperate Struts from the backend was 
>to implement
>> what we called a "Firebreak". We created an abstract Java 
>class called
>> API.java. It's whole purpose in life was to be the 
>application API to the
>> model component. This would enable us to utilise  
>alternative views and/or
>> controllers if our needs ever took us in that direction.
>> >
>> > All functionality in the application is accessable through static
>> methods
>> in the API class. This is nice for us, we removed all 
>processing logic
>> from
>> the actions and put it in the main application space. Now our actions
>> concentrate on ActionForms and calling the API methods.
>> >
>> > To further the break between view and logic, we use 
>Request and Reply
>> objects to carry the data on the calls into and the return 
>values back
>> from
>> the API.
>> >
>> > Simon
>> >
>> > -
>> > Simon P. Chappell [EMAIL PROTECTED]
>> > Java Programming Specialist  www.landsend.com
>> > Lands' End, Inc.   (608) 935-4526
>> >
>> >
>> > >-Original Message-
>> > >From: Michael Delamere [mailto:[EMAIL PROTECTED]]
>> > >Sent: Monday, July 29, 2002 1:15 PM
>> > >To: Struts Users Mailing List
>> > >Subject: Architecture advice
>> > >
>> > >
>> > >Hi,
>> > >
>> > >I had a discussion at work today concerning the best way to
>> > >implement our
>> > >application.  A very
>> > >basic discription of the framework would be the following:
>> > >
>> > >1. Struts + Velocity for the view
>> > >2. Struts ActionServlets for the controller
>> > >3. Service layer/methods for querying persistence layer
>> > >4. OJB persistence layer
>> > >
>> > >The main debate was actually about what the service layer
>> > >would look like.
>> > >We thought about the following options:
>> > >
>> > >1. The service layer consists of static methods
>> > >2. The service layer would consists of normal classes
>> > >3. The service layer could consist of servlets
>> > >
>> > >The idea is that (this is nothing new of course) the service
>> > >layer would
>> > >purely have methods such as addToShoppingBasket() or
>> > >checkLogin(); basically
>> > >service methods which carry out the communication with the
>> > >p

RE: Architecture advice....

[Craig R. McClanahan]

On Mon, 29 Jul 2002, Chappell, Simon P wrote:

> Date: Mon, 29 Jul 2002 14:06:03 -0500
> From: "Chappell, Simon P" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Architecture advice
>
> Well, what we did to seperate Struts from the backend was to implement
> what we called a "Firebreak". We created an abstract Java class called
> API.java. It's whole purpose in life was to be the application API to
> the model component. This would enable us to utilise alternative views
> and/or controllers if our needs ever took us in that direction.
>

Design pattern books call this the Data Access Object (DAO) pattern.  It's
quite commonly implemented.  The best scenaro is where your DAO object
returns JavaBeans that represent the underlying data (like customers and
orders), instead of just providing pass-through access to the connection
pool.

One of the big things I like about it is that the actual technology used
to store the persistent data (and any changes to it you make later) are
hidden from the business logic that uses the data.

For example, you might start out by embedding JDBC calls in your DAO to
load and store the data.  Later on, your DBA might split one table into
two (or combine two into one) to improve efficiency -- you can tweak the
JDBC calls inside your DAO and never touch the business logic that uses
it.  Later on, you might find it necessary to switch to EJBs for
scalability -- as long as you're not adding properties to the data
objects, these kinds of changes are transparent.

> All functionality in the application is accessable through static
> methods in the API class. This is nice for us, we removed all processing
> logic from the actions and put it in the main application space. Now our
> actions concentrate on ActionForms and calling the API methods.
>

Servlet context attributes can be thought of like "per-webapp statics",
because they have exactly the same memory impact.  However, they provide
slightly more flexibility because you can subtitute different
implementations of the same API interface more easily.  The negative is
that you have to have a reference to the ServletContext to acquire your
DAO object.

The standard J2EE approach to that is to use JNDI resources - they act
like static variables in that you can gain access to them directly,
without giving up the flexibility of using different implementations that
you can do with servlet context resources.

> To further the break between view and logic, we use Request and Reply
> objects to carry the data on the calls into and the return values back
> from the API.
>

Sounds a lot like another pattern, variously called "value objects" or
"data transfer objects".

> Simon


Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Architecture advice....

[Michael Delamere]

ah... thanks for that.  Certainly helps me get a better picture of the whole
process!

Regards,

Michael


- Original Message -
From: "Kulp, Arian" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 10:58 PM
Subject: RE: Architecture advice


> It doesn't matter that all calls go through the same method since each
would
> be within the context of the calling thread.  In other words, each caller
> (servlet connection) is in a thread, so therefore the static call is made
> from each thread (as opposed to all callers funneling through literally
one
> call -- remember just because the call is static doesn't prevent it from
> being called from separate threads).  You would have a bottleneck if it is
> synchronized or contains synchronized sections, but otherwise you'll be
> fine.
>
> -Arian
>
> > -Original Message-
> > From: Michael Delamere [SMTP:[EMAIL PROTECTED]]
> > Sent: Monday, July 29, 2002 2:30 PM
> > To: Struts Users Mailing List
> > Subject: Re: Architecture advice
> >
> > Thanks to you also!
> >
> > It´s a great help to hear other peoples experiences.  What we were
worried
> > about is that all calls for a particular job would go via the one and
only
> > static method; i.e. thought it might become a bit of a bottleneck.  Did
> > you
> > experience anything along those lines?
> >
> > Thanks for your time.
> >
> > Regards,
> >
> > Michael
> >
> >
> > - Original Message -
> > From: "Chappell, Simon P" <[EMAIL PROTECTED]>
> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > Sent: Monday, July 29, 2002 9:06 PM
> > Subject: RE: Architecture advice
> >
> >
> > > Well, what we did to seperate Struts from the backend was to implement
> > what we called a "Firebreak". We created an abstract Java class called
> > API.java. It's whole purpose in life was to be the application API to
the
> > model component. This would enable us to utilise  alternative views
and/or
> > controllers if our needs ever took us in that direction.
> > >
> > > All functionality in the application is accessable through static
> > methods
> > in the API class. This is nice for us, we removed all processing logic
> > from
> > the actions and put it in the main application space. Now our actions
> > concentrate on ActionForms and calling the API methods.
> > >
> > > To further the break between view and logic, we use Request and Reply
> > objects to carry the data on the calls into and the return values back
> > from
> > the API.
> > >
> > > Simon
> > >
> > > -
> > > Simon P. Chappell [EMAIL PROTECTED]
> > > Java Programming Specialist  www.landsend.com
> > > Lands' End, Inc.   (608) 935-4526
> > >
> > >
> > > >-Original Message-
> > > >From: Michael Delamere [mailto:[EMAIL PROTECTED]]
> > > >Sent: Monday, July 29, 2002 1:15 PM
> > > >To: Struts Users Mailing List
> > > >Subject: Architecture advice
> > > >
> > > >
> > > >Hi,
> > > >
> > > >I had a discussion at work today concerning the best way to
> > > >implement our
> > > >application.  A very
> > > >basic discription of the framework would be the following:
> > > >
> > > >1. Struts + Velocity for the view
> > > >2. Struts ActionServlets for the controller
> > > >3. Service layer/methods for querying persistence layer
> > > >4. OJB persistence layer
> > > >
> > > >The main debate was actually about what the service layer
> > > >would look like.
> > > >We thought about the following options:
> > > >
> > > >1. The service layer consists of static methods
> > > >2. The service layer would consists of normal classes
> > > >3. The service layer could consist of servlets
> > > >
> > > >The idea is that (this is nothing new of course) the service
> > > >layer would
> > > >purely have methods such as addToShoppingBasket() or
> > > >checkLogin(); basically
> > > >service methods which carry out the communication with the
> > > >persistense layer
> > > >and

RE: Architecture advice....

[Kulp, Arian]

It doesn't matter that all calls go through the same method since each would
be within the context of the calling thread.  In other words, each caller
(servlet connection) is in a thread, so therefore the static call is made
from each thread (as opposed to all callers funneling through literally one
call -- remember just because the call is static doesn't prevent it from
being called from separate threads).  You would have a bottleneck if it is
synchronized or contains synchronized sections, but otherwise you'll be
fine.

-Arian

> -Original Message-
> From: Michael Delamere [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, July 29, 2002 2:30 PM
> To:   Struts Users Mailing List
> Subject:  Re: Architecture advice
> 
> Thanks to you also!
> 
> It´s a great help to hear other peoples experiences.  What we were worried
> about is that all calls for a particular job would go via the one and only
> static method; i.e. thought it might become a bit of a bottleneck.  Did
> you
> experience anything along those lines?
> 
> Thanks for your time.
> 
> Regards,
> 
> Michael
> 
> 
> - Original Message -
> From: "Chappell, Simon P" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Monday, July 29, 2002 9:06 PM
> Subject: RE: Architecture advice
> 
> 
> > Well, what we did to seperate Struts from the backend was to implement
> what we called a "Firebreak". We created an abstract Java class called
> API.java. It's whole purpose in life was to be the application API to the
> model component. This would enable us to utilise  alternative views and/or
> controllers if our needs ever took us in that direction.
> >
> > All functionality in the application is accessable through static
> methods
> in the API class. This is nice for us, we removed all processing logic
> from
> the actions and put it in the main application space. Now our actions
> concentrate on ActionForms and calling the API methods.
> >
> > To further the break between view and logic, we use Request and Reply
> objects to carry the data on the calls into and the return values back
> from
> the API.
> >
> > Simon
> >
> > -
> > Simon P. Chappell [EMAIL PROTECTED]
> > Java Programming Specialist  www.landsend.com
> > Lands' End, Inc.   (608) 935-4526
> >
> >
> > >-Original Message-
> > >From: Michael Delamere [mailto:[EMAIL PROTECTED]]
> > >Sent: Monday, July 29, 2002 1:15 PM
> > >To: Struts Users Mailing List
> > >Subject: Architecture advice
> > >
> > >
> > >Hi,
> > >
> > >I had a discussion at work today concerning the best way to
> > >implement our
> > >application.  A very
> > >basic discription of the framework would be the following:
> > >
> > >1. Struts + Velocity for the view
> > >2. Struts ActionServlets for the controller
> > >3. Service layer/methods for querying persistence layer
> > >4. OJB persistence layer
> > >
> > >The main debate was actually about what the service layer
> > >would look like.
> > >We thought about the following options:
> > >
> > >1. The service layer consists of static methods
> > >2. The service layer would consists of normal classes
> > >3. The service layer could consist of servlets
> > >
> > >The idea is that (this is nothing new of course) the service
> > >layer would
> > >purely have methods such as addToShoppingBasket() or
> > >checkLogin(); basically
> > >service methods which carry out the communication with the
> > >persistense layer
> > >and returns the result to the controller.
> > >
> > >The question is though, should we create a new object every
> > >time we want to
> > >access a stateless method?  Surely that would be a bit of an
> > >overhead.  Go
> > >with servlets?  This possibly ties it to the web-container too much and
> > >isn´t very elegant (?).  Another option would be just to use
> > >static methods;
> > >can this cause a problem when wanting to distribute to more
> > >than one server?
> > >Is it better in terms of performance?
> > >
> > >I would really appreciate some help and ideas on this.  It
> > >would make things
> > >easier in terms of deciding on the next step.
> > >
> > >Thanks in advance!
> > >
> > >Regards,
> > >
> > >Michael
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
> > ><mailto:struts-user->[EMAIL PROTECTED]>
> > >For
> > >additional commands,
> > >e-mail: <mailto:[EMAIL PROTECTED]>
> > >
> > >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> 
> 
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Architecture advice....

[Michael Delamere]

Graham,

there´s just one more question that I have concerning your method.

Obviously there will be many different objects which make up the service
facade.  Does that mean that one has a "factory" for each object; i.e. each
"factory" returns it´s type of instance,  or do you pass a parameter to the
"factory" and return an instance accordingly?

Thanks for your time.

Michael


- Original Message -
From: "David Graham" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 9:59 PM
Subject: Re: Architecture advice


> I chose not to implement a session facade in my current project but have
> done it this way in other applications.  I really dislike bunches of
static
> method calls so this solution works nicely.  I mispoke when I mentioned
the
> factory method; it would only create the singleton instance on the first
> request, after that it would always return that instance.  You would use
> your service layer like this:
>
> // returns same instance every time
> ServiceFacade sf = ServiceFacade.getInstance();
> sf.doSomeServiceMethod();
>
> instead of
>
> ServiceFacade.doSomeServiceMethod();
>
> Sure, it's one more line of code but it is a cleaner design to me.
>
> >Yep, that´s exactly what it sounds like :-).  I would like to implement
> >something similar to the session facade used in EJB environments.
> >
> >I like the singleton idea.  Have you implemented this yourself.  What are
> >your experiences in doing it this way?
> >I take it that the factory would do the job of making sure that only the
> >existing instance is returned and if gone, create a new one.
> >
> >Have I got that right?  I certainly like the idea.
> >
> >Regards,
> >
> >Michael
> >
> >
> >- Original Message -
> >From: "David Graham" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Monday, July 29, 2002 8:59 PM
> >Subject: Re: Architecture advice
> >
> >
> > > Sounds like a "how to implement a facade" problem.  I would make your
> > > service layer a singleton with a factory method to retrieve the
> >instance.
> > > That way you avoid the static method calls and maintain the symantics
of
> > > passing messages to objects (the singleton).  You also avoid creating
a
> >new
> > > object everytime you want to use a service method.
> > >
> > >
> > > >Hi,
> > > >
> > > >I had a discussion at work today concerning the best way to implement
> >our
> > > >application.  A very
> > > >basic discription of the framework would be the following:
> > > >
> > > >1. Struts + Velocity for the view
> > > >2. Struts ActionServlets for the controller
> > > >3. Service layer/methods for querying persistence layer
> > > >4. OJB persistence layer
> > > >
> > > >The main debate was actually about what the service layer would look
> >like.
> > > >We thought about the following options:
> > > >
> > > >1. The service layer consists of static methods
> > > >2. The service layer would consists of normal classes
> > > >3. The service layer could consist of servlets
> > > >
> > > >The idea is that (this is nothing new of course) the service layer
> >would
> > > >purely have methods such as addToShoppingBasket() or checkLogin();
> > > >basically
> > > >service methods which carry out the communication with the
persistense
> > > >layer
> > > >and returns the result to the controller.
> > > >
> > > >The question is though, should we create a new object every time we
> >want
> >to
> > > >access a stateless method?  Surely that would be a bit of an
overhead.
> >Go
> > > >with servlets?  This possibly ties it to the web-container too much
and
> > > >isn´t very elegant (?).  Another option would be just to use static
> > > >methods;
> > > >can this cause a problem when wanting to distribute to more than one
> > > >server?
> > > >Is it better in terms of performance?
> > > >
> > > >I would really appreciate some help and ideas on this.  It would make
> > > >things
> > > >easier in terms of deciding on the next step.
> > > >
> > > >Thanks in advance!
> > > >
> > > >Regards,
> > > >
> > > >Michael
> > > >
> > > >
>

Re: Architecture advice....

[Michael Delamere]

yes, I think I will try that now and possibly introduce it at work tomorrow.
It´s just what I have been looking for because I didn´t like the _idea_ of
static methods (although the last couple of threads have proven otherwise);
nor did I like the idea of having the service methods in servlets.

Thanks for your advice.  I don´t know what I´d do without these lists! :-)

Michael


- Original Message -
From: "David Graham" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 9:59 PM
Subject: Re: Architecture advice


> I chose not to implement a session facade in my current project but have
> done it this way in other applications.  I really dislike bunches of
static
> method calls so this solution works nicely.  I mispoke when I mentioned
the
> factory method; it would only create the singleton instance on the first
> request, after that it would always return that instance.  You would use
> your service layer like this:
>
> // returns same instance every time
> ServiceFacade sf = ServiceFacade.getInstance();
> sf.doSomeServiceMethod();
>
> instead of
>
> ServiceFacade.doSomeServiceMethod();
>
> Sure, it's one more line of code but it is a cleaner design to me.
>
> >Yep, that´s exactly what it sounds like :-).  I would like to implement
> >something similar to the session facade used in EJB environments.
> >
> >I like the singleton idea.  Have you implemented this yourself.  What are
> >your experiences in doing it this way?
> >I take it that the factory would do the job of making sure that only the
> >existing instance is returned and if gone, create a new one.
> >
> >Have I got that right?  I certainly like the idea.
> >
> >Regards,
> >
> >Michael
> >
> >
> >- Original Message -
> >From: "David Graham" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Monday, July 29, 2002 8:59 PM
> >Subject: Re: Architecture advice
> >
> >
> > > Sounds like a "how to implement a facade" problem.  I would make your
> > > service layer a singleton with a factory method to retrieve the
> >instance.
> > > That way you avoid the static method calls and maintain the symantics
of
> > > passing messages to objects (the singleton).  You also avoid creating
a
> >new
> > > object everytime you want to use a service method.
> > >
> > >
> > > >Hi,
> > > >
> > > >I had a discussion at work today concerning the best way to implement
> >our
> > > >application.  A very
> > > >basic discription of the framework would be the following:
> > > >
> > > >1. Struts + Velocity for the view
> > > >2. Struts ActionServlets for the controller
> > > >3. Service layer/methods for querying persistence layer
> > > >4. OJB persistence layer
> > > >
> > > >The main debate was actually about what the service layer would look
> >like.
> > > >We thought about the following options:
> > > >
> > > >1. The service layer consists of static methods
> > > >2. The service layer would consists of normal classes
> > > >3. The service layer could consist of servlets
> > > >
> > > >The idea is that (this is nothing new of course) the service layer
> >would
> > > >purely have methods such as addToShoppingBasket() or checkLogin();
> > > >basically
> > > >service methods which carry out the communication with the
persistense
> > > >layer
> > > >and returns the result to the controller.
> > > >
> > > >The question is though, should we create a new object every time we
> >want
> >to
> > > >access a stateless method?  Surely that would be a bit of an
overhead.
> >Go
> > > >with servlets?  This possibly ties it to the web-container too much
and
> > > >isn´t very elegant (?).  Another option would be just to use static
> > > >methods;
> > > >can this cause a problem when wanting to distribute to more than one
> > > >server?
> > > >Is it better in terms of performance?
> > > >
> > > >I would really appreciate some help and ideas on this.  It would make
> > > >things
> > > >easier in terms of deciding on the next step.
> > > >
> > > >Thanks in advance!
> > > >
> > > >Regards,
> > > >
> > > >Michael
> > > >
> > > >
> > > >--
> > &

Re: Architecture advice....

[Michael Delamere]

- Original Message -
From: "Greg Hess" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 10:00 PM
Subject: RE: Architecture advice


> I just recently seen an implementation that used static methods and I am
> always trying to tread lightly with the use of the ServletContext and
> HttpSession.
>
> My web container is hosting hundreds of these applications and I am
> concerned that this strategy might lead to problems in the future(running
> out of memory) but right now it is just my paranoia. I don't think the
> static method strategy will relieve my concerns with memory usage as the
> class will just live in another memory location?
>
That rather much sums up the discussion I had at work today on that subject.
I can´t speak of experience though, so if anyone knows better, please
contribute :-)

> I know what your thinking "hundreds" of the same web application being
> hosted on the same web container? It was in my spec to have every client
> subscription to this application(service) have unique web application
> assigned.

I don´t fully understand

>
> If I run into problems I might use RMI and place the service classes into
> the RMI registry.

We also had a similar idea.  JNDI was also on the agenda.  The problem is
though that we don´t want to set up an application server and JNDI without
one isn´t ideal.  I know that tomcat supports JNDI but I don´t much like the
way it is handled.

Regards,

Michael


>
> Any suggestions are greatly appreciate :-),
>
> Greg
>
> -Original Message-
> From: Michael Delamere [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 29, 2002 3:22 PM
> To: Struts Users Mailing List
> Subject: Re: Architecture advice
>
>
> Am I understanding you correctly that you weren´t happy with the first
> approach?  What were your experiences that´s getting you to rethink the
> matter?
>
> Thanks,
>
> Michael
>
>
> - Original Message -----
> From: "Greg Hess" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Monday, July 29, 2002 9:11 PM
> Subject: RE: Architecture advice
>
>
> > Hi,
> >
> > I have designed our service layer using normal classes, I initialize the
> > service layer on application start up and place them in the
> ServletContext.
> > I have been looking at this strategy and considering using Static
methods
> as
> > well, as the only state in these classes is the jdbc driver and base
data
> > source. My persistency layer implementation handles concurrency issues
and
> I
> > don't think I would run into any issues having the application
distributed
> > to more than one server.
> >
> > Wish I could offer more help, but I am in the same boat.
> >
> > Greg
> >
> > -Original Message-
> > From: Michael Delamere [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, July 29, 2002 2:15 PM
> > To: Struts Users Mailing List
> > Subject: Architecture advice
> >
> >
> > Hi,
> >
> > I had a discussion at work today concerning the best way to implement
our
> > application.  A very
> > basic discription of the framework would be the following:
> >
> > 1. Struts + Velocity for the view
> > 2. Struts ActionServlets for the controller
> > 3. Service layer/methods for querying persistence layer
> > 4. OJB persistence layer
> >
> > The main debate was actually about what the service layer would look
like.
> > We thought about the following options:
> >
> > 1. The service layer consists of static methods
> > 2. The service layer would consists of normal classes
> > 3. The service layer could consist of servlets
> >
> > The idea is that (this is nothing new of course) the service layer would
> > purely have methods such as addToShoppingBasket() or checkLogin();
> basically
> > service methods which carry out the communication with the persistense
> layer
> > and returns the result to the controller.
> >
> > The question is though, should we create a new object every time we want
> to
> > access a stateless method?  Surely that would be a bit of an overhead.
Go
> > with servlets?  This possibly ties it to the web-container too much and
> > isn´t very elegant (?).  Another option would be just to use static
> methods;
> > can this cause a problem when wanting to distribute to more than one
> server?
> > Is it better in terms of performance?
> >
> > I would really appreciate some help and ideas on this.  It would make
> things
> &

Re: Architecture advice....

[David Graham]

I chose not to implement a session facade in my current project but have 
done it this way in other applications.  I really dislike bunches of static 
method calls so this solution works nicely.  I mispoke when I mentioned the 
factory method; it would only create the singleton instance on the first 
request, after that it would always return that instance.  You would use 
your service layer like this:

// returns same instance every time
ServiceFacade sf = ServiceFacade.getInstance();
sf.doSomeServiceMethod();

instead of

ServiceFacade.doSomeServiceMethod();

Sure, it's one more line of code but it is a cleaner design to me.

>Yep, that´s exactly what it sounds like :-).  I would like to implement
>something similar to the session facade used in EJB environments.
>
>I like the singleton idea.  Have you implemented this yourself.  What are
>your experiences in doing it this way?
>I take it that the factory would do the job of making sure that only the
>existing instance is returned and if gone, create a new one.
>
>Have I got that right?  I certainly like the idea.
>
>Regards,
>
>Michael
>
>
>- Original Message -
>From: "David Graham" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Monday, July 29, 2002 8:59 PM
>Subject: Re: Architecture advice
>
>
> > Sounds like a "how to implement a facade" problem.  I would make your
> > service layer a singleton with a factory method to retrieve the 
>instance.
> > That way you avoid the static method calls and maintain the symantics of
> > passing messages to objects (the singleton).  You also avoid creating a
>new
> > object everytime you want to use a service method.
> >
> >
> > >Hi,
> > >
> > >I had a discussion at work today concerning the best way to implement 
>our
> > >application.  A very
> > >basic discription of the framework would be the following:
> > >
> > >1. Struts + Velocity for the view
> > >2. Struts ActionServlets for the controller
> > >3. Service layer/methods for querying persistence layer
> > >4. OJB persistence layer
> > >
> > >The main debate was actually about what the service layer would look
>like.
> > >We thought about the following options:
> > >
> > >1. The service layer consists of static methods
> > >2. The service layer would consists of normal classes
> > >3. The service layer could consist of servlets
> > >
> > >The idea is that (this is nothing new of course) the service layer 
>would
> > >purely have methods such as addToShoppingBasket() or checkLogin();
> > >basically
> > >service methods which carry out the communication with the persistense
> > >layer
> > >and returns the result to the controller.
> > >
> > >The question is though, should we create a new object every time we 
>want
>to
> > >access a stateless method?  Surely that would be a bit of an overhead.
>Go
> > >with servlets?  This possibly ties it to the web-container too much and
> > >isn´t very elegant (?).  Another option would be just to use static
> > >methods;
> > >can this cause a problem when wanting to distribute to more than one
> > >server?
> > >Is it better in terms of performance?
> > >
> > >I would really appreciate some help and ideas on this.  It would make
> > >things
> > >easier in terms of deciding on the next step.
> > >
> > >Thanks in advance!
> > >
> > >Regards,
> > >
> > >Michael
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:
> > ><mailto:[EMAIL PROTECTED]>
> > >For additional commands, e-mail:
> > ><mailto:[EMAIL PROTECTED]>
> >
> >
> >
> >
> > _
> > Chat with friends online, try MSN Messenger: http://messenger.msn.com
> >
> >
> > --
> > To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
> >
>
>
>--
>To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>




_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Architecture advice....

[Greg Hess]

I just recently seen an implementation that used static methods and I am
always trying to tread lightly with the use of the ServletContext and
HttpSession.

My web container is hosting hundreds of these applications and I am
concerned that this strategy might lead to problems in the future(running
out of memory) but right now it is just my paranoia. I don't think the
static method strategy will relieve my concerns with memory usage as the
class will just live in another memory location?

I know what your thinking "hundreds" of the same web application being
hosted on the same web container? It was in my spec to have every client
subscription to this application(service) have unique web application
assigned.

If I run into problems I might use RMI and place the service classes into
the RMI registry.

Any suggestions are greatly appreciate :-),

Greg

-Original Message-
From: Michael Delamere [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 29, 2002 3:22 PM
To: Struts Users Mailing List
Subject: Re: Architecture advice


Am I understanding you correctly that you weren´t happy with the first
approach?  What were your experiences that´s getting you to rethink the
matter?

Thanks,

Michael


- Original Message -
From: "Greg Hess" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 9:11 PM
Subject: RE: Architecture advice


> Hi,
>
> I have designed our service layer using normal classes, I initialize the
> service layer on application start up and place them in the
ServletContext.
> I have been looking at this strategy and considering using Static methods
as
> well, as the only state in these classes is the jdbc driver and base data
> source. My persistency layer implementation handles concurrency issues and
I
> don't think I would run into any issues having the application distributed
> to more than one server.
>
> Wish I could offer more help, but I am in the same boat.
>
> Greg
>
> -Original Message-
> From: Michael Delamere [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 29, 2002 2:15 PM
> To: Struts Users Mailing List
> Subject: Architecture advice
>
>
> Hi,
>
> I had a discussion at work today concerning the best way to implement our
> application.  A very
> basic discription of the framework would be the following:
>
> 1. Struts + Velocity for the view
> 2. Struts ActionServlets for the controller
> 3. Service layer/methods for querying persistence layer
> 4. OJB persistence layer
>
> The main debate was actually about what the service layer would look like.
> We thought about the following options:
>
> 1. The service layer consists of static methods
> 2. The service layer would consists of normal classes
> 3. The service layer could consist of servlets
>
> The idea is that (this is nothing new of course) the service layer would
> purely have methods such as addToShoppingBasket() or checkLogin();
basically
> service methods which carry out the communication with the persistense
layer
> and returns the result to the controller.
>
> The question is though, should we create a new object every time we want
to
> access a stateless method?  Surely that would be a bit of an overhead.  Go
> with servlets?  This possibly ties it to the web-container too much and
> isn´t very elegant (?).  Another option would be just to use static
methods;
> can this cause a problem when wanting to distribute to more than one
server?
> Is it better in terms of performance?
>
> I would really appreciate some help and ideas on this.  It would make
things
> easier in terms of deciding on the next step.
>
> Thanks in advance!
>
> Regards,
>
> Michael
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Architecture advice....

[Chappell, Simon P]

Your welcome.

I just checked with the chaps and they agree. Because our API is completely abstract 
and methods are static and we have no synchronised code blocks or member variable 
accesses, we do not expect any bottlenecks in that piece of code.

Hope this helps.

>-Original Message-
>From: Michael Delamere [mailto:[EMAIL PROTECTED]]
>Sent: Monday, July 29, 2002 2:44 PM
>To: Struts Users Mailing List
>Subject: Re: Architecture advice
>
>
>Nice to hear.  I suppose worried was the wrong word :-) !  
>Basically our
>experience with this type of architecture isn´t all that 
>great; nonetheless
>we want to do our best possible to eliminate known problems or 
>bottlenecks
>before starting.  There´s nothing worse then hearing the 
>words... "if only
>we had" half way through the project.
>
>Therefore I really appreciate you guys sharing your 
>experiences with me :-)
>!
>
>Thanks,
>
>Michael
>
>
>- Original Message -
>From: "Chappell, Simon P" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Sent: Monday, July 29, 2002 9:27 PM
>Subject: RE: Architecture advice
>
>
>> Not yet! Of course, the API methods are 100% passthrough. 
>They exist only
>to prevent "M" mixing with the "V" and "C". To that extent, I 
>am not too
>worried.
>>
>> Simon
>>
>> >-Original Message-
>> >From: Michael Delamere [mailto:[EMAIL PROTECTED]]
>> >Sent: Monday, July 29, 2002 2:30 PM
>> >To: Struts Users Mailing List
>> >Subject: Re: Architecture advice
>> >
>> >
>> >Thanks to you also!
>> >
>> >It´s a great help to hear other peoples experiences.  What we
>> >were worried
>> >about is that all calls for a particular job would go via the
>> >one and only
>> >static method; i.e. thought it might become a bit of a
>> >bottleneck.  Did you
>> >experience anything along those lines?
>> >
>> >Thanks for your time.
>> >
>> >Regards,
>> >
>> >Michael
>> >
>> >
>> >- Original Message -
>> >From: "Chappell, Simon P" <[EMAIL PROTECTED]>
>> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>> >Sent: Monday, July 29, 2002 9:06 PM
>> >Subject: RE: Architecture advice
>> >
>> >
>> >> Well, what we did to seperate Struts from the backend was to
>> >implement
>> >what we called a "Firebreak". We created an abstract Java 
>class called
>> >API.java. It's whole purpose in life was to be the application
>> >API to the
>> >model component. This would enable us to utilise  alternative
>> >views and/or
>> >controllers if our needs ever took us in that direction.
>> >>
>> >> All functionality in the application is accessable through
>> >static methods
>> >in the API class. This is nice for us, we removed all
>> >processing logic from
>> >the actions and put it in the main application space. Now 
>our actions
>> >concentrate on ActionForms and calling the API methods.
>> >>
>> >> To further the break between view and logic, we use 
>Request and Reply
>> >objects to carry the data on the calls into and the return
>> >values back from
>> >the API.
>> >>
>> >> Simon
>> >>
>> >> -
>> >> Simon P. Chappell [EMAIL PROTECTED]
>> >> Java Programming Specialist  www.landsend.com
>> >> Lands' End, Inc.   (608) 935-4526
>> >>
>> >>
>> >> >-Original Message-
>> >> >From: Michael Delamere [mailto:[EMAIL PROTECTED]]
>> >> >Sent: Monday, July 29, 2002 1:15 PM
>> >> >To: Struts Users Mailing List
>> >> >Subject: Architecture advice
>> >> >
>> >> >
>> >> >Hi,
>> >> >
>> >> >I had a discussion at work today concerning the best way to
>> >> >implement our
>> >> >application.  A very
>> >> >basic discription of the framework would be the following:
>> >> >
>> >> >1. Struts + Velocity for the view
>> >> >2. Struts ActionServlets for the controller
>> >> >3. Service laye

Re: Architecture advice....

[Michael Delamere]

Nice to hear.  I suppose worried was the wrong word :-) !  Basically our
experience with this type of architecture isn´t all that great; nonetheless
we want to do our best possible to eliminate known problems or bottlenecks
before starting.  There´s nothing worse then hearing the words... "if only
we had" half way through the project.

Therefore I really appreciate you guys sharing your experiences with me :-)
!

Thanks,

Michael


- Original Message -
From: "Chappell, Simon P" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 9:27 PM
Subject: RE: Architecture advice


> Not yet! Of course, the API methods are 100% passthrough. They exist only
to prevent "M" mixing with the "V" and "C". To that extent, I am not too
worried.
>
> Simon
>
> >-Original Message-
> >From: Michael Delamere [mailto:[EMAIL PROTECTED]]
> >Sent: Monday, July 29, 2002 2:30 PM
> >To: Struts Users Mailing List
> >Subject: Re: Architecture advice
> >
> >
> >Thanks to you also!
> >
> >It´s a great help to hear other peoples experiences.  What we
> >were worried
> >about is that all calls for a particular job would go via the
> >one and only
> >static method; i.e. thought it might become a bit of a
> >bottleneck.  Did you
> >experience anything along those lines?
> >
> >Thanks for your time.
> >
> >Regards,
> >
> >Michael
> >
> >
> >- Original Message -
> >From: "Chappell, Simon P" <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >Sent: Monday, July 29, 2002 9:06 PM
> >Subject: RE: Architecture advice
> >
> >
> >> Well, what we did to seperate Struts from the backend was to
> >implement
> >what we called a "Firebreak". We created an abstract Java class called
> >API.java. It's whole purpose in life was to be the application
> >API to the
> >model component. This would enable us to utilise  alternative
> >views and/or
> >controllers if our needs ever took us in that direction.
> >>
> >> All functionality in the application is accessable through
> >static methods
> >in the API class. This is nice for us, we removed all
> >processing logic from
> >the actions and put it in the main application space. Now our actions
> >concentrate on ActionForms and calling the API methods.
> >>
> >> To further the break between view and logic, we use Request and Reply
> >objects to carry the data on the calls into and the return
> >values back from
> >the API.
> >>
> >> Simon
> >>
> >> -
> >> Simon P. Chappell [EMAIL PROTECTED]
> >> Java Programming Specialist  www.landsend.com
> >> Lands' End, Inc.   (608) 935-4526
> >>
> >>
> >> >-Original Message-
> >> >From: Michael Delamere [mailto:[EMAIL PROTECTED]]
> >> >Sent: Monday, July 29, 2002 1:15 PM
> >> >To: Struts Users Mailing List
> >> >Subject: Architecture advice
> >> >
> >> >
> >> >Hi,
> >> >
> >> >I had a discussion at work today concerning the best way to
> >> >implement our
> >> >application.  A very
> >> >basic discription of the framework would be the following:
> >> >
> >> >1. Struts + Velocity for the view
> >> >2. Struts ActionServlets for the controller
> >> >3. Service layer/methods for querying persistence layer
> >> >4. OJB persistence layer
> >> >
> >> >The main debate was actually about what the service layer
> >> >would look like.
> >> >We thought about the following options:
> >> >
> >> >1. The service layer consists of static methods
> >> >2. The service layer would consists of normal classes
> >> >3. The service layer could consist of servlets
> >> >
> >> >The idea is that (this is nothing new of course) the service
> >> >layer would
> >> >purely have methods such as addToShoppingBasket() or
> >> >checkLogin(); basically
> >> >service methods which carry out the communication with the
> >> >persistense layer
> >> >and returns the result to the controller.
> >> >
> >> 

RE: Architecture advice....

[Chappell, Simon P]

Not yet! Of course, the API methods are 100% passthrough. They exist only to prevent 
"M" mixing with the "V" and "C". To that extent, I am not too worried.

Simon

>-Original Message-
>From: Michael Delamere [mailto:[EMAIL PROTECTED]]
>Sent: Monday, July 29, 2002 2:30 PM
>To: Struts Users Mailing List
>Subject: Re: Architecture advice
>
>
>Thanks to you also!
>
>It´s a great help to hear other peoples experiences.  What we 
>were worried
>about is that all calls for a particular job would go via the 
>one and only
>static method; i.e. thought it might become a bit of a 
>bottleneck.  Did you
>experience anything along those lines?
>
>Thanks for your time.
>
>Regards,
>
>Michael
>
>
>- Original Message -
>From: "Chappell, Simon P" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Sent: Monday, July 29, 2002 9:06 PM
>Subject: RE: Architecture advice
>
>
>> Well, what we did to seperate Struts from the backend was to 
>implement
>what we called a "Firebreak". We created an abstract Java class called
>API.java. It's whole purpose in life was to be the application 
>API to the
>model component. This would enable us to utilise  alternative 
>views and/or
>controllers if our needs ever took us in that direction.
>>
>> All functionality in the application is accessable through 
>static methods
>in the API class. This is nice for us, we removed all 
>processing logic from
>the actions and put it in the main application space. Now our actions
>concentrate on ActionForms and calling the API methods.
>>
>> To further the break between view and logic, we use Request and Reply
>objects to carry the data on the calls into and the return 
>values back from
>the API.
>>
>> Simon
>>
>> -
>> Simon P. Chappell [EMAIL PROTECTED]
>> Java Programming Specialist  www.landsend.com
>> Lands' End, Inc.   (608) 935-4526
>>
>>
>> >-Original Message-
>> >From: Michael Delamere [mailto:[EMAIL PROTECTED]]
>> >Sent: Monday, July 29, 2002 1:15 PM
>> >To: Struts Users Mailing List
>> >Subject: Architecture advice
>> >
>> >
>> >Hi,
>> >
>> >I had a discussion at work today concerning the best way to
>> >implement our
>> >application.  A very
>> >basic discription of the framework would be the following:
>> >
>> >1. Struts + Velocity for the view
>> >2. Struts ActionServlets for the controller
>> >3. Service layer/methods for querying persistence layer
>> >4. OJB persistence layer
>> >
>> >The main debate was actually about what the service layer
>> >would look like.
>> >We thought about the following options:
>> >
>> >1. The service layer consists of static methods
>> >2. The service layer would consists of normal classes
>> >3. The service layer could consist of servlets
>> >
>> >The idea is that (this is nothing new of course) the service
>> >layer would
>> >purely have methods such as addToShoppingBasket() or
>> >checkLogin(); basically
>> >service methods which carry out the communication with the
>> >persistense layer
>> >and returns the result to the controller.
>> >
>> >The question is though, should we create a new object every
>> >time we want to
>> >access a stateless method?  Surely that would be a bit of an
>> >overhead.  Go
>> >with servlets?  This possibly ties it to the web-container 
>too much and
>> >isn´t very elegant (?).  Another option would be just to use
>> >static methods;
>> >can this cause a problem when wanting to distribute to more
>> >than one server?
>> >Is it better in terms of performance?
>> >
>> >I would really appreciate some help and ideas on this.  It
>> >would make things
>> >easier in terms of deciding on the next step.
>> >
>> >Thanks in advance!
>> >
>> >Regards,
>> >
>> >Michael
>> >
>> >
>> >--
>> >To unsubscribe, e-mail:
>> ><mailto:struts-user->[EMAIL PROTECTED]>
>> >For
>> >additional commands,
>> >e-mail: <mailto:[EMAIL PROTECTED]>
>> >
>> >
>>
>> --
>> To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
>> For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
>>
>
>
>--
>To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Architecture advice....

[Michael Delamere]

Thanks to you also!

It´s a great help to hear other peoples experiences.  What we were worried
about is that all calls for a particular job would go via the one and only
static method; i.e. thought it might become a bit of a bottleneck.  Did you
experience anything along those lines?

Thanks for your time.

Regards,

Michael


- Original Message -
From: "Chappell, Simon P" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 9:06 PM
Subject: RE: Architecture advice


> Well, what we did to seperate Struts from the backend was to implement
what we called a "Firebreak". We created an abstract Java class called
API.java. It's whole purpose in life was to be the application API to the
model component. This would enable us to utilise  alternative views and/or
controllers if our needs ever took us in that direction.
>
> All functionality in the application is accessable through static methods
in the API class. This is nice for us, we removed all processing logic from
the actions and put it in the main application space. Now our actions
concentrate on ActionForms and calling the API methods.
>
> To further the break between view and logic, we use Request and Reply
objects to carry the data on the calls into and the return values back from
the API.
>
> Simon
>
> -
> Simon P. Chappell [EMAIL PROTECTED]
> Java Programming Specialist  www.landsend.com
> Lands' End, Inc.   (608) 935-4526
>
>
> >-Original Message-
> >From: Michael Delamere [mailto:[EMAIL PROTECTED]]
> >Sent: Monday, July 29, 2002 1:15 PM
> >To: Struts Users Mailing List
> >Subject: Architecture advice
> >
> >
> >Hi,
> >
> >I had a discussion at work today concerning the best way to
> >implement our
> >application.  A very
> >basic discription of the framework would be the following:
> >
> >1. Struts + Velocity for the view
> >2. Struts ActionServlets for the controller
> >3. Service layer/methods for querying persistence layer
> >4. OJB persistence layer
> >
> >The main debate was actually about what the service layer
> >would look like.
> >We thought about the following options:
> >
> >1. The service layer consists of static methods
> >2. The service layer would consists of normal classes
> >3. The service layer could consist of servlets
> >
> >The idea is that (this is nothing new of course) the service
> >layer would
> >purely have methods such as addToShoppingBasket() or
> >checkLogin(); basically
> >service methods which carry out the communication with the
> >persistense layer
> >and returns the result to the controller.
> >
> >The question is though, should we create a new object every
> >time we want to
> >access a stateless method?  Surely that would be a bit of an
> >overhead.  Go
> >with servlets?  This possibly ties it to the web-container too much and
> >isn´t very elegant (?).  Another option would be just to use
> >static methods;
> >can this cause a problem when wanting to distribute to more
> >than one server?
> >Is it better in terms of performance?
> >
> >I would really appreciate some help and ideas on this.  It
> >would make things
> >easier in terms of deciding on the next step.
> >
> >Thanks in advance!
> >
> >Regards,
> >
> >Michael
> >
> >
> >--
> >To unsubscribe, e-mail:
> ><mailto:struts-user->[EMAIL PROTECTED]>
> >For
> >additional commands,
> >e-mail: <mailto:[EMAIL PROTECTED]>
> >
> >
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Architecture advice....

[Michael Delamere]

Yep, that´s exactly what it sounds like :-).  I would like to implement
something similar to the session facade used in EJB environments.

I like the singleton idea.  Have you implemented this yourself.  What are
your experiences in doing it this way?
I take it that the factory would do the job of making sure that only the
existing instance is returned and if gone, create a new one.

Have I got that right?  I certainly like the idea.

Regards,

Michael


- Original Message -
From: "David Graham" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 8:59 PM
Subject: Re: Architecture advice


> Sounds like a "how to implement a facade" problem.  I would make your
> service layer a singleton with a factory method to retrieve the instance.
> That way you avoid the static method calls and maintain the symantics of
> passing messages to objects (the singleton).  You also avoid creating a
new
> object everytime you want to use a service method.
>
>
> >Hi,
> >
> >I had a discussion at work today concerning the best way to implement our
> >application.  A very
> >basic discription of the framework would be the following:
> >
> >1. Struts + Velocity for the view
> >2. Struts ActionServlets for the controller
> >3. Service layer/methods for querying persistence layer
> >4. OJB persistence layer
> >
> >The main debate was actually about what the service layer would look
like.
> >We thought about the following options:
> >
> >1. The service layer consists of static methods
> >2. The service layer would consists of normal classes
> >3. The service layer could consist of servlets
> >
> >The idea is that (this is nothing new of course) the service layer would
> >purely have methods such as addToShoppingBasket() or checkLogin();
> >basically
> >service methods which carry out the communication with the persistense
> >layer
> >and returns the result to the controller.
> >
> >The question is though, should we create a new object every time we want
to
> >access a stateless method?  Surely that would be a bit of an overhead.
Go
> >with servlets?  This possibly ties it to the web-container too much and
> >isn´t very elegant (?).  Another option would be just to use static
> >methods;
> >can this cause a problem when wanting to distribute to more than one
> >server?
> >Is it better in terms of performance?
> >
> >I would really appreciate some help and ideas on this.  It would make
> >things
> >easier in terms of deciding on the next step.
> >
> >Thanks in advance!
> >
> >Regards,
> >
> >Michael
> >
> >
> >--
> >To unsubscribe, e-mail:
> ><mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
> ><mailto:[EMAIL PROTECTED]>
>
>
>
>
> _
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Architecture advice....

[Michael Delamere]

Am I understanding you correctly that you weren´t happy with the first
approach?  What were your experiences that´s getting you to rethink the
matter?

Thanks,

Michael


- Original Message -
From: "Greg Hess" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Monday, July 29, 2002 9:11 PM
Subject: RE: Architecture advice


> Hi,
>
> I have designed our service layer using normal classes, I initialize the
> service layer on application start up and place them in the
ServletContext.
> I have been looking at this strategy and considering using Static methods
as
> well, as the only state in these classes is the jdbc driver and base data
> source. My persistency layer implementation handles concurrency issues and
I
> don't think I would run into any issues having the application distributed
> to more than one server.
>
> Wish I could offer more help, but I am in the same boat.
>
> Greg
>
> -Original Message-
> From: Michael Delamere [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 29, 2002 2:15 PM
> To: Struts Users Mailing List
> Subject: Architecture advice
>
>
> Hi,
>
> I had a discussion at work today concerning the best way to implement our
> application.  A very
> basic discription of the framework would be the following:
>
> 1. Struts + Velocity for the view
> 2. Struts ActionServlets for the controller
> 3. Service layer/methods for querying persistence layer
> 4. OJB persistence layer
>
> The main debate was actually about what the service layer would look like.
> We thought about the following options:
>
> 1. The service layer consists of static methods
> 2. The service layer would consists of normal classes
> 3. The service layer could consist of servlets
>
> The idea is that (this is nothing new of course) the service layer would
> purely have methods such as addToShoppingBasket() or checkLogin();
basically
> service methods which carry out the communication with the persistense
layer
> and returns the result to the controller.
>
> The question is though, should we create a new object every time we want
to
> access a stateless method?  Surely that would be a bit of an overhead.  Go
> with servlets?  This possibly ties it to the web-container too much and
> isn´t very elegant (?).  Another option would be just to use static
methods;
> can this cause a problem when wanting to distribute to more than one
server?
> Is it better in terms of performance?
>
> I would really appreciate some help and ideas on this.  It would make
things
> easier in terms of deciding on the next step.
>
> Thanks in advance!
>
> Regards,
>
> Michael
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Architecture advice....

[Chappell, Simon P]

Well, what we did to seperate Struts from the backend was to implement what we called 
a "Firebreak". We created an abstract Java class called API.java. It's whole purpose 
in life was to be the application API to the model component. This would enable us to 
utilise  alternative views and/or controllers if our needs ever took us in that 
direction.

All functionality in the application is accessable through static methods in the API 
class. This is nice for us, we removed all processing logic from the actions and put 
it in the main application space. Now our actions concentrate on ActionForms and 
calling the API methods.

To further the break between view and logic, we use Request and Reply objects to carry 
the data on the calls into and the return values back from the API.

Simon

-
Simon P. Chappell [EMAIL PROTECTED]
Java Programming Specialist  www.landsend.com
Lands' End, Inc.   (608) 935-4526


>-Original Message-
>From: Michael Delamere [mailto:[EMAIL PROTECTED]]
>Sent: Monday, July 29, 2002 1:15 PM
>To: Struts Users Mailing List
>Subject: Architecture advice
>
>
>Hi,
>
>I had a discussion at work today concerning the best way to 
>implement our
>application.  A very
>basic discription of the framework would be the following:
>
>1. Struts + Velocity for the view
>2. Struts ActionServlets for the controller
>3. Service layer/methods for querying persistence layer
>4. OJB persistence layer
>
>The main debate was actually about what the service layer 
>would look like.
>We thought about the following options:
>
>1. The service layer consists of static methods
>2. The service layer would consists of normal classes
>3. The service layer could consist of servlets
>
>The idea is that (this is nothing new of course) the service 
>layer would
>purely have methods such as addToShoppingBasket() or 
>checkLogin(); basically
>service methods which carry out the communication with the 
>persistense layer
>and returns the result to the controller.
>
>The question is though, should we create a new object every 
>time we want to
>access a stateless method?  Surely that would be a bit of an 
>overhead.  Go
>with servlets?  This possibly ties it to the web-container too much and
>isn´t very elegant (?).  Another option would be just to use 
>static methods;
>can this cause a problem when wanting to distribute to more 
>than one server?
>Is it better in terms of performance?
>
>I would really appreciate some help and ideas on this.  It 
>would make things
>easier in terms of deciding on the next step.
>
>Thanks in advance!
>
>Regards,
>
>Michael
>
>
>--
>To unsubscribe, e-mail:   
>[EMAIL PROTECTED]>
>For 
>additional commands, 
>e-mail: 
>
>

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

RE: Architecture advice....

[Greg Hess]

Hi,

I have designed our service layer using normal classes, I initialize the
service layer on application start up and place them in the ServletContext.
I have been looking at this strategy and considering using Static methods as
well, as the only state in these classes is the jdbc driver and base data
source. My persistency layer implementation handles concurrency issues and I
don't think I would run into any issues having the application distributed
to more than one server.

Wish I could offer more help, but I am in the same boat.

Greg

-Original Message-
From: Michael Delamere [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 29, 2002 2:15 PM
To: Struts Users Mailing List
Subject: Architecture advice


Hi,

I had a discussion at work today concerning the best way to implement our
application.  A very
basic discription of the framework would be the following:

1. Struts + Velocity for the view
2. Struts ActionServlets for the controller
3. Service layer/methods for querying persistence layer
4. OJB persistence layer

The main debate was actually about what the service layer would look like.
We thought about the following options:

1. The service layer consists of static methods
2. The service layer would consists of normal classes
3. The service layer could consist of servlets

The idea is that (this is nothing new of course) the service layer would
purely have methods such as addToShoppingBasket() or checkLogin(); basically
service methods which carry out the communication with the persistense layer
and returns the result to the controller.

The question is though, should we create a new object every time we want to
access a stateless method?  Surely that would be a bit of an overhead.  Go
with servlets?  This possibly ties it to the web-container too much and
isn´t very elegant (?).  Another option would be just to use static methods;
can this cause a problem when wanting to distribute to more than one server?
Is it better in terms of performance?

I would really appreciate some help and ideas on this.  It would make things
easier in terms of deciding on the next step.

Thanks in advance!

Regards,

Michael


--
To unsubscribe, e-mail:

For additional commands, e-mail:



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

Re: Architecture advice....

[David Graham]

Sounds like a "how to implement a facade" problem.  I would make your 
service layer a singleton with a factory method to retrieve the instance.  
That way you avoid the static method calls and maintain the symantics of 
passing messages to objects (the singleton).  You also avoid creating a new 
object everytime you want to use a service method.


>Hi,
>
>I had a discussion at work today concerning the best way to implement our
>application.  A very
>basic discription of the framework would be the following:
>
>1. Struts + Velocity for the view
>2. Struts ActionServlets for the controller
>3. Service layer/methods for querying persistence layer
>4. OJB persistence layer
>
>The main debate was actually about what the service layer would look like.
>We thought about the following options:
>
>1. The service layer consists of static methods
>2. The service layer would consists of normal classes
>3. The service layer could consist of servlets
>
>The idea is that (this is nothing new of course) the service layer would
>purely have methods such as addToShoppingBasket() or checkLogin(); 
>basically
>service methods which carry out the communication with the persistense 
>layer
>and returns the result to the controller.
>
>The question is though, should we create a new object every time we want to
>access a stateless method?  Surely that would be a bit of an overhead.  Go
>with servlets?  This possibly ties it to the web-container too much and
>isn´t very elegant (?).  Another option would be just to use static 
>methods;
>can this cause a problem when wanting to distribute to more than one 
>server?
>Is it better in terms of performance?
>
>I would really appreciate some help and ideas on this.  It would make 
>things
>easier in terms of deciding on the next step.
>
>Thanks in advance!
>
>Regards,
>
>Michael
>
>
>--
>To unsubscribe, e-mail:   
>
>For additional commands, e-mail: 
>




_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


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