from java to scala, newbie questions

On 01/02/2012 10:12 PM, Omar wrote:
> Hey guys
> I am new to scala and have a few questions from the design point of
> view coming from the java/j2ee background.
>
> typically for a web app you would have something similar to the
> following layers
>
> controller -> service / repository -> Dao -> Entity
>
> And typically all these layers are stateless so no special
> consideration is needed for concurrency issues. A lot of the func on
> the server side is just synchronous function calls down the layers.
> (ofcourse im generalizing a bit)
>
> As akka documentation points out, services are a good candidate for
> actors. Some services like a "mail service" or a "audit log service"
> etc seem like great candidates for actors, things that may not require
> feedback to the UI or things like posts in a social networking kind of
> an app where near real time is good enough.
>
> I am a bit confused about more CRUD like operations and how actors fit
> into these situations, eg an extremely simple case scenario (ofcourse
> an actual implementation might have a more generic service so as to
> only have on crud service for all the entities)
>
> User Controller(or snippet in case of lift) -> User service -> User
> DAO -> User
>
> Assume we make the user service an actor.
>
> (I am using lift as an example since thats what ive been playing
> around with and have not had a chance to look at playframework in
> detail or any other framework)
>
> So lets say the user clicks a "view" link to view his user details,
> which dispatches to a snippet, which sends a msg to the user service
> actor. The user service on loading the info from the db sends a
> message to a comet actor which updates the UI. Would it have been
> better in this scenario not to use an actor and instead have returned
> the result synchronously? Since i would imagine async would seem a bit
> less responsive? Also i have not worked with comet so i dont know if
> having a majority of your web app using comet for every thing is bad?
>
> Not a 100% sure if snippets can be turned into actors but if so, i
> could use a future and block but is that better than sync stateless
> service without using actors
>
> I guess im wondering what people already using scala/akka (esp in web
> apps) have to recommend about how to design/layer enterprise (possibly
> distributed apps) using scala/akka with web/rest/mobile clients and if
> there are any services that are not suited as actors? My biggest
> reason to moving to scala is to get away from the bloat of java so
> wondering if that means different ways of thinking about design and
> architecture.
>
> Related to the previous question, i know the reasons behind having
> everything decoupled with all the diff layers, but most examples i
> have seen in lift (or playframework), the snippet or the controller
> seems to be directly accessing the model eg via the companion object.
> I assume this is only for teaching purposes but in real production
> app, you would still have these layers?? (esp if the business tier
> might be distributed on a diff server)
>
> The reason i ask is that I always see mention of "similar to ror" for
> rapid development (and i have never worked with ruby on rails).
> (assuming client and business logic was bundled in a single war) is
> having access to the model (representing the active record pattern)
> directly in the view is considered ok? To me its like injecting the
> dao in the controller. but unlike typical java frameworks, these
> frameworks provide a much tighter integration between the view and
> model (like validation, generating forms etc). So i wasnst sure if
> people were actually doin so
>
> Also using Lifts "Record/Mapper" or PlayFramework's "Model" ties the
> business logic to the web framework a little bit especially if i want
> to use things like validation etc. This means if i ever change my
> client side framework, either i would have to change my business tier
> or make the Record/Model work with the new framework. Is there any
> plans in scala itself to provide validation api like the java bean
> validation? Are people currently writing their own solutions to have a
> non framework specific option?
>
> For instance in the java world i can have a simple bean, (move all my
> orm mappings to a xml file rather than annotation) so that for certain
> web clients like gwt i dont have to worry about the instrumentation
> added by the orm frameworks and dependence on javax.persistence
> annotations on the client side and use these pojos as my dtos. (I know
> a lot of people argue to use the detached entity as a dto but in some
> situations it just doenst work)> However, the pojo is still just java
> not dependent on any framework api. And with the new bean validation
> annotations, validation is still part of the java platform.
>
>
> There are plenty of books for java from architecture and design point
> of view of making a "enterprise scale app". Are there any recommended
> sources for scala (or for functional/actor based programming) from
> design and architecture point of view for all the diff tiers (just to
> see what to carry over from java and what to leave behind)

Sorry for a not so long answer but it's late...
Take a look at my example here: https://github.com/andreak/on-example-rpm
It touches many aspects of what you're asking. Warning; It's rather fat
and probably also does very much you don't care for (like showing JSF
interacting with Lift-AJAX).

Please overlook the fact that the example doesn't use immutable DTOs in
the actors and hence might experience some serious concurrency-issues
trying to lazy-load associations in the entities used in the distributed
nature of actors. I'll update it some day showing how to map the JPA
entities to immutable DTOs (using simple case-classes) and use them in
all actors (comet).

Thanks Andreas. The project provided some great insight. Though the
web tier code is proving a little bit challenging to grasp (since
there is quite a bit going on in there and i am a beginner with lift).
Would you mind clarifying a few things for me. If my understanding is
correct, then

(project list template) -> Project Snippet => calls AppService and
gets a list of all the projects that it displays on the screen.
Regardless of if the snippet is called (with or without ajax),
processing from the snippet itself everything is happening
synchronously (since the services are not actors but are just typical
stateless services) (unless i overlooked something, only actors used
are the comet actors on the client side)

Similarly, (project edit template) -> ProjectEditSnippet calls create
or update on the AppService

The confusion on my part is regarding the use of comet. Not sure how
that fits in. Again still very basic understanding of lift so maybe my
understanding of the code is incorrect, so please correct me if i am
wrong

- When the project list is displayed, each project has a edit link
- clicking the link gets the projectdto and caches it in the comet
actor. If we update the project, the cache is updated so that when we
view the project, it displays the info from cache using comet (rather
than - retrieving the information again from the business tier). Does
that sound right?

If that is correct, then the answer to my original question is that
for crudify operations, (or filtering operations on when you are
displaying a table/list). it is better to do that synchronously using
regular old services, rather than sending that event to actor based
service to be processed asycnhronously,? And using actor based
services for operations that either do not require replies or UI
updates can tolerate delays?

On 2012, Jan 2, at 10:12 PM, Omar wrote:
> I am a bit confused about more CRUD like operations and how actors fit
> into these situations, eg an extremely simple case scenario (ofcourse

This is great question.

I don't feel I know enough of the libraries/frameworks people use out there to give you specific answers. Hereabouts, we use a more traditional java stack because we struggled with the documentation for the scala libraries when we started out well over a year ago. I would assume that your choice of libraries affect how you best can assemble your application.

My general and quite useless answers to your question:
- try to figure out how the most efficient solution should be assembled. "Efficient" here should vary depending on your situation. If you work for a startup you will probably have a completely different set of priorities (cashflow) than if you work for a large bank (quality). Oh, and your priorities will change over time. A startup will grow or die. The stuff you toy around with may make it into production.
- there is no "right" solution. DTOs were considered the "right" way to do things ten years ago. Five years ago, people got bored writing all that code. The only thing I am sure of is that whatever way we build applications today can be improved upon tomorrow.
- try to arrange matters so that you can move your functionality forward when the technologies shift. This means, amongst other things, that you should try to get as many implementation details that may change in the future out of your tests as possible.
- if you go for an asynchronous solution, make sure you understand what a race condition is, when they might arise, and how to avoid them as much as possible.

Sorry for wimping out on you.

yours
Geir

Thanks Gier, any response is appreciated.

I agree about libs/frameworks people use. With the rapid rate at which
scala libs and frameworks get introduced makes it tough to know or
decide on what to use, unless you have the time and resources to
research and play around with them all. There is no "spring like"
standard goto framework in scala. I think closest you get is akka on
the server side of things since its very unobstrusive and at the end
of the day the messages are simply scala case classes.(my goal on this
project is to get the most out of the scala lang itself without
resorting to too many frameworks. After all the whole reason for me
moving to scala is to have the lang do all the heavy lifting. Sure you
use a few scala based libs here and there. But i guess this dilemma
was true in java as well, people were using hibernate and other orm
solutions directly, before java said ok here is jpa, do everything you
need using the java platform and just plug and play whatever
implemenation you like)

With teh web frameworks, its a tougher decision since to use the the
framework specific classes in your model/business tier means you do
get all the wonderful capabilities that these frameworks offer (like
validation, integration with the views and forms), but you do couple
your self to the framework. I think for this one, i prefer the similar
approach to Andreas where i write the code to wire in my DTO's (or
entities) returned from my business tier to the framework's client
tier somehow to get the functionality.

As far as the async handling of certain things (like crud ops) using
actor services in a web app, the thing that throws me off a bit is
when i think async in web apps, i thnk ajax. So if i am making an ajax
call, thats one layer of asynchronicity (to improve user experience),
and if i pass it on to an actor (wihout blocking for a result), then
thats another layer of asycn (but this one doesnt necessarily improve
the experience depending on response time and comet update vs
synchronous call) . Most of my experience with messaging has been
synchronous and most of the discussion ive seen regarding sync vs
async messaging , is usually regarding web services or jms systems
where youre talking to independent and possibly third party systems.
In this case, the actor might be bundled inside the war itself. (i
really need to re-read martin fowlers integration patterns book to
refresh my memory :) )

Maybe its better to have both versions (a stateless service and an
actor based service) for these crud operations. Then i can not only
try to do some testing under load to see response time differences,
it would also cover scenarios where
async crud service that does not require updates to a UI (eg from a
separate automated system talking via rest)
sync crud service (whether from the web UI) or a mobile client using
rest

> DTOs were considered the "right" way to do things ten years ago. Five years ago, people got bored writing all that code. The only thing I am sure of is that whatever way we build applications today can be improved upon tomorrow.

As a way of encapsulating the parameters to a RPC - I can't really
think of a compelling alternative. Particularly as Scala IDE doesn't
code complete method parameters.

Regards,

Bryan Hunt