Roland thanks for the reply. To be more specific, let me take an example. I am working on a legacy (monolithic) java web application that doesn't use any particular framework (everything from the servlet to configuration was manually crafted). The app uses Hibernate for ORM and a custom 'transaction service' that takes care of starting and committing transactions. We have discussed the option of modularizing the app using Akka in the backend/middle tier by extracting some of the existing services and migrating them to an Actor based implementation. The first question that came up was: how do we integrate Akka with Hibernate (nobody here wants to get rid of this ORM because so much work already went into it)? Is there a way to span transactions across several actors? Should we use Agents and STM for this? If so, how? (I haven't seen one example of that). Or should the JPA entity manager be passed around the actors? Is that even safe? In a typical java legacy application you would have a bunch of DAO method calls followed by a commit (or one large @Transactional method in the Spring world). What's the idiomatic way of doing this with actors achieving the same transactionality? As you see, this is a stereotypical example of the issues a (small) enterprise will run into when considering Akka. So, to rephrase my original question for this specific case: would a simple Akka example answer the above questions? If so, can you guide me through it? If I had pointers, I'd be glad to cook up a simple Akka + HBN example and contribute it to the docs.
Finally, I could give you more examples of the other service patterns or "buzzwords" I mentioned but I think the above is already a great start. Thanks again! Giovanni On Monday, February 10, 2014 2:49:09 AM UTC-5, rkuhn wrote: > > Hi Giovanni, > > 5 feb 2014 kl. 16:46 skrev Giovanni Botta <amoj...@gmail.com <javascript:> > >: > > Hey Roland > I just want to revive this thread because of my interest in Akka as a SOA > platform. I do believe Akka has what it takes to get the job done > (particularly with the new spray integration). However, I think there are > still some missing pieces. Akka is a relatively low level framework, > providing great flexibility and power to the users. However, as we all know > with great power comes great responsibility, i.e., it's easy to make the > wrong design choices. > > > That is true, and certainly more educational material is needed. We are > getting there: the Coursera course, Activator templates and last but not > least Akka’s documentation provide some rich inputs on how to get things > right. > > What I'm getting at is that it would be useful to build some additional > infrastructure on top of Akka cluster to implement some common SOA patterns > and move the user effort to high level service definition and configuration > that can be plugged in an existing framework. Some of these patterns > include but are not limited to: > > > - Security (authentication/authorization) > - Transactional services (ORM or NoSQL) and/or business locks > - Endpoints (REST, etc.) > - Client code generation (lightweight client libraries that can talk > to services using known protocols) > - Periodic tasks (schedulers, at-most-once execution) > - Work queue > - Service monitoring > - ... > > I might be hitting an enterprise layer that Akka is not specifically built > for but I think a framework like this would be invaluable to give Akka even > more visibility and appeal. > > > You mention several buzz words, where some (Transactions vs. persistent > actor state; periodic tasks via Quartz; Endpoints with akka-http and > akka-camel) are covered, but others like Security or Monitoring are > extremely vague. What exactly do you feel is missing? > > I am currently working on designing and implementing some of these pattern > using Akka and I would gladly share my experience and code if that sounds > like an interesting idea. > > > I guess that should answer my previous question as soon as you have > something to show, and it definitely is a good idea to start off like that. > Thanks in advance for your contributions to the Akka ecosystem! > > In the meantime I'd like your feedback and to open a discussion about the > best ways to proceed with the implementation and what existing > projects/code examples might work as a baseline. > > > It is a bit hard to give generic advice at this point, but one thing we > have learnt is that actor-based implementations should offer an > ActorRef-based interface (i.e. giving up all the nice advantages built into > Akka’s message passing abstraction is rarely worth it). > > Regards, > > Roland > > > Giovanni > > > On Wednesday, April 24, 2013 4:28:06 AM UTC-4, rkuhn wrote: >> >> Hi Yuesong, >> >> 23 apr 2013 kl. 15:11 skrev yues...@gmail.com: >> >> This is a use case question. I am exploring feasibility of using akka >> cluster as the underlying framework to build out a service oriented >> infrastructure. The architecture consists of an internet facing edge layer >> serving a public API; behind the edge, any number of internal services may >> be deployed; when a web request comes in, the edge will delegate to the >> internal services for business logic processing, aggregate the results and >> respond. The edge will take care of web request handling, service >> discovery, load balancing, circuit breaker, retry etc. while individual >> service will implement a specific business logic. In a way, it is similar >> to twitter's Finagle I suppose. >> >> The cluster including the edge and services can have up to a few hundred >> servers that are co-located in the same data center. It is critical to >> minimize latency and avoid blocking IO between edge nodes and service >> nodes. Akka cluster seems to be a good fit on a high level, but I'd like to >> get some expert opinions given the scale and latency requirements. I have >> worked with 2.0.x but not 2.1 or 2.2 yet, so any pointer as to what to look >> for and how to prototype/benchmark is also much appreciated. >> >> >> Your description matches our mental model of how to make most of >> akka-cluster, so I definitely think that you are looking in the right >> direction. You will need features which are part of the upcoming 2.2 >> release (like different node roles for front-end and different services) so >> it makes sense to start trying out the latest milestone 2.2-M3 which is a >> feature-complete preview. The scale of “a few hundred nodes” matches what >> other customers are using the experimental cluster support in Akka 2.1 for, >> and there is no blocking IO in Akka 2.2’s remoting layer (only connection >> establishment is blocking up to 2.1). You did not state your latency >> requirements, hence I cannot give a blanket answer on that point. >> >> We’ll be happy to answer further concrete questions you have, but it >> might also be worthwhile to consider more focused commercial support >> (including architecture review etc.); in the latter case please send a mail >> off-list. >> >> Regards, >> >> >> *Dr. Roland Kuhn* >> *Akka Tech Lead* >> Typesafe <http://typesafe.com/> – Empowering professional developers to >> build amazing apps. >> twitter: @rolandkuhn <http://twitter.com/#!/rolandkuhn> >> >> > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to akka-user+...@googlegroups.com <javascript:>. > To post to this group, send email to akka...@googlegroups.com<javascript:> > . > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > *Dr. Roland Kuhn* > *Akka Tech Lead* > Typesafe <http://typesafe.com/> – Reactive apps on the JVM. > twitter: @rolandkuhn > <http://twitter.com/#!/rolandkuhn> > > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
