本篇博文推荐给开发经理、系统架构师和系统设计人员，希望SE的设计思路可以对您有所帮助。
“每一个应用的诞生，都为了解决某些特定的问题。这就是应用系统的方向。”
问题带来需求，需求带来方向。好的架构师必须首先了解系统的需求，进而才能设计出合适的结构。这个世界上永远没有“最好”的架构，只有“最合适”的架构。向不了解需求就开始设计的架构师默哀吧。。因为这样设计出来的架构必将是失败的。
SE的方向：
- RIA应用。
- 即时通讯。
- 企业信息（类邮件）。
- 业务应用。
RIA应用：
- RIA应用类似与传统的C/S结构，应用系统中必须包含Client和Server。通讯底层将是系统的核心，可选方案有：WCF、RIAServices、Socket。
- WCF：Silverlight对WCF支持的不好，当时（SL 3.0）可选的协议都是基于HTTP的，通用性好但是性能低下、速度缓慢。。。无法达到对于系统高效的要求。
- RIAServices：Beta版本，很多都是不稳定的（就在几天前，2010年5月11日 RIAServices正式发布了1.0版本，并更名为WCF RIA Services，实际上起到数据访问的还是Asp.Net。）
- Socket：成熟的技术。基于TCP/IP，收发消息速度飞快~可以满足系统效率的要求。问题是Silverlight不支持Listener，无法运行监听端口，因此必须维护客户端到服务端的长链接。维护长链接的开销。。如何保证复杂环境下长链接的可用。。都是难点。。
即时通讯：
- 即时通讯在企业应用中非常的有用。SE是办公类软件，如果可以集成即时通讯，不但增强用户的粘度，更可将业务应用和即时通讯进行紧密的结合，创造出巨大的价值。
- 即时通讯的基本功能：好友列表、对话、多人对话、广播、文件。
- Silverlight不支持p2p，因此无法实现客户端之间的直接通信。所有的内容必须经由服务器转发，这会给服务器增加额外的压力。比较不一致的体验就是，局域网内的两个用户，传输文件也必须经由服务器中转，效率低下。
- Silverlight的UI相当于单一页面，收到消息的提示是个大问题。（这个问题在SL 4.0升级后得到了一定的解决，OOB时MainWindow和NotificationWindow还是很好用的！赞一个！！我们将在下一版SE 4.0中应用大量Silverlight 4.0的新特性~尽请期待！）
企业信息：
- 类邮件的系统很多的办公软件都有，但是到目前为止没有哪个应用系统的邮件体验可以达到网页版的Gmail、163或客户端的Outlook、Foxmail的水平。Silverlight给了我们一个机会，可以努力做到类似客户端的体验。
- 邮件是一套非常复杂的系统，如果全部实现不是一家小公司短时间内可以做到的。但是客户又要求满足这方面的需求，而且这也是办公最常用和最基本的形式。再难也要做。。
- 邮件基本功能：通讯簿、发出邮件、答复、全部答复、转发、收件人、抄送、附件、撤回。
- 撤回：必须要着重讲一下撤回功能，撤回功能在企业应用中有着非常重要的作用。但是目前任何一个邮件服务的撤回都是难以实现的，因为发出去的邮件就像泼出去的水。。再要收回来就比较难了。由于我们没有去做一个传统的邮件系统，而是自己实现了一套“类邮件”，反而在架构上拥有先天的优势，因此相对容易的实现了撤回功能。
- 存储、同步等。。都是难点。
业务应用：
- 业务应用。系统设计之初没有太多考虑应用实现的问题。业务应用的实现只是底线，如何将业务应用和即时通讯和企业信息相结合，才是SE系统最大的亮点。当时想不过来这些，摸着石头过河，业务应用就被暂缓考虑的。
通过对需求的分析，我们最终选定为：Socket（自己实现通讯和服务调用，相当于完整的WCF体系）、即时通讯（自己实现Silverlight中的“多窗口”，通讯内容全部基于服务器转发）、企业信息（基于服务器的类邮件系统，存储、同步、分发等功能都自己实现）、业务应用（由于即时通讯必须要求“多窗口”，因此业务的UI也一定是基于“窗口”的）。
最终我们确定了两套框架：基于Socket的底层通讯及服务调用框架和实现一套“多窗口”的UI框架。
SE第一次确定了“方向”。