• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Limitation on the provided interface

 
Alexandru Dragoi
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Should we use the provided interface on the client side when performing the calls to the server?
Or we can expose a different interface for the client?

I have the URLyBird assignment and I see some limitations, for example on finding records using a specified criteria.

Finding records is a two step process. First the client uses:

to get all the record Id's that match the criteria
After that, the client should query individual records using:


However the returned records may no longer match the specified criteria.
Another client modified the records, so the search may retrieve info that is no longer valid (taking into account the search criteria).

How did you fixed this? Did you exposed to the client another interface different from the one provided on the assignment?

Best regards,
Alex
 
Rehan Zahoor
Ranch Hand
Posts: 83
Android Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As far as I remember, there was something in the specification that allowed for small errors (due to changes by another client on network) while getting records against a specific criteria. Even if there is no provision, you can choose to implement in this way and mention it in your choices.txt. Another way can be putting the above mentioned methods in one synchronized method on server. There is no restriction on adding more methods to the interface. Even if there is a restriction (and better approach ofcourse) is to add this new method in a service layer above your data access layer.
The more important thing emphesized in my assigent was, data integrity of the data file. That is your locking of records must be fool proof.
 
K. Tsang
Bartender
Posts: 3583
16
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The interface exposed to client usually have one method for each functionality (search, book, etc). How the method is implemented is up to you.

The thing with search is that it represents the results at that moment of time. Yet when the client actually try to do something to it, some checking is needed to see if it's still valid.

As Rehan mentioned, having a fool-proof locking mechanism is key.
 
Alexandru Dragoi
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, guarding the integrity of the data file is also a primary concern for me.

But I do not see how to guarantee accurate search results without exposing a new interface to the client (or at least to extend the provided interface).
 
Rehan Zahoor
Ranch Hand
Posts: 83
Android Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think, the answer to your question lies in using a layered approach. You can call your mentioned meyhods in synchronized block at service layer. This would make sure that you would serve the right results at the time of your search. See this http://www.coderanch.com/t/615752/sr/certification/OCM-Java-SE-Developer.
However if another user teo changes some data after you have displayed your result to user one, then so be it. When the user one would try to book a room that is already booked by user two, you can display error message that this room has already been booked. You don' t have to update search results to all users after some user has booked a room or deleted a room. Not by the provided specs, I hope.
 
Alexandru Dragoi
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was just under the impression that the service layer must exactly match the interface that I was provided in the exam instructions (for the data access layer).
No more, no less...

But if I have the freedom to customize my service layer, then this is a cool thing.
This means that I can expose to the client completely different methods than those provided in the exam instructions.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alexandru Dragoi wrote:I was just under the impression that the service layer must exactly match the interface that I was provided in the exam instructions (for the data access layer).
No more, no less...

But if I have the freedom to customize my service layer, then this is a cool thing.
This means that I can expose to the client completely different methods than those provided in the exam instructions.

I passed the OCMJD exam (in 2009) with a thin client approach. So my business service exposed just 2 methods (which are required by the client): findRooms and bookRoom. I even created a subinterface of the required-to-implement interface and added a few extra methods (which were required for my solution). And my Data class implemented this subinterface (and thus also implemented the required-to-implement interface). I

In the assignment there are very few limitations. The only things you are required to do are the must requirements in your assignment. So every sentence containing "must", you must do. If you violate one of them (e.g. another name for your Data class), you will almost certainly fail. For all other decisions, it's completely up to you what you want to do. Many (or even all) of these decisions you could/should document/justify/explain in your design decisions document.

Hope it helps!
Kind regards,
Roel
 
Paweł Baczyński
Bartender
Posts: 1876
35
Firefox Browser IntelliJ IDE Java Linux Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alex,
I have used exactly the same approach as Roel described when I was doing my OCMJD in 2013.

By the way, have you read this?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic