Hi Giovanni, 11 feb 2014 kl. 17:22 skrev Giovanni Botta:
> Roland, > Thanks for the reply. I do agree that having individual actors wrap each > transaction might be the way to go. I will cook up a little demo and send it > over your way so you can decide if it's worth adding to the docs. Sounds good! Don’t forget to run those actors on a dedicated dispatcher (since JPA activities are blocking) ;-) Regards, Roland > > Ian, > I am aware of the Camel module. I'll definitely check it out and dive in and > figure out what's missing (if anything). Thanks for the pointers. > > Giovanni > > On Tuesday, February 11, 2014 6:55:02 AM UTC-5, Akka Team wrote: > Hi Giovanni, > > while it might work to send a transaction around between actors, I believe > that that is the wrong approach. In the Actor Model, the only consistent > place is within a given actor, everything else is inconsistent. Therefore I > would collect all information needed for performing a DB transaction within > one actor and then use JPA / Hibernate / etc. only within the actor’s > confines. The answer to the question of “how do I integrate Hibernate with > Akka” then becomes moot, since neither API will need to be aware of the > other—within an Actor you just write normal code as if Akka did not exist. > (If this is the way to go, then documenting that would still be interesting, > though.) > > The above is derived from Akka’s principles and might well sound naïve when > viewed from the other side of the fence, and in that case I would be very > much interested in hearing about a use-case which does not fit this model. It > is always best to look at something concrete when exploring terrain which is > only vaguely familiar. > > Regards, > > Roland > > > > On Mon, Feb 10, 2014 at 3:59 PM, Giovanni Botta <amoj...@gmail.com> wrote: > 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>: > >> 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 – Empowering professional developers to build amazing apps. >> twitter: @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. >> To post to this group, send email to akka...@googlegroups.com. >> >> 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 – Reactive apps on the JVM. > twitter: @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. > To post to this group, send email to akka...@googlegroups.com. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > Akka Team > Typesafe - The software stack for applications that scale > Blog: letitcrash.com > Twitter: @akkateam > > -- > >>>>>>>>>> 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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @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.
