也就是说，RSS阅读器提供了由知识生产者到知识消费者之间的快捷通道。但是在RSS阅读器里，知识仍然是原有的知识，并不能通过知识消费者之间的互动而得到升华，因而RSS阅读器作为eLearning工具的作用也就甚为有限了。为什么这么说呢，先简单的扯一点理论。

社会建构主义学习观认为个人建构的、独有的主观意义和理论只有与社会、与物理世界“相适应”时，才有可能得到发展。因此，社会建构主义学习观强调意义的社会建构和学习的社会情境，强调社会互动、协作与活动等。从社会建构主义角度来看，知识不仅是个体在与物理环境的相互作用中建构起来的，而且社会性的相互作用对于知识的建构也同样重要，甚至更为重要。

基于上面的理论，只有当阅读器支持社会性互动，支持社会性知识建构，才能成为更有效的社会化学习工具。社会化也是目前大多数在线RSS阅读器的发展方向。
Google Reader 在社会化方面做了很多尝试，包括许多社会化方面的功能：

• 分享：包括对文章的分享，目录的分享，标签的分享以及把文章邮寄给好友等功能
• 评论：可对分享的文章进行评论
• Like: 与分享不同的地方在于Like对于所有人是可见的，从而为学习者提供了一种找到兴趣可能相同的人的方法
• Follow: 最初是订阅gtalk好友的分享，改成follow后范围大大扩大，而且是单向关系。

总的来说，这几个方面的功能都可归结为“分享”。其实，“分享”的过程可以看做是知识整理的过程，相当于无数的用户不断地在以人工的方式从Google Reader的巨大的内容库中挑选出有价值的知识。重要的是，这些知识是存在Google Reader里的，这本身就是一个财富。用户精挑细选互联网上的内容，加以评论和注释，帮助google构建了一个巨大的知识库。这个知识库又会吸引更多的人来使用Google Reader,他们之中又会有很多人参与“分享”活动，从而形成一个知识不断增长的“生态系统”。

从上面的分析来看，阅读器本身可以作为一个社会化的学习工具，且在社会化方面其实可以走得更远一些，比如围绕同种类型的知识形成学习圈子（因其小众，更容易形成同质的人群），更好地促进学习。

上面这幅图来自这篇文章：Mosh Pit as Innovation Model。

长期以来，知识是一种财富，掌握在少数人手中，很多“专家”乐此不疲的囤积知识，生怕别人偷走他们的想法。Web 2.0改变了这一切，我们可以看到，知识传播不在是少数知识所有者的专利，而是形成了一个知识网，每个人都可以成为知识分享者。

Karl Nelson提出了“开源知识（Open Source Knowledge）”的概念：“信息过时的速度是非常快的，特别是在技术领域，如果你将其存在你的头脑中不会产生什么价值，保存其价值的最好的办法是与他人共享你的知识 ”。

但是想真正使教育适应这一变化很难，这需要观念上的改变，教育本身就有一定的惰性，短时间内很难改变。但是对于那些出生于数字时代的小孩来说，他们都是数字原住民，他们习惯了网络，习惯了从网络上获取和分享。只是我们的老土教育还在束缚着他们。

Sakai有一个内核，负责提供公用的服务并且管理不同的组件。此外，还有一些独立的web应用来实现多种不同的功能，这些web彼此之间相互隔离，但是可以调用Sakai的公用服务。这一功能是通过Sakai自有的Component Manager机制实现的。

Component Manager

Component Manager负责将Sakai的各部分组装起来，它使得service之间能够通讯，并且各个web app能够使用这些service。在通常情况下，servlet 容器里的web应用是独立运行的，它们之间不能通讯，并且不能输出可共享的服务。Component Manager通过自定义ClassLoader的方式，提供了一些可共享的服务，以供各个web应用使用，同时，Sakai也提供了不用关闭整个服务而重启插件应用的方法。Sakai通过Component Manager来避开servlet容器的限制。Sakai里共享的服务API运行于servlet容器的特定位置，这个位置对所有的web应用可见。

与Component Manager功能相似的工业标准

Sakai的Component Manager是一个非标准实现，有两个实现类似功能的标准:

• EJB容器，有JBoss, Weblogic, Websphere等相关实现
• OSGI，有Apache felix, Eclipse Equinox等实现。Spring提供对于OSGI的支持，新版本3.0的组件都做成了OSGI bundle的形式。还有Sping DM项目对OSGI提供支持。

Component Manager的工作原理

Sakai的结构如下图所示：

在第一个web app启动时，Component Manager会随之启动。Component Manager为每一个component创建一个用来加载它的ClassLoader:

/**
 * Create the class loader for this component package
 *
 * @param dir
 *        The package's root directory.
 * @return A class loader, whose parent is this class's loader,
           which has the classes/ and jars for this component.
 */
protected ClassLoader newPackageClassLoader(File dir)
{
    // collect as a List, turn into an array after
    List urls = new Vector();

    File webinf = new File(dir, "WEB-INF");

    // put classes/ on the classpath
    File classes = new File(webinf, "classes");
    if ((classes != null) && (classes.isDirectory()))
    {
        try
        {
            URL url = new URL("file:" + classes.getCanonicalPath() + "/");
            urls.add(url);
        }
        catch (Throwable t)
        {
        }
    }

    // put each .jar file onto the classpath
    File lib = new File(webinf, "lib");
    if ((lib != null) && (lib.isDirectory()))
    {
        File[] jars = lib.listFiles(new FileFilter()
        {
            public boolean accept(File file)
            {
                return (file.isFile() && file.getName().endsWith(".jar"));
            }
        });

        if (jars != null)
        {
            for (int j = 0; j < jars.length; j++)
            {
                try
                {
                    URL url = new URL("file:" + jars[j].getCanonicalPath());
                    urls.add(url);
                }
                catch (Throwable t)
                {
                }
            }
        }
    }

    // make the array from the list
    URL[] urlArray = (URL[]) urls.toArray(new URL[urls.size()]);

    // make the classloader - my loader is parent
    URLClassLoader loader = new URLClassLoader(urlArray, getClass().getClassLoader());

    return loader;
}

Component的ClassLoader和每一个web应用有共同的父ClassLoader，这个父ClassLoader可以看见/WEB-INF/classes下的类，和所有/WEB-INF/lib/下的jar包。Component的ClassLoader和web应用的ClassLoader的行为很像，只是有一点不同，这个ClassLoader是标准的URLClassloader，它会首先委托自己的父ClassLoader来加载类，只有当父ClassLoader无法找到类时，才会自己的类路径下去寻找。而web应用的ClassLoader的行为和标准的ClassLoader的行为是不一样的，因为根据Servlet规范，web应用的ClassLoader需要首先寻找自己的类路径下的类和jar包，然后才会去寻找父ClassLoader的类路径。

从某种程度上来讲，任何社会性软件都可以做为eLearning工具，这取决于用户的使用方式。把twitter做为eLearning工具，就是要研究如何将twitter应用于具体的学习情境，比如课堂，学术会议，项目协做等。

eLearning Blog在这篇文章里有一些使用twitter的小技巧，并且提出了twitter做为eLearning工具的几个作用：

• 增加课堂质量。为课程起一个hashtag，让学生们在与课程相关的tweet里加上这个hashtag，方便课后讨论和作业情况追踪。
• 从学习者那里获取知识。学生的tweet可以增加学习内容的价值，并可使老师受益。
• 扩展你的个人网络。参见此文：Twitter: A Tool for Academia to Connect, Share, and Grow Relationships

对于twitter做为eLearning工具，Tony Karrerr的观点是：twitter是一种”flow learning”而不是”direct learning”，twitter不适合于那些社会化学习新手。

工具只是工具，虽然工具提供了手段，但是否能达到目的，取决于学习者对于社会化学习的理解和对于工具的熟练程度。

如果你对于“长尾”这个概念不熟悉，可以参照一下维基百科给出的定义，也可以看一下 getAbstracts的Abstract on Anderson’s The Long Tail。其基本观点可以由下面这个例子来说明，Amazon网上书店销售了大量在传统书店里甚至不能看到的书。当商品的流通，存储和生产的成本降低到一定程度时，销售那些相对冷门的产品就变为可能。存在长尾的市场更倾向于生产种类不断增长的大量产品，而只有一小部分产品位于头部。这种情况经常会发生，比如Yahoo或CNN这样的内容提供者就要和大量的个人博客竞争，电视台则要和Yutube这样的网站竞争。

由于每个人用来处理信息的时间是相同的，他们自然而然的要将时间分配到越来越广泛的领域，也就是所谓的注意力经济，在注意力经济里，稀缺资源不是分发渠道或者是信息，而是注意力，每个人所有的时间有限，只能关注那些重要的事情。这类似于将长尾图中的销售换成注意力。

对于学习组织和企业培训组织会产生的影响：

• 企业培训组织更像是内容的生产者和分发者；
• 知识工人面对正在增长的大量信息资源，企业学习只是其中的一小部分；
• 在信息的使用方面，金钱成本不再是一个主要考虑的因素，时间成本显得更加重要，比如，我们选择我们所喜欢的搜索引擎是因为我们认为它可以帮助我们在最短的时间内获取最有价值的信息；
• 信息源仍然在爆炸式的增长，企业培训组织做为传统的内容发布者只能满足一小部分需要；
• 如果我们不能吸引注意力，我们就会被逐渐边缘化，获得注意力比以前更加重要，并且需要比以前更多的努力，企业学习处于注意力危机之中；
• 企业学习组织正在寻找降低成本，扩大市场的方法——投入到长尾中去。他们需要e-Learning手段来降低内容分发成本； 企业学习组织如果要真正影响长尾，就必须面对eLearning 2.0 ；