需要有关 Web 应用程序的设计/架构的意见

发布于 2024-08-11 21:37:21 字数 342 浏览 6 评论 0 原文

我正在开发一个 Web 应用程序,它需要从一些本地和一些非本地资源获取数据,然后显示它。由于从这些资源获取数据可能需要任意时间,因此我正在考虑使用参与者概念,以便每个参与者负责从各自的资源获取数据。请求线程将等待每个参与者完成其任务,然后使用 ajax 仅更新依赖于该数据的网页部分。这样,用户将在收到数据后立即开始查看数据,而不是等待所有数据完成然后首先查看数据。

我计划为此研究 scala/lift 框架。我在网上阅读了一些有关 scala/lift 的文章,想探讨这是否是解决此问题的正确方法,以及 scala/lift 是否是一个不错的选择平台。我之前曾从事过 Java 和 C# 工作。欢迎任何意见、评论、建议。

谢谢, 加里

I am working on a web application which needs to get data from some local and some non local resources and then display it. As it could take arbitrary amount of time to get the data from these resources I am thinking of using the actors concept so that each actor is responsible for getting data from the respective resource. The request thread will wait for each actor to finish its task and then use ajax to update only the portion of the web page that is dependent on that data. This way user will start seeing the data as soon as it is received rather than wait for all of them to finish and then get a first look at the data.

I am planning to look into scala/lift framework for this. I have read some articles on the web for scala/lift and want to explore if this is the correct way to approach this problem and also if scala/lift is good platform of choice. I have worked in Java and C# previously. Any opinions, comments, suggestions are welcome.

Thanks,
gary

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

瑾夏年华 2024-08-18 21:37:21

看看像Java的JMS这样的消息队列技术。消息队列允许您异步且可靠地处理长时间运行的后台任务。这是 Flickr 和 YouTube 等网站用来异步进行媒体转码的技术。您可以使用 Java EE 服务器或 JMS 技术,例如 Apache 的 ActiveMQ,然后对 Scala/Lift 进行分层代码在它上面。

Richard Monson-Haefel 的关于 JMS 的书对此进行了很好的介绍。

有关网站扩展和构建的更多一般帮助,请查看 Todd Hoff 的优秀博客 highscalability.com/。有一些很好的指导可以帮助您以这种方式使用消息队列来卸载长时间运行的任务。

顺便说一句,Twitter 使用 Scala 来完成与您正在考虑的事情非常相似的事情。这是对他们的一些开发人员的采访;他们描述了一种使用 Scala 的方式:

Robey Pointer:我们的很多架构都是基于让 Rails 做它最擅长的事情,即 AJAX、Web 前端、网站——用户所看到的。我们可以从请求/响应周期中卸载任何东西。因此,我们将这些任务排队到消息系统中,并让后端守护进程处理它们。

Take a look a message queue technology like Java's JMS. Message queues allow you to handle long running background tasks asynchronously and reliably. This is the technique sites like Flickr and YouTube use to do media transcoding asynchronously. You can use a Java EE server, or a JMS technology like Apache's ActiveMQ, and then layer your Scala/Lift code on top of it.

Richard Monson-Haefel's book on JMS covers it well.

For more general help with web site scaling and construction, take a look at Todd Hoff's excellent blog, highscalability.com/. There are some good pointers to using message queues to offload long-running tasks this way.

BTW, Twitter uses Scala for something much like what you're considering. Here's an interview with some of their developers; they describe one way they use Scala:

Robey Pointer: A lot of our architecture is based on letting Rails do what it does best, which is the AJAX, the web front ends, the website—what the user sees. Anything we can offload out of the request/response cycle, we do. So we queue those tasks into a messaging system and have back-end daemons handle them.

茶花眉 2024-08-18 21:37:21

如果非本地资源源自某些其他服务或系统,事件驱动架构可能适合您。您可以将此 Web 应用程序设置为这些服务发布的事件的订阅者,而不是从非本地资源中获取。收到有关其部分功能的消息后,它将在本地缓存其感兴趣的数据。这应该可以让您避免页面部分异步更新的问题(所有数据都可以在本地访问)。

Udi Dahan 发表了很多有关此方法的博客,同时也是 .NET 消息总线的作者 (NServiceBus)就可以在此类场景中使用。请参阅示例 http://msdn.microsoft.com/en-us/architecture /aa699424.aspx

If the non-local resources originate at some other service or system, Event Driven Architecture might work for you. Instead of pulling from the non-local resources you could set up this web-application as a subscriber to the events published by these services. Upon receiving a message regarding part of its functionality it would cache locally the data it's interested in. This should let you escape the issue of asynchronous update of parts of the page (all data would be accessible locally).

Udi Dahan blogs about this approach a lot and is also an author of a .NET message bus (NServiceBus) that can be used in such scenarios. See for example http://msdn.microsoft.com/en-us/architecture/aa699424.aspx

素罗衫 2024-08-18 21:37:21

演员将是一条路要走。您实际上是在设置 JMS 的轻量级版本。 Lift 很好地完成了彗星的任务。
除了 Scala Actor 和 Lift Actor 之外,您还有 akka Actor。当 Scala Swarm 准备好投入生产时,您也将做好准备。

Actors would be a way to go. You're essentially setting up a light weight version of JMS. And Lift does the comet stuff very well.
In addition to the Scala actors, and the Lift Actors, you also have akka actors. When Scala Swarm becomes production ready you'll be ready for that too.

好听的两个字的网名 2024-08-18 21:37:21

如果延迟的信息与需要立即显示的信息不同,则通过 Lift,您可以使用 LazyLoad 代码片段,该代码片段将运行时间较长的计算(调用 Web 服务)作为其逻辑的一部分。准备好后,Lift 将负责将其插入页面中。

If the delayed information is distinct from the information that needs to display immediately, with Lift you can use a LazyLoad snippet that has the longer-running computation (calling the web service) as part of its logic. Lift will take care of inserting it into the page when its ready.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文