aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: exposing the MetaData to the client Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: exposing the MetaData to the client" Watch "NX: exposing the MetaData to the client" New topic
Author

NX: exposing the MetaData to the client

Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi everyone,
I have some questions how to expose the MetaData to the client:
I have following design for the Data-Layer:
the header-informations are read by DataSchema, a singleton instance.
DataSchema also creates an immutable object MetaData (thanx, Vlad) which provide informations needed by the client.
Further DataSchema contains a getMetaData method which returns MetaData.
In local mode the client can call getMetaData from DataSchema directly. For the remote mode, I have created a new Class called RemoteSchemaImpl implementing the remote interface RemoteSchema.
RemoteSchemaImpl's only method beneath its constructor is getMetaData, returning the serializable object MetaData.
1. Sounds a little bit complicated, I know, but I don't know a better way to provide the MetaData to the client for the 2-tier solutions.
Comments?
Thanks a lot in advance
Ulrich
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Ulrich,
Sounds a little bit complicated

Agreed
I don't think it is a good idea to let dataSchema have a method getMetaData(), since DataSchema is MetaData.
There many ways to do it.
Example 1:
You don't have MetaData class. Your Data class has a method getDataSchema (or getMetaData()), which returns DataSchema.
EXample 2: If your DataSchema contains some information needed for the server application and you don't want to expose it to the client:
You can have two classes:
One abstract class MetaData(contains all getters needed by client) and the DataSchema class extending MetaData.
Your Data class will have than MetaData getMetaData() method, which returns actually DataSchema. It would hide any complexity from the client.

Best,
Vlad
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Vlad
thank you for your reply.
One abstract class MetaData(contains all getters needed by client) and the DataSchema class extending MetaData.

That sounds cool. I will try this way and surely will have some more questions to ask
Greetings
Ulrich
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
Hi Vlad and Ulrich,
I have finished the core part, and now is trying to fine tune the programs.
At first, I read my MetaData from the database file, and I have this:

And I get the following:

These string values will be displayed in the JTable's header.
However, in my instructions:

My question is:
Should I keep displaying "name" in the JTable Header, or I should display "Hotel Name" instead of "name"?
I have tried this before, I put this mapping into the "suncertify.properties" file, but when it really display in the header field, it makes the length to be very long, which is very ugry
Any comments?
Thanks.
Nick
[ December 08, 2003: Message edited by: Nicholas Cheung ]

SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Nick,
Should I keep displaying "name" in the JTable Header, or I should display "Hotel Name" instead of "name"?

Well, I tried to display names from "descriptive name" list. I changed them a bit: Hotel name-> Hotel, Cutomer .... -> Customer and so on.
Best,
Vlad
P.S. I would suggest to change the name of your class MetaData to ColumnInfo or something like that. MetaData logically should a class describing all columns (e.g. the array of columns), not a single column.
Seid Myadiyev
Ranch Hand

Joined: Jul 02, 2002
Posts: 196
I would like to ask if I may "assume" the structure of the record from the instructions document and create a "Room" class based on the assumption with appropriate data types for each instance field. For example:

Or do I need to inspect the db file at runtime hold everything in abstraction (without any specific instance field names and types) and only make a wrapper for the array of strings which represent the field values? For example:

Thank you!
Seid
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Seid,
I would preffer the second option (with array). GUI is required to be developed with option of future functionality enhancements. The second option helps client to do so by providing more generic framework.
Best,
Vlad
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Vlad, hi Seid,
Seid,
I have tried also to use the descriptive names, but they're so long, now I will use the shorter field names.
Hi Vlad,
I have now thought a little bit about my further design concerning the MetaData(or whatever I will call it later, now, excuse me, I will keep this name
I.I can't implement getMetaData() in the Data-Class because I'm using the 2-tier approach (I suppose that we are not allowed to add further methods in the DBAccess interface).
Because I have DataSchema as a Singleton, I will have in this class getInstance()-method which returns the singleton (like you suggested, DataSchema extends MetaData):

Now, some thoughts concerning the exposing of MetaData for the client.
I think I have two options:
1. to add one more RemoteObject which includes a getMetaData()-method or
2.to include this method in one of my two already existing RemoteObjects, ConnectionFactory(Impl) or RemoteDBAccess(Impl). Because I can't add getMetaData to RemoteDBAccess for the reasons I mentioned above, I can add it to ConnectionFactory.
Please correct me, if you see some weak points in my reasoning
OK, let's assume that I choose the option 2:
So in ConnectionFactoryImpl I would have following method:

this is a kind of wrapper for DataSchema's getInstance() transforming the DataSchema in the User-conforming MetaData.
For the local mode, the transforming from DataSchema to MetaData will happen at the client side and look like:

I'm sorry to border you with this mass of code, but I'm a little bit lost.
What do you think about this approach?
Thanks a lot
Ulrich
[ December 08, 2003: Message edited by: Ulrich Heeger ]
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Vlad,
sorry to annoy you again
I just wanted to say that I will first try my concept and will probably post my questions in a new thread.
So thank you & see you later
Ulrich
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Ulrich,
I'm sorry to border you with this mass of code, but I'm a little bit lost

Stop saying sorry! I enjoy talking to you.
1. There is no way I would make another remote object just for DataSchema. I know, there were people doing that, but I, personally, don't like it. It is too complex and confusing.
2.
Solution A:
Well, I did have some kind of "hybrit" between 2/3 tier.
I did have interface DBAdapter. This adapter had no any much of the logic:
- It chained unchecked exception to checked exceptions.
- additional getMetaData() method.
I would solve the problems mentioned by you.
Solution B:
You have a standard interface (say DB) and data class implementing it.
You can create one more interface MyDB extending DB interface (which would have additional getMetaData() method). Then you can
1) just add getMetaData() method to your Data class and make it implement not DB, but MyDB. It is a bit risky (since it may be a breach of specification), but the people in this forum decided that it should be Ok.
2) create MyData class (pretty the same as DBAdapter), which would implement MyDB and call the logic from Data:

Your RemoteObject can wrap than MyDB instead of DB.
Best,
Vlad
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Vlad,
thanks for your help, I will try to avoid the word "sorry" in future, sorry

1. There is no way I would make another remote object just for DataSchema. I know, there were people doing that, but I, personally, don't like it. It is too complex and confusing.

That sounds reasonable. That�s also my intuitive thought.
Your further solution looks really good.
In the meantime, I�ve now tested the approach I�ve mentioned above:
So I have now implemented following methods in ConnectionFactoryImpl:

The question is if I can argue to integrate the getMetaData()-method within my ConnectionFactory. In this article from Sun
it�s written:

In general, a factory implementation is useful when you need one object to control the creation of and/or access to other objects.By using a factory in RMI, you can reduce the number of objects that you need to register with the RMI registry.

With this statement I could justify the implementation of getMetaData-method or what do you think about that? Shall I post a new thread to ask this question?
Greetings
Ulrich
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Ulrich,
I find your approach interesting. You can probably justify it: You don't have to follow patterns and so on. So, it is a valid solution.
However, I would try to avoid it, since your ConnectionObject consufes a bit from the first look. It is hard to comment it: it is a valid solution, but, I PERSONALLY, don't like it. I still beleive it is the best way to provide the client with business user interface containing all methods needed to work with the server (including getMetaData()).
I would like to ask others to join this thread to hear other opinions, since I my approach is, may be, too restrictive.
Best,
Vlad
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Vlad,
thank you for your comments.
I have to think a little bit about my concept.
Greetings
Ulrich
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX: exposing the MetaData to the client