What tier goes where

Question

Hi,
with a web (jsp) application, the tier architecture is simple:
Database tier -> middle tier (webserver) -> client tier (webbrowser)
But what about JClient apps.
Database tier -> middle tier (bc4j) -> client tier (jclient) ?
Where does code execute. If I use a viewobject to populate a JTree, does it 'run' on the middle tier (application server), or does it run on the client machine in the jclient application? What and where's exactly the separation between gui and middle tier?
In a web environment, the browser is the 'thin' client, which knows only html. All business logic is performed on the server. Is the JClient situation comparable? Or is a jclient a much less thin client?

Answer 1

As you're familiar, BC4J allows you to build J2EE-compliant apps with a clean, logical three-tier design. You can then choose to deploy your application as a physical two tier application, or a physical three-tier application as your needs require. These rules hold, regardless of the client implementation technology.
Two concrete examples of a physical two-tier physical deployment are:
[list=1]
[*]JClient application talking to BC4J appmodule in local mode
[*]JSP pages using BC4J datatags talking to BC4J appmodule in local mode
[list]
Two concrete examples of a physical three-tier deployment are:
[list=1]
[*]JClient application talking to BC4J appmodule deployed as an EJB Session Bean in a J2EE Container on another machine
[*]JSP pages using BC4J datatags talking to BC4J appmodule deployed as an EJB Session Bean in a J2EE Container on another machine
[list]
Of course, the degenerate case of the last example above occurs when the JSP pages and the EJB Session Bean actually reside on the same J2EE container, then you can use the EJB Session Bean option of BC4J with local interfaces.
Regardless of the UI layer you're using, your client works with the set of BC4J interfaces in the oracle.jbo.* package.
What changes in the two deployment scenarios is the classes in the JBO framework that implement these common interfaces.
[list]
[*]In a physical two-tier deployment (also known as "local mode"), the interfaces are implemented by classes in the oracle.jbo.server.* package.
[*]In a physical three-tier deployment, the interfaces are implemented by classes in the oracle.jbo.client.* package (and its oracle.jbo.client.remote.* "sub"-package.
[list]
This is transparent to your application code since you are working with the interfaces.
When you use the remote mode, the bulk of the implementation stays on the EJB tier inside your session bean. What travels to the client are collections of value objects which are managed by a client-side value-object cache that BC4J implements for you (but which you do not need to manage yourself). If you are, say, browsing the results of a query that has scrolled through 1000 records, BC4J will keep a "window" of rows of value objects on the client for you, where the size of the window is set via the setRangeSize() method on the view object you're working with.
BC4J is also designed to keep its client-side value object cache kept in sync with any changes that occur in the business objects in the middle tier. For example, say you have some business logic coded into your Employee business object that increases an employee's salary by $1000.00 when their job category goes up a level. And let's say your client is working with a view of the data that shows:
Empno    Ename    Salary     JobClass
1234     Ivo      4321         4If the client updates the value of "JobClass" from 4 to 5, the attribute change on the client-side value object eventually makes it to the middle tier -- immediately if you are using the SYNC_IMMEDIATE mode, and on the next row navigation, row validation, or custom method invocation in the case of our SYNC_LAZY mode. In the middle tier, BC4J syncs the change in the client-side value object "row" of this view object query result and sets the "JobClass" view row attribute in the middle tier. Since view objects cooperate with entity objects, the setting of the "JobClass" on the view object row internally delegates to an attempt to set the "JobClass" attribute on the underlying entity object instance representing employee #1234 (which was created in the EO cache as this row was queried in from the database). Your business logic in the setJobClass() method at the Employee entity level contains the logic that decides that, based on the increase in job class, the salary should get incremented by $1000, so it calls setSalary() like this:
  private static final Number ONE_THOUSAND = new Number(1000);
  public void setJobClass(Number value) {
    setAttributeInternal(JOBCLASS, value);
    // If new job class is greater than old job class, increase salary by $1000
    Number prevJobClass = (Number)getPostedAttribute(JOBCLASS);
    if (value.compareTo(prevJobClass) > 0) {
      setSalary(getSalary().add(ONE_THOUSAND));
  }Part of the functionality of BC4J's unique "Value Messenger" design pattern implementation is that the framework keeps track of the "side-effects" of any middle-tier activity and automatically returns any relevant changes to the client-side value object cache to keep it in sync in the same round-trip that caused the activity to occur. In this example, the client is looking at a value object with the "Salary" attribute for employee #1234 and this employee's Salary has changed as a result of having set the JobClass attribute.
The net effect is that the user types in a new job class of 5 and tabs to a new field, and the updated salary of 5321 appears automatically.
Empno    Ename    Salary     JobClass
1234     Ivo      5321         5  <---------This attribute changed by the user
                     \_______<_______ The updated salary (increased by $1000) appearsThis works both in local mode or 3-tier mode for JClient, JSP, or any of our supported "View-Layer" technologies that bind to the standard BC4J client interfaces in oracle.jbo.*
So, in short, a BC4J JClient app that's deployed as a 3-tier application is a thin client with a small cache of value objects for view objects with active iterators open on the client.
Let me know if you have more questions on this subject.