Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Design problem : security layers

Reply
Thread Tools

Design problem : security layers

 
 
subtenante
Guest
Posts: n/a
 
      04-17-2007
Hi,

I'm fresh in java (started learning in december, by myself because
already in "enterprise scope"), and i'm having a little trouble.

I have to make a website, in jsp, and currently working on the
business model.

I'd like to reuse the Objects i write for the frontend in the backend,
namely the ones in the frontend generally have only getters, and the
ones in the backend also have setters.

So for the moment what i do is having two packages, namely frontend
and backend, and the backend Objects all extend from the frontend
ones.

Except that the frontend ones depend on each other : for example an
article will have an author Object in its attributes. But Author in
frontend has only getters.
When i do the backend version, it seems that if i directly extend from
the frontend class Article, the Author object used will be the one
from the frontend package also.

The only solution for the moment that i see is to create the Author
class as default (non public - non private), and write all the getters
setters for it. In the frontend I also write all the setters for the
Author in the Article class.

Then, when i go to the backend, i can extend and add the setters for
the Author, which are available.

But i'm not sure of this design. Anybody have suggestions on this kind
of problem ? A name of pattern to throw me i could dive into ?

Thanks.
 
Reply With Quote
 
 
 
 
subtenante
Guest
Posts: n/a
 
      04-17-2007
On Tue, 17 Apr 2007 16:53:48 +0800, subtenante
<(E-Mail Removed)> wrote:

TYPO CORRECTION :

>The only solution for the moment that i see is to create the Author
>class as default (non public - non private), and write all the getters
>setters for it. In the frontend I also write all the *Getters* for the
>Author in the Article class.


 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      04-17-2007
subtenante wrote:
> But i'm not sure of this design. Anybody have suggestions on this kind
> of problem ? A name of pattern to throw me i could dive into ?


"Front Controller", a.k.a. "Model-View-Controller" (MVC).

JSF and Struts implement it.

You should have only one entity class, not a hierarchy, for each entity type.

--
Lew
 
Reply With Quote
 
Wojtek
Guest
Posts: n/a
 
      04-17-2007
subtenante wrote :
> Hi,
>
> So for the moment what i do is having two packages, namely frontend
> and backend, and the backend Objects all extend from the frontend
> ones.


I usually split my packages by use case. So each package holds all the
classes required for one function. This includes the servlet, business
rules code and the Data class. The data class consists of only
attributes and their respective getter/setter pairs.

The Data class holds all the information which the JSP needs. The
information is loaded by the SQL class, inspected by the business class
(including setting flags). The Data object is then placed into the
HttpRequest.

The JSP picks out the Data object from the request and displays the
information held within it. It may also highlight some information
depending on the flags.

With each use case in its own package, and minimal interaction between
packages (except for the framework), I greatly reduce the probability
that a change in one package will affect another package.

--
Wojtek


 
Reply With Quote
 
Ed
Guest
Posts: n/a
 
      04-17-2007
On 17 Apr, 17:08, Wojtek <(E-Mail Removed)> wrote:

> > So for the moment what i do is having two packages, namely frontend
> > and backend, and the backend Objects all extend from the frontend
> > ones.

>
> I usually split my packages by use case. So each package holds all the
> classes required for one function. This includes the servlet, business
> rules code and the Data class. The data class consists of only
> attributes and their respective getter/setter pairs.
>



>
> With each use case in its own package, and minimal interaction between
> packages (except for the framework), I greatly reduce the probability
> that a change in one package will affect another package.
>
> --
> Wojtek


An interesting approach. I've often wondered how a package-per-feature
would look; your package-per-use-case looks even more advanced in that
direction.

Wojtek, can you tell me how you handle re-use between use cases?

..ed

--

www.EdmundKirwan.com - Home of The Fractal Class Composition



 
Reply With Quote
 
Ed
Guest
Posts: n/a
 
      04-17-2007
On 17 Apr, 10:53, subtenante <(E-Mail Removed)> wrote:
> Hi,
>
> I'm fresh in java (started learning in december, by myself because
> already in "enterprise scope"), and i'm having a little trouble.
>
> I have to make a website, in jsp, and currently working on the
> business model.
>
> I'd like to reuse the Objects i write for the frontend in the backend,
> namely the ones in the frontend generally have only getters, and the
> ones in the backend also have setters.
>
> So for the moment what i do is having two packages, namely frontend
> and backend, and the backend Objects all extend from the frontend
> ones.


Subtenante, I've read your post a couple of times, and I'm afraid I
don't understand. So this post is really a request for more
information.

Firstly: what do the words, "Frontend," and, "Backend," mean to you?
I've a feeling that they are well-defined terms in your field, but I'm
unfamiliar with them. (I don't know JSP, so maybe they're well-known
JSP terms, in which case you can stop reading here as all my advice
will be irrelevant.)

Secondly, I presume the system you're working on is not gigantic:
there are no fixed rules for the number of classes per package, but 50
is generally an upper limit. I presume you're not dealing here with
more than 100 classes in these two packages.

>
> Except that the frontend ones depend on each other : for example an
> article will have an author Object in its attributes. But Author in
> frontend has only getters.


An article has an author: what is it that you're designing? A
reference library of some sort?

I truly do not understand why a frontend (whatever that is) should
only have getters and a backend should only have setters.

> When i do the backend version, it seems that if i directly extend from
> the frontend class Article, the Author object used will be the one
> from the frontend package also.


Re-use is great, of course. You want to maximise your functionality
per line of code. But I don't understand how inheriting from one
package to another automatically brings this benefit.

If one class in backend inherits from a class in frontend, and then
that backend class is instantiated, there is only one object
instantiated: there are not two objects created, one in the backend
and one in the frontend. You can consider the instantiated object as a
mash of the backend object and the frontend object: but it's just one
object, not two.

>
> The only solution for the moment that i see is to create the Author
> class as default (non public - non private), and write all the getters
> setters for it. In the frontend I also write all the setters for the
> Author in the Article class.


I don't understand this: perhaps you could supply more information, or
details of the specific classes?

But if I were you, and this is just a project to get you used to Java,
then I'd forget about re-use. Re-use opportunities will present
themselves unmistakably (you'll be writing the same methods in
different places) and when they present themselves, deal with them
then.

I'd be far, far more interested in designing a solution to the problem
you're trying to solve as simply as possible, but with the flexibility
to change it to any ideas for the future that you might have.

Also, just as classes are encapsulated behaviour, think of packages as
encapsulated behaviour of a rougher granularity. If you have a
reference library application (as guessed) then you'll probably have
the following funtionality:
- Create a library.
- Add a work (with author, and perhaps cross-reference to other
works).
- Delete a work.
- Search for a work (or all works by an author, or any other
attribute).
- Save library.

These are all rough-grained behaviours. And though I wouldn't put each
in its own package (as Wojtek does - and feel free to chose his
approach), I'd imagine that you'd have the following packages
(presuming you're using Model-View-Controller, which you're maybe not
using, but it's a good way to separate the core functionality from the
way this is presented to the user, and you did say that you're working
on the, "Business model," which would be the model here):
com.subtenante.controller - parses commands from user and kicks off
execution in the model.
com.subtenante.model - holding package for main functionality.
com.subtenante.model.library - holds main functionality for the
library
com.subtenante.view - holding package for the presentation of your
library
com.subtenante.view.gui - GUI specifics for your library (if any).
com.subtenante.view.console - text specifics for your library.

Of coures, using JSP limits your view (you almost certainly won't have
a console view) but it demonstrates how packages should hold related
behaviours.

This also reinforces my lack of comprehension of your frontend and
backend.

And that com.subtenante.model.library will be further sub-packaged
depending on the application you're designing. It could be guessed
further that a major part of your library could be the search you use
to interrogate the library, and so maybe the library would have a
further sub-package:
com.subtenante.model.library.search

This is especially true if you could consider using a totally
different search engine in future.

Also, perhaps the indexing you use is a substantial piece of behaviour
that could be replaced by a different system of indexiing in future;
in this case you'd probably also have:
com.subtenante.model.library.index

If you could also envisage some sort of authentication whereby only
certain users could view the works of certain authors (ok, maybe a bit
Nazi, but you get the point) then you might want to allow you users to
log-on and base authentication on them, in which case you might have a
slew of sub-packages, beginning with:
com.subtenante.model.library.user
com.subtenante.model.library.security

And what if you want to charge people for use of your libary? Well,
then have:
com.subtenante.model.user.credit
com.subtenante.model.user.restrict
com.subtenante.model.user.history

Again, the credit sub-package will contain all that behaviour that
checks the user's back-account to ensure that he has enough money to
view the work he seeks. The history sub-package will hold the
functionality to show all the works the user has ever viewed.

These are, of course, just guesses, but the intent is to show that the
two packages frontend and backend don't really describe what those
packages do (outside those expert circles that understand those
terms).

Another way to look at it is this: if you have a requirement to change
something in your system in a few months time, will the person
implementing the change have a good idea where to look just based on
the package names?

Using MVC (sort of) as described above, the programmer will know that
a change to the GUI will not affect the com.subtenante.model sub-
packages so much.

Whether a GUI change will impact frontend or backend more, I have no
idea.

>
> Then, when i go to the backend, i can extend and add the setters for
> the Author, which are available.
>
> But i'm not sure of this design. Anybody have suggestions on this kind
> of problem ? A name of pattern to throw me i could dive into ?
>
> Thanks.


..ed

--

www.EdmundKirwan.com - Home of The Fractal Class Composition

 
Reply With Quote
 
Wojtek
Guest
Posts: n/a
 
      04-17-2007
Ed wrote :
> On 17 Apr, 17:08, Wojtek <(E-Mail Removed)> wrote:
>
>>> So for the moment what i do is having two packages, namely frontend
>>> and backend, and the backend Objects all extend from the frontend
>>> ones.

>>
>> I usually split my packages by use case. So each package holds all the
>> classes required for one function. This includes the servlet, business
>> rules code and the Data class. The data class consists of only
>> attributes and their respective getter/setter pairs.
>>

>
>
>>
>> With each use case in its own package, and minimal interaction between
>> packages (except for the framework), I greatly reduce the probability
>> that a change in one package will affect another package.
>>

> An interesting approach. I've often wondered how a package-per-feature
> would look; your package-per-use-case looks even more advanced in that
> direction.
>
> Wojtek, can you tell me how you handle re-use between use cases?


package names:

person
person.common
person.edit
person.filter
person.list

So the common package holds classes which are used by filter, list,
and/or edit, yet all are contained within person. These are usually
data holders.

In the case where a class might be used all over the place, that whole
"concept" gets its own package, usually in the framework.

Where the same code might be used between similar concepts such as
person.list and apes.list I used redundant code.

I spent quite a bit of time working out patterns which my use cases
use, so the same code flow is used in both person.list and apes.list,
with only imports and variable names being different.

If I need to make a pattern change (really rare now), then I go through
all the code, so that all the same patterns really are the same.

Maintaining the pattern IS a lot of work, but once set, it makes
creating new use cases a snap. Create a package set, copy, paste,
rename some classes, rename some variables, and there you go, a working
robust list and edit.

Also, I use the minimal posssible scope for everything. So the
classes/methods in a use case usually have package level scope, that is
there is no public modifier.

--
Wojtek


 
Reply With Quote
 
subtenante
Guest
Posts: n/a
 
      04-18-2007
Wow, thanks a lot Ed, for the time you spent answering.

I'll give you a bit more information here.

On 17 Apr 2007 15:37:08 -0700, Ed <(E-Mail Removed)> wrote:
>Firstly: what do the words, "Frontend," and, "Backend," mean to you?


The usual in the website paradigm : frontend is the website viewed by
users, backend the one seen by administrators.

My concern is security. I perhaps should have said that before.
I need the normal users of the website to have limited rights on the
objects they use (most of them don't even know they are creating
objects on my server, but you see my meaning).
That's the reason for the frontend package. The objects in that one
have very limited rights : only getters (and not all of them). This
way i am sure that the frontend webpages, which only import the
frontend package, have limited rights.

On the other end, i need the administrators to work on the objects in
the database, so create and update them. Therefore i need setters, and
a DB interface. I wondered if i would have two different classes for
each object or not, in the beginning i decided to extend the backend
ones from the frontend ones. But i'm reconsidering this.

>Secondly, I presume the system you're working on is not gigantic:
>there are no fixed rules for the number of classes per package, but 50
>is generally an upper limit. I presume you're not dealing here with
>more than 100 classes in these two packages.


Right.

>An article has an author: what is it that you're designing? A
>reference library of some sort?


It's only an example. Although i also have this articles/authors
structure in my model, it's not the main part.

>I truly do not understand why a frontend (whatever that is) should
>only have getters and a backend should only have setters.


Backend needs both, that why i extend in backend from frontend.

It's not likely that i am to maintain this project a long time, that's
why i wanted to be kind to the maintainers and have the least
redundant code possible.

>If one class in backend inherits from a class in frontend, and then
>that backend class is instantiated, there is only one object
>instantiated: there are not two objects created, one in the backend
>and one in the frontend. You can consider the instantiated object as a
>mash of the backend object and the frontend object: but it's just one
>object, not two.


I know. Backend users have their own objects, frontend users will
create theirs by themselves when they connect to the frontend of the
website.

>But if I were you, and this is just a project to get you used to Java,
>then I'd forget about re-use. Re-use opportunities will present
>themselves unmistakably (you'll be writing the same methods in
>different places) and when they present themselves, deal with them
>then.


Well that's the point. What i don't like about java is the "only one
inheritance", my problem would be solved otherwise.

If i do not inherit from the backend to their frontend version, i have
to recode all the constructors (sometimes heavy ones), and every
change in one attribute has to be done twice. I'm personnally not much
worried about it but i might not be the maintainer (and i work in an
"emerging" country : they have good programmers but poor english and
therefore limited access to documentation).

And because there is not multiple inheritance, i have to embed some
objects in my frontend ones. An author is an attribute of an article.
But they both are the frontend version (light getters). When i inherit
in the backend Article, i still have a frontend Author in it. But i
don't want it : i want a backend Author !

I was thinking that maybe generics would do the trick, but i'm not
sure how to make it work right now, and it makes every definition of
my objects a lot heavier (call
Article<backend.Author,backend.Language,backend.Co mments,...>).
I guess i could make another screening class that would create these
objects directly. Have to think about this.

>These are all rough-grained behaviours. And though I wouldn't put each
>in its own package (as Wojtek does - and feel free to chose his
>approach), I'd imagine that you'd have the following packages
>(presuming you're using Model-View-Controller, which you're maybe not
>using, but it's a good way to separate the core functionality from the
>way this is presented to the user


I thought that my db/jsp/java was already a MVC approach... You're
telling me there can be different MVC at different scales, that is one
db/jsp/java and one more within the java code ?

Anyways, thanks again for you long answer and all the details.
sub.
 
Reply With Quote
 
subtenante
Guest
Posts: n/a
 
      04-18-2007
On Tue, 17 Apr 2007 08:08:19 -0400, Lew <(E-Mail Removed)>
wrote:

>subtenante wrote:
>> But i'm not sure of this design. Anybody have suggestions on this kind
>> of problem ? A name of pattern to throw me i could dive into ?

>
>"Front Controller", a.k.a. "Model-View-Controller" (MVC).
>
>JSF and Struts implement it.
>
>You should have only one entity class, not a hierarchy, for each entity type.


Thanks Lew.

I have short time, and learning JSF or Struts would have taken too
much time (i seriously considered them and made a first attempt to use
them, but the "return on time investment" would not have been good
enough...).
 
Reply With Quote
 
subtenante
Guest
Posts: n/a
 
      04-18-2007
On Tue, 17 Apr 2007 15:08:24 GMT, Wojtek <(E-Mail Removed)> wrote:

>subtenante wrote :
>> Hi,
>>
>> So for the moment what i do is having two packages, namely frontend
>> and backend, and the backend Objects all extend from the frontend
>> ones.

>
>I usually split my packages by use case. So each package holds all the
>classes required for one function. This includes the servlet, business
>rules code and the Data class. The data class consists of only
>attributes and their respective getter/setter pairs.


Yep, i see your point, and it's mine too !
I'm not that much splitting the packages,but the backend/frontend
separation has the same philosophy i think. (In case i need only to
watch the website, there is the frontend package, in case i need also
to change the data i have the backend one. But in both cases the
objects have a lot of similarities.)

>The Data class holds all the information which the JSP needs. The
>information is loaded by the SQL class, inspected by the business class
>(including setting flags). The Data object is then placed into the
>HttpRequest.


The thing is that i look at my website as two separate ones. The
backend interferes with the database, updating it. The frontend only
reads it. They use the same kinds of objects, but never interact
directly, they always interact through the DB.

>With each use case in its own package, and minimal interaction between
>packages (except for the framework), I greatly reduce the probability
>that a change in one package will affect another package.


Well i *want* (and need) that a change in a frontend object makes a
change on the backend one. I want them both to have almost the same
attributes, generally, and i want for example all the getters (or
displaying methods) to be the same in the backend than in the frontend
(and not to have to do the changes twice every time). But i really do
not want the frontend objects to be able to make any change in the
database.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Question regarding oo design / layers Rob Meade ASP .Net 2 06-22-2007 01:37 PM
Subnets between core and access/distribution layers & routing between layers J Cisco 0 12-13-2006 08:38 PM
Layers Problem HoDeHoo HTML 0 02-27-2006 08:28 PM
Tiers, Layers, Models and Design Patterns (Model-2 of Struts) Jan Brunia Java 1 02-10-2004 05:38 AM
Layers/scroll bar problem on Macs murmur HTML 1 10-27-2003 03:25 AM



Advertisments