SOA框架下如何传递文件？

千锤万击 2014-04-05 11:38:37
加精
直接读文件，然后把文件内容封装进xml传递吗？
...全文
3983 32 打赏 收藏 转发到动态 举报
写回复
用AI写文章
32 条回复
切换为时间正序
请发表友善的回复…
发表回复
以专业开发人员为伍 2014-07-11
  • 打赏
  • 举报
 回复
引用 6 楼 difstone 的回复:
[quote=引用 3 楼 caozhy 的回复:] soa是一个务虚的概念，你该怎么做还怎么做。
其实我就是想问，传递文件时，是直接将文件内容封装到soap消息中发送；还是只发送文件url，然后接收端再以ftp形式下载？[/quote] 这是根据你的需要而决定的，这两种都是非常直观普通的方法，不要因为非要符合什么“SOA架构”这类空名词儿而找不着北了。 选择技术方式，需要你自己亲自测试，得到自己的数据支持。而不是抄别人的概念。
千锤万击 2014-07-11
  • 打赏
  • 举报
 回复
我现在的解决办法是这样的，将web服务部署在服务器端，使用AXIS2/C的服务器。客户端发送调用请求，服务器端计算完成后会生成一些结果文件，然后将下载地址返回给客户端。客户端再通过FTP协议下载结果文件。 不知道有没有比这更好的方法？
风之影子 2014-05-22
  • 打赏
  • 举报
 回复
到网上去查一下，关于WS或是WCF上传下载文件的贴子。 不要一直想着简单对象访问的概念。
铜臂阿铁木 2014-05-22
  • 打赏
  • 举报
 回复
我推荐外挂tcp或者直接挂http协议去发送文件。 WCF也有自带的nettcpbinding 走byte比stream要好。
dereck123 2014-05-10
  • 打赏
  • 举报
 回复
引用 22 楼 super_admi 的回复:
百度：http://baike.baidu.com/subview/21305/5033544.htm?fr=aladdin 维基：http://zh.wikipedia.org/wiki/SOA 概念： 面向服务的体系结构（Service-OrientedArchitecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。 我的理解： SOA只是一个概念上的东西，所以3楼版主说这是一个“务虚”的概念。你可以把它理解成为一种基本规则，或者指导思想：凡是符合这种规则或者思想的具体实现，都可以称之为SOA。 所以，如Web Service, servlet什么的，都可以认为是一个简单的SOA实现。 SOA的重点应该是两个词：服务，接口。它所期待的，应该是不论什么需求，不论此需求在什么平台，不论此需求在什么地方，不论此需求什么时候提出，都可以通过一个通用的接口，得到服务器上提供的服务。 所以你常看到SOA中XML横行，这是因为XML是和具体平台具体实现无关的文本格式的信息规范定义。其实我在实际使用中，更喜欢用JSON。 以上是个人的理解，不足之处，请指教。 [quote=引用 21 楼 qmpy321 的回复:] [quote=引用 1 楼 wyd1520 的回复:] SOA是啥玩意
同问。。[/quote][/quote] 补充一下： SOA 数据传输协议有很多，甚至可以自己定义，SOAP协议只是其中一种。 内容有很多种格式，就看你的协议是怎么定的，其实任何数据在网络上传输的时候都是二进制，不过因为格式进行了一次转换，那么应用层用的时候才会有xml,json之分
宇宙最强皮皮虾 2014-05-09
  • 打赏
  • 举报
 回复
gzhcdz 2014-05-08
  • 打赏
  • 举报
 回复
学习了
Devin_Mao 2014-05-08
  • 打赏
  • 举报
 回复
FTP协议不行吗
bwangel 2014-05-07
  • 打赏
  • 举报
 回复
文件是字节流，还是老老实实用HTTP POST方式比较稳妥。
super_admi 2014-05-07
  • 打赏
  • 举报
 回复
百度：http://baike.baidu.com/subview/21305/5033544.htm?fr=aladdin 维基：http://zh.wikipedia.org/wiki/SOA 概念： 面向服务的体系结构（Service-OrientedArchitecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。 我的理解： SOA只是一个概念上的东西，所以3楼版主说这是一个“务虚”的概念。你可以把它理解成为一种基本规则，或者指导思想：凡是符合这种规则或者思想的具体实现，都可以称之为SOA。 所以，如Web Service, servlet什么的，都可以认为是一个简单的SOA实现。 SOA的重点应该是两个词：服务，接口。它所期待的，应该是不论什么需求，不论此需求在什么平台，不论此需求在什么地方，不论此需求什么时候提出，都可以通过一个通用的接口，得到服务器上提供的服务。 所以你常看到SOA中XML横行，这是因为XML是和具体平台具体实现无关的文本格式的信息规范定义。其实我在实际使用中，更喜欢用JSON。 以上是个人的理解，不足之处，请指教。
引用 21 楼 qmpy321 的回复:
[quote=引用 1 楼 wyd1520 的回复:] SOA是啥玩意
同问。。[/quote]
糖三豆 2014-05-06
  • 打赏
  • 举报
 回复
引用 1 楼 wyd1520 的回复:
SOA是啥玩意
同问。。
ccnyou 2014-05-06
  • 打赏
  • 举报
 回复
我记得是 SOAP 是将文件 Base64 之后嵌入到 xml 里面的
guojing6512 2014-05-06
  • 打赏
  • 举报
 回复
ZHEGE 这个不知道，啊 ，一年
寂寞是在想你的时候 2014-05-05
  • 打赏
  • 举报
 回复
magicluo 2014-05-05
  • 打赏
  • 举报
 回复
SOA不等于Web Service. 如果你们的应用都已经接口服务化了，并且服务的实现技术是基于Web Service. 那么你可以考虑使用支持附件的Web Service技术，如MTOM哈。。 你为什么要将文件序列化编码为XML文档呢？不解。 SOA中文件传输，可以考虑FTP或者MQ
五更琉璃 2014-05-05
  • 打赏
  • 举报
 回复
就这玩应 也能推荐
wanghui0380 2014-05-05
  • 打赏
  • 举报
 回复
额，stream可以，byte[]可以，你甚至可以base64了当字符串也可以
claregang 2014-05-05
  • 打赏
  • 举报
 回复
大家好，我是czg
sandaoliuge 2014-05-05
  • 打赏
  • 举报
 回复
什么意思呢。。。。。
真闹挺真的假的 2014-05-05
  • 打赏
  • 举报
 回复
同求结果啊+1
加载更多回复（10）
一个进程间通讯同步的C#框架引荐
0.背景简介 微软在 .NET 框架中提供了多种实用的线程同步手段，其中包括 monitor 类及 reader-writer锁。但跨进程的同步方法还是非常欠缺。另外，目前也没有方便的线程间及进程间传递消息的方法。例如C/S和SOA，又或者生产者/消费者模式中就常常需要传递消息。为此我编写了一个独立完整的框架，实现了跨线程和跨进程的同步和通讯。这框架内包含了信号量，信箱，内存映射文件，阻塞通道，及简单消息流控制器等组件。这篇文章里提到的类同属于一个开源的库项目（BSD许可），你可以从这里下载到 www.cdrnet.net/projects/threadmsg/. 这个框架的目的是：   
领域驱动设计与模式实战
第一部分 背景知识 第1章 应重视的价值，也是对过去几年的沉重反思 1.1 总体价值 1.2 应重视的架构风格 1.2.1 焦点之一：模型 1.2.2 焦点之二：用例 1.2.3 如果重视模型，就可以使用领域模型模式 1.2.4 慎重处理数据库 1.2.5 领域模型与关系数据库之间的阻抗失配 1.2.6 谨慎处理分布式 1.2.7 消息传递很重要 1.3 对过程的各个组成部分的评价 1.3.1 预先架构设计 1.3.2 领域驱动设计 1.3.3 测试驱动开发 1.3.4 重构 1.3.5 选择一种还是选择组合 1.4 持续集成 1.4.1 解决方案（或至少是正确方向上的一大步） 1.4.2 从我的组织汲取的教训 1.4.3 更多信息 1.5 不要忘记运行机制 1.5.1 有关何时需要运行机制的一个例子 1.5.2 运行机制的一些例子 1.5.3 它不仅仅是我们的过错 1.6 小结 第2章 模式起步 2.1 模式概述 2.1.1 为什么要学习模式 2.1.2 在模式方面要注意哪些事情 2.2 设计模式 2.3 架构模式 2.3.1 示例：层 2.3.2 另一个示例：领域模型模式 2.4 针对具体应用程序类型的设计模式 2.5 领域模式 2.6 小结 第3章 TDD与重构 3.1 TDD 3.1.1 TDD流程 3.1.2 演示 3.1.3 设计效果 3.1.4 问题 3.1.5 下一个阶段 3.2 模拟和桩 3.2.1 典型单元测试 3.2.2 声明独立性 3.2.3 处理困难因素 3.2.4 用测试桩替换协作对象 3.2.5 用模拟对象替换协作对象 3.2.6 设计含义 3.2.7 结论 3.2.8 更多信息 3.3 重构 3.4 小结 第二部分 应用DDD 第4章 新的默认架构 4.1 新的默认架构的基础知识 4.1.1 从以数据库为中心过渡到以领域模型为中心 4.1.2 进一步关注DDD 4.1.3 根据DDD进行分层 4.2 轮廓 4.2.1 领域模型示例的问题/特性 4.2.2 逐个处理特性 4.2.3 到目前为止的领域模型 4.3 初次尝试将UI与领域模型挂接 4.3.1 基本目标 4.3.2 简单UI的当前焦点 4.3.3 为客户列出订单 4.3.4 添加订单 4.3.5 刚才我们看到了什么 4.4 另一个维度 4.4.1 领域模型的位置 4.4.2 孤立或共享的实例 4.4.3 有状态或无状态领域模型实例化 4.4.4 领域模型的完整实例化或子集实例化 4.5 小结 第5章 领域驱动设计进阶 5.1 通过简单的TDD实验来精化领域模型 5.1.1 从Order和OrderFactory的创建开始 5.1.2 一些领域逻辑 5.1.3 第二个任务：OrderRepository+OrderNumber 5.1.4 重建持久化的实体：如何从外部设置值 5.1.5 获取订单列表 5.1.6 该到讨论实体的时候了 5.1.7 再次回到流程上来 5.1.8 总览图 5.1.9 建立OrderRepository的伪实现 5.1.10 简单讨论一下保存 5.1.11 每个订单的总量 5.1.12 历史客户信息 5.1.13 实例的生命周期 5.1.14 订单类型 5.1.15 订单的介绍人 5.2 连贯接口 5.3 小结 第6章 准备基础架构 6.1 将POCO作为工作方式 6.1.1 实体和值对象的PI 6.1.2 是否使用PI 6.1.3 运行时与编译时PI 6.1.4 PI实体/值对象的代价 6.1.5 将PI用于存储库 6.1.6 单组存储库的代价 6.2 对保存场景的处理 6.3 建立伪版本机制 6.3.1 伪版本机制的更多特性 6.3.2 伪版本的实现 6.3.3 影响单元测试 6.4 数据库测试 6.4.1 在每次测试之前重置数据库 6.4.2 在测试运行期间保持数据库的状态 6.4.3 测试之前重置测试所使用的数据 6.4.4 不要忘记不断演变的模式 6.4.5 分离单元测试和数据库调用测试 6.5 查询 6.5.1 单组查询对象 6.5.2 单组查询对象的代价 6.5.3 将查询定位到哪里 6.5.4 再次将聚合作为工具 6.5.5 将规格用于查询 6.5.6 其他查询选择 6.6 小结 第7章 应用规则 7.1 规则的分类 7.2 规则的原则及用法 7.2.1 双向规则检查：可选的（可能的）主动检查，必需的（和自动的）被动检查 7.2.2 所有状态（即使是错误状态）都应该是可保存的 7.2.3 规则应该高效使用 7.2.4 规则应该是可配置的，以便添加自定义规则 7.2.5 规则应与状态放在一起 7.2.6 规则应该具有很高的可测试性 7.2.7 系统应阻止我们进入错的状态 7.3 开始创建API 7.3.1 上下文，上下文，还是上下文 7.3.2 数据库约束 7.3.3 将规则绑定到与领域有关的转换，还是绑定到与基础架构有关的转换 7.3.4 精化原则：所有状态，即使是错误状态，都应该是可保存的 7.4 与持久化有关的基本的规则API的需求 7.4.1 回到已发现的API问题上 7.4.2 问题是什么 7.4.3 我们允许了不正确的转换 7.4.4 如果忘记检查怎么办 7.5 关注与领域有关的规则 7.5.1 需要合作的规则 7.5.2 使用基于集合的处理方法 7.5.3 基于服务的验证 7.5.4 在不应该转换时尝试转换 7.5.5 业务ID 7.5.6 避免问题 7.5.7 再次将聚合作为工具 7.6 扩展API 7.6.1 查询用于设置UI的规则 7.6.2 使注入规则成为可能 7.7 对实现进行精化 7.7.1 一个初步实现 7.7.2 创建规则类，离开最不成熟的阶段 7.7.3 设置规则列表 7.7.4 使用规则列表 7.7.5 处理子列表 7.7.6 一个API改进 7.7.7 自定义 7.7.8 为使用者提供元数据 7.7.9 是否适合用模式来解决此问题 7.7.10 复杂规则又是什么情况 7.8 绑定到持久化抽象 7.8.1 使验证接口成为可插入的 7.8.2 在保存方面实现被动验证的替代解决方案 7.8.3 重用映射元数据 7.9 使用泛型和匿名方法 7.10 其他人都做了什么 7.11 小结 第三部分 应用PoEAA 第8章 用于持久化的基础架构 8.1 持久化基础架构的需求 8.2 将数据存储到哪里 8.2.1 RAM 8.2.2 文件系统 8.2.3 对象数据库 8.2.4 关系数据库 8.2.5 使用一个还是多个资源管理器 8.2.6 其他因素 8.2.7 选择和前进 8.3 方法 8.3.1 自定义手工编码 8.3.2 自定义代码的代码生成 8.3.3 元数据映射（对象关系（O/R）映射工具） 8.3.4 再次选择 8.4 分类 8.4.1 领域模型风格 8.4.2 映射工具风格 8.4.3 起点 8.4.4 API焦点 8.4.5 查询风格 8.4.6 高级数据库支持 8.4.7 其他功能 8.5 另一个分类：基础架构模式 8.5.1 元数据映射：元数据的类型 8.5.2 标识字段 8.5.3 外键映射 8.5.4 嵌入值 8.5.5 继承解决方案 8.5.6 标识映射 8.5.7 操作单元 8.5.8 延迟加载/立即加载 8.5.9 并发控制 8.6 小结 第9章 应用NHibernate 9.1 为什么使用NHibernate 9.2 NHibernate简介 9.2.1 准备 9.2.2 一些映射元数据 9.2.3 一个小的API示例 9.2.4 事务 9.3 持久化基础架构的需求 9.3.1 高级持久化透明 9.3.2 持久化实体的生命周期所需的特定特性 9.3.3 谨慎处理关系数据库 9.4 分类 9.4.1 领域模型风格 9.4.2 映射工具风格 9.4.3 起点 9.4.4 API焦点 9.4.5 查询语言风格 9.4.6 高级数据库支持 9.4.7 其他功能 9.5 另一种分类：基础架构模式 9.5.1 元数据映射：元数据类型 9.5.2 标识字段 9.5.3 外键映射 9.5.4 嵌入值 9.5.5 继承解决方案 9.5.6 标识映射 9.5.7 操作单元 9.5.8 延迟加载/立即加载 9.5.9 并发性控制 9.5.10 额外功能：验证挂钩 9.6 NHibernate和DDD 9.6.1 程序集概览 9.6.2 ISession和存储库 9.6.3 ISession、存储库和事务 9.6.4 得到了什么结果 9.7 小结 第四部分 下一步骤 第10章 博采其他设计技术 10.1 上下文为王 10.1.1 层和分区 10.1.2 分区的原因 10.1.3 限界上下文 10.1.4 限界上下文与分区有何关联 10.1.5 向上扩展DDD项目 10.1.6 为什么对领域模型——SO分区 10.2 SOA简介 10.2.1 什么是SOA 10.2.2 为什么需要SOA 10.2.3 SOA有什么不同 10.2.4 什么是服务 10.2.5 服务中包括什么 10.2.6 深入分析4条原则 10.2.7 再来看一下什么是服务 10.2.8 OO在SOA中的定位 10.2.9 客户-服务器和SOA 10.2.10 单向异步消息传递 10.2.11 SOA如何提高可伸缩性 10.2.12 SOA服务的设计 10.2.13 服务之间如何交互 10.2.14 SOA和不可用的服务 10.2.15 复杂的消息传递处理 10.2.16 服务的可伸缩性 10.2.17 小结 10.3 控制反转和依赖注入 10.3.1 任何对象都不是孤岛 10.3.2 工厂、注册类和服务定位器 10.3.3 构造方法依赖注入 10.3.4 setter依赖注入 10.3.5 控制反转 10.3.6 使用了Spring.NET框架的依赖注入 10.3.7 利用PicoContainer.NET进行自动装配 10.3.8 嵌套容器 10.3.9 服务定位器与依赖注入的比较 10.3.10 小结 10.4 面向方面编程 10.4.1 热门话题有哪些 10.4.2 AOP术语定义 10.4.3 .NET中的AOP 10.4.4 小结 10.5 小结 第11章 关注UI 11.1 提前结语 11.2 模型-视图-控制器模式 11.2.1 示例：Joe的Shoe Shop程序 11.2.2 通过适配器简化视图界面 11.2.3 将控制器从视图解耦 11.2.4 将视图和控制器结合起来 11.2.5 是否值得使用MVC 11.3 测试驱动的Web窗体 11.3.1 背景 11.3.2 一个示例 11.3.3 领域模型 11.3.4 GUI的TDD 11.3.5 Web窗体实现 11.3.6 小结 11.3.7 用NMock创建模拟 11.4 映射和包装 11.4.1 映射和包装 11.4.2 用表示模型来包装领域模型 11.4.3 将表示模型映射到领域模型 11.4.4 管理关系 11.4.5 状态问题 11.4.6 最后的想法 11.5 小结 11.6 结束语 第五部分 附录 附录A 其他领域模型风格 附录B 已讨论的模式的目录
基于WCF构建企业级大型分布式SOA架构(初级篇)
好消息：基于WCF构建企业级大型分布式SOA架构(中级篇)的源码开放下载了，可以向老师索取或者查看最后一个课时下载 下载即可获得如下大礼包：企业级大型分布式SOA框架源码 + 模板网站实践项目源码 + 框架工具、资料 + 初级篇全套源码、视频 学.Net WCF——当架构师 轻松就业 前途无限 掌握高端技术、迈进高收入行列 .Net都是谁在用？——微软、腾讯、网易、戴尔、当当网、携程、招商银行、中国知网、申通快递、房天下、汽车之家等。微软在软件行业的龙头老大位置没有任何人能够否认，它总是站在开发技术的前沿。如今微软正高举.NET大旗继续向前，他正努力使开发变得更加轻松。 学习目标  1、让学员熟练掌握WCF的核心概念及相关编程技能，对WCF技术有一个全面的、深入的、系统的了解；  2、让学员对SOA架构设计的思想和方式具有初步的认识, 对后期我们将要学习的SOA架构有一个宏观的了解;  3、让学员通过完整的示例的学习, 能够熟练搭建开发环境, 服务构建，服务配置，服务调试、服务单元测试， Restful服务的编写, 客户端代理的编写、各种应用程序中消费使用服务等;  4、通过项目实战让学员达到1-3年工作经验水平。达到.NET软件工程师，.Net/C#研发工程师、中高级工程师等岗位所需技能; 课程简介 专注15年C#/.Net开发、科研，在多个中大型企业中负责过多个中大型项目的架构设计、开发、实施部署，积累丰富的研发及实践经验，为Net学习者快速掌握.Net企业级开发常用技术及架构，录制本视频课程系列(分为初级篇，中级篇，高级篇三大课程），采用实战项目从0开始一步步讲授如何搭建项目架构及分析各技术的优劣，提供系统/示例完整源码（价值高）及详细上课日志，及时为您解惑答疑，让课程价值无限; 无论您是Java、C++、Python还是其它语言的开发者，都可以学习本系列课程，因为这种架构设计思想和方式对任何语言来说是一样的，只是实现的技术、语言不一样而已;纯干货，含金量高，价格实惠，物超所值 ，配套的项目架构源码等均能直接应用于实际项目开发中;        课程特色        1:课程设计循序渐进，讲解细致，通俗易懂，由浅入深, 非常适合自主学习;        2:以PPT为大纲，教学过程示例丰富，强调技术关键点，并且分析透彻;先概念后示例再应用实践；        3:物美价廉，本着知识共享，帮助更多有需求者原则，毫无保留，此外，提供源代码/示例代码+课程资料+课程相关工具; 本课程示例程序解决方案 SOA架构部署图(中级篇) SOA架构特色(中级篇) SOA架构解决方案(中级篇) 与SOA架构配合开发的Web实战项目解决方案(中级篇) 教学理念        1:把需要工作的人变成工作需要的人;        2:创设立足学员，突出项目，强化技术，提高能力的教学局面; 注意 1.开发环境VS2015、Eclipse、Sql Server 2008R2; 2.赠送配套资料：详细注释的示例项目源码、详实的讲义等; 3.由初级篇—中级篇—高级篇,建议按顺序一节节学习，一节节理解;从而快速实现架构师之梦;
（十六）.net之SOA-WebService
SOA-WebService
SOA架构
文章目录基于SOA架构核心模块和中间件详解系统间通信分布式文件服务器缓存搜索功能消息队列反向代理主从备份 基于SOA架构 SOA：Service Oriented Architecture面向服务的架构。也就是把工程都拆分成服务层工程、表现层工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。工程都可以独立部署。 在一个典型的SO...
Web Services

12,162

社区成员

16,328

社区内容

发帖
与我相关
我的任务
社区描述
.NET技术 Web Services
社区管理员
  • Web Services社区
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章