Forums Register Login

Terminology Clarification

+Pie Number of slices to send: Send

In our assignment, there are 3 layers of interest, in my mind :-

Presentation Layer - constitutes the GUI plus invocation of the RMI interface methods( network mode ) to access the Data class or direct invocation of the methods on the Data class
Network Layer - allows GUI application to call Data class methods located remotely. This is provided in my case by the RMI
Data layer - support the access to the database as provided by the Data class.

I read the terms "Business layer" and "Service layer" also mentioned regularly in the forum. Would it be possible to explain to me where & how these two layer fit in the overall picture with respect to my perception please.

Regards

Pete
+Pie Number of slices to send: Send
Howdy, Pete! It is good to see you around!

In the EJB 3 In Action book (which happens to be really great, by the way), the authors address what they call "traditional four-tier layered architecture", which is a way to logically divide your application. Basically, you have GUI Layer -> Business Logic Layer -> Persistence Layer -> Database Layer. In this architecture, the presentation layer is responsible for dealing with graphical user interface-related matters, such as displaying the result of a query to the user, or accepting the user’s input. For instance, in the JEE context, JSP or XHTML files compose this layer. In this type of architecture, this layer is not supposed to contain business logic, which should entirely be concentrated in the business logic layer. This layer composes the heart of this architecture and is responsible for keeping all business rules implemented by the application. The business logic layer does not directly retrieve or persist information in the database; instead, all database-related operations are intermediated by the persistence layer, which is an object-oriented abstraction over the database layer. This layer should not also contain business logic.

In our case, I thought it would be a good approach to have interfaces in the business logic layer with the business operations that we are supposed to implement (for instance, searching for rooms or booking rooms). What I usually do is face these classes as isolated components, so the interface is designed independently of a particular implementation. In our case, we either use directly the Data class (which is the persistence layer, in this case), or the RMI server. The Data class finally deals directly with the .db file (which is the database layer, in this case). One example of this organization could be:



It is important to note that these layers are logical layers, which means that they can be located in the same physical layer. In my case, the business logic layer and the GUI layer run on the same machine. When we have the business logic layer running on the client, we have the called "thick client", which was my case. When we have the business logic layer running on the server side, we have the called "thin client".

And finally, according to the description provided in the book, the GUI uses the business logic layer. In my case, what I did was use the business components inside the ActionListeners (which can be faced as controllers). So, for instance, I use the "bookRoom" method of my business layer inside the BookRoomButtonListener.

This really helps you get independent of a particular implementation (for instance, the GUI would never know where the data came from when using the search method of the interface provided above), eases the maintenance and promotes reusability.

Hope this helps! If you still have other doubts, please let us know!
+Pie Number of slices to send: Send

Greetings Roberto,

It is nice to be around but really I would also like to get this certification complete and maybe enjoy some quality time

So just to continue on from your explanation and try to correlate this to what I have done ...

My implementation is also a thick client approach. So the book operation is all handled from the GUI side ie it
- locks record,
- read the record to book,
- update the record ( contractor id ),
- release lock

I have implemented pretty much identical approach to your example. So just to extend that example to cater for remote access to the Data class, I have this :-




In the Service interface, I have effectively all the public interfaces of the Data class.


The above interfaces are invoked from the GUI controller. So when the user selects to Boo a contractor, the following happens as a result pressing the Book Jbutton ActionListener :-

services.lockRecord(recNo);
services.readRecordObj(recNo);
services.updateRecord(recNo, record, lockCookie); // containing updated contractor id field
services.unlock(recNo, lockCookie);

So, going with the example, I think, you are saying that this "Business Layer" is defined by the "Service" interface.
In my case, the Service interface provides a means of accessing the Data class from the GUI and also "hiding" how the Data class is accessed ie it could be direct or using RMI. I don't see any Buiness logic here. Obviously, I am missing a point or two !.

Should the above logic need to performed somewhere else ?


Regards

Pete

+Pie Number of slices to send: Send
 

Pete Palmer wrote:So, going with the example, I think, you are saying that this "Business Layer" is defined by the "Service" interface.
In my case, the Service interface provides a means of accessing the Data class from the GUI and also "hiding" how the Data class is accessed ie it could be direct or using RMI. I don't see any Buiness logic here. Obviously, I am missing a point or two !.

Should the above logic need to performed somewhere else ?


In simple terms, Rob's mentioned "GUI layer -> business logic layer -> persistence layer -> database layer" is really in your case "client (GUI) -> service layer -> Data class".

Since you are using "thick client" then IMO you are using the service layer as some form of adapter because your service layer is identical to Data class or Sun's provided interface (eg exposing lock, unlock etc). Given this, your "business logic" is really the Data class because in the service layer you get an instance of Data class and delegate the book/search methods to the Data class.

For my own implementation, I didn't expose the lock/unlock methods to the client - do these in the service layer. So mine is more of a thin client. Mine also delegates to the Data class because the service layer calls Data class's lock/update/unlock in that order. So in my case the business logic is the "lock->process->unlock" block in my say book method in the service layer.
+Pie Number of slices to send: Send
Hi K,
Thank you for following up.

Given this, your "business logic" is really the Data class because in the service layer you get an instance of Data class

- correct

and delegate the book/search methods to the Data class.

I am interpreting this to mean that I invoke the necessary operations, from the GUI controller, on the business logic to "book" and "search". I don't have such methods as "book" or "search" declared in either the business logic or the Data class.
Invoking the appropriate methods on the business logic ( and hence on the Data class ) is all done from the GUI controller. eg as a result pressing the Book, ( on the GUI) Jbutton ActionListener will do the following :-

services.lockRecord(recNo);
services.readRecordObj(recNo);
services.updateRecord(recNo, record, lockCookie); // containing updated contractor id field
services.unlock(recNo, lockCookie);

Doing this in the GUI controller, is this an accpetable approach ? Or is it better to wrap all this in book () declared in the business logic, like yourself.

I have made all the public interfaces of the Data class available in the business logic, even though I don't use all of them. Is this OK ? Reason for doing this, is to cater for future enhancements to the GUI feature ie to allow the user to Update, Delete.

Regards

Pete


+Pie Number of slices to send: Send
You know there really isn't a "correct" or "incorrect" approach. There is only a "good" or "bad" approach. Since you are using thick client approach, your current approach seems fine. Using the GUI Controller is indeed a good choice - MVC man.

Honestly for thick client approach (exposing lock/unlock methods to client) may have the following consequence IMHO from the maintenance/enhacement viewpoint: Assume I'm the programmer going to enhance your programs.
I copy your code logic (lock->read->update->unlock) for some other new method say create... Now I will have a problem because create process does not need to lock/unlock, just call create and it does the work for me. So If I'm dumb (of course in this situation assume I am) and I don't read those docs I could have done:

services.lockRecord(recNo);
services.readRecordObj(recNo);
services.createRecord(recNo, record, lockCookie);
services.unlock(recNo, lockCookie);


You see how this will end up blablabla... Of course the smarter me having read the docs would have done:
services.createRecord(data);

Therefore the architecture of the whole app really decides these thing:
thick vs thin client (expose lock methods?)
where to put the processing code (lock->update->unlock)
how client connect to server (local and remote Data class lookup)

Of course I know you already done these or have an idea.
+Pie Number of slices to send: Send
Hi K,

I take your point, I have implemented the thick client approach but will ponder over it this bank holiday weekend, whilst I endeavour to address other aspects of the assignment.

One last question ( he says ... )

I have made all the public interfaces of the Data class available in the business layer, even though I don't use all of them.

Is that OK ? Thank you.

Regards

Pete
+Pie Number of slices to send: Send
Howdy, Pete!

Sorry for not replying yesterday... it's just that it was a holiday here in Brazil, so I took the day to rest.

Just to give you a position on your question:


So, going with the example, I think, you are saying that this "Business Layer" is defined by the "Service" interface.
In my case, the Service interface provides a means of accessing the Data class from the GUI and also "hiding" how the Data class is accessed ie it could be direct or using RMI. I don't see any Buiness logic here. Obviously, I am missing a point or two !.

Should the above logic need to performed somewhere else ?



The business logic layer is more related to implementing the business rules of a particular problem that an application is going to solve. One thing I noticed is that you said that "The above interfaces are invoked from the GUI controller", so it looks like you are putting business logic in a controller (or I may be wrong). You could move this code to another layer (the business logic layer), and have your GUI use it. Then, the business layer would either use local data (in standalone mode) or remote data (in networked mode).

To complete the example provided above (and renaming the Services interface so you can see how it could work with your Services interface), you could have the following code:



Then, you would have LocalApplicationServices using local data and RemoteApplicationServices using remote data. The idea is to move business logic to more specialized components, where they know the business steps to be taken (like, locking a record before updating it). Then, the GUI just deals with visual matters, and the Controllers delegate actions to the business components, which know the components that persist/retrieve data (the persistence layer). The business layer delegates data persisting/retrieving to the persistence layer, and all it does is deal with data, and just does what's asked by the business logic layer; for instance, if the business logic layer says "create this record!", the persistence layer says "ok, will do!".

The above schema could be represented also like this:

GUI Controller -> Business layer -> Remote Services (on the server side) -> Data class -> .db file (for remote implementation)
GUI Controller -> Business layer -> Data class -> .db file (for local implementation)

To summarize, my approach was to just include in the business logic layer the business actions to be taken. And from there, I use what's needed, which means that I chose not to expose, for instance, the lock/unlock/isLocked methods to the clients, and these think that it is only possible to search for rooms and book rooms.
+Pie Number of slices to send: Send
Hi Roberto,

Trust you enjoyed your holiday yesterday. Our's is on Monday. I will be using the time to progress with the assignment & in between watching football & cricket....

What can I say, a comprehensive response.

The above interfaces are invoked from the GUI controller", so it looks like you are putting business logic in a controller (or I may be wrong).

You are correct, it is in the controller.

The communication between K and yourself has made review my implementation and I think it would be wise for me to adopt a similar approach as it is more structured, easiar to follow and maintain.

Going with this approach, I don't clutter up my Services interface with unnecessary methods as I currently have.

The business logic layer is more related to implementing the business rules of a particular problem that an application is going to solve

This is done by providing the Search() & Book() operation. But this layer also hids from the GUI the detail of whether it is accessing the local or remote database. Is this considered to be implementing the business rule ?

Regards

Pete
+Pie Number of slices to send: Send
Howdy, my good buddy Pete!

The holiday went great yesterday! We finished the day eating a lot of soup (it was kindda' cold here in Brazil, 18º )!

This is done by providing the Search() & Book() operation. But this layer also hids from the GUI the detail of whether it is accessing the local or remote database. Is this considered to be implementing the business rule ?



Hmm... I think so. If you have these methods in classes (let's call components) that retrieve data from the persistence layer, and you can have your GUI use them with a simple call, and they deal with operations that the GUI doesn't have to know that exist (such as locking a record before updating it), then yes. You can also have these components in a separate package for better understanding. That's the called "business layer"!

I do believe that very soon you'll be a SCJD too. In my opinion, this is the second best certification related to the Java technology (the first is SCEA), because of the researches we have to do in our way, which really improve our knowledge. If there are other things you'd like to discuss in the future, please come here and let us know. We'll be very glad to at least try to help!

Have a great weekend and enjoy your holiday!
+Pie Number of slices to send: Send
K and Roberto,

From what was a general query, turned into, form me, interesting and educational discussion.
Thank you both for your input.

Kind Regards

Pete.

I do believe that very soon you'll be a SCJD too

Thats very encouraging, however, I think I have a little way to go !
+Pie Number of slices to send: Send
Once you get your server code done and make sure it works, then you are on your way to get SCJD.
+Pie Number of slices to send: Send

GUI Controller -> Business layer -> Remote Services (on the server side) -> Data class -> .db file (for remote implementation)
GUI Controller -> Business layer -> Data class -> .db file (for local implementation)



My original approach had all the "logic" in the GUI controller and I viewed this as a thick client implementation. However, I have moved away from that to the above, where the logic has moved into the business layer. Can I still view this as a thick client implementation ?

Just another question, how many Tier approach is the above ?

Regards

Pete
+Pie Number of slices to send: Send
Howdy, Pete!

Essentially, you have a thick client when you have the business layer running on the client. For instance, my approach was that I only had the Data class being represented by the server. When you have the client that has only the GUI, and the GUI makes calls to the server, where you have the business layer and the persistence layer, then you have the thin client. Some people choose to do the following:

GUI -> RMI Server, which has: business layer -> persistence layer -> .db file (Thin client, which has only the GUI running on it)

If you have the business layer running on the client side, and this layer makes calls to the RMI server, then you have a thick client. And even though you also have another layer (the RMI server) before the persistence layer, you still have the 4-tier layered architecture.

There is some confusion between what is a layer and what is a tier. What I find the best definition is that a tier is a physical separation, and a layer is a logical separation. Here is an article called Layers and Tiers which addresses this subject.
+Pie Number of slices to send: Send
Hello Roberto,

Thanks for clearing that issue. Earliar today, I just thinking about potential essay questions ( which is distant issue ) .. such as explain how many tiers did your architecture have and why this appraoch and similarly did you have thick/thin client and why etc. I realized I wasn't sure and would not have been able to answer corrctly.

Many Thanks

Pete

If you look closely at this tiny ad, you will see five bicycles and a naked woman:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 3822 times.
Similar Threads
Design Question
B&S: Need some clarification on the single mode flag
Non-Networked Mode
remote client provides methods of db.Data?
Lockmanger- singleton implementation /static creation & assignment in RMI server ?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 08:50:55.