IBM的Kyle Brown在其评论文章开始描述了一种常见的情景:“许多人因以不恰当的方式使用Web服务和XML而给他们自己挖了一个坑”。在他的评论中,Kyle介绍了三个常见的痛点,解释了它们为何会发生并提供了一些替代方法。
我的消息吃了我的服务器!Kyle指出,通常,Web服务开发者开始经历“内存溢出”的错误或者奇怪的“性能问题”时,总是会发现服务器拥有极高的处理负载,CPU使用率接近100%,以及较低的吞吐量和高网络延迟。导致这些症状的典型原因是非常大的(有时会达到50 MB或者更大)消息。而且,这些大消息往往包含了非常大的、作为XML消息主体的、采用base-64编码的二进制编码信息。导致其发生的原因通常是:
……开发者不理解技术的局限性:XML处理对解决许多问题都有用, |
Kyle建议采用如下方法来改善这种情况:
不要发送冗余信息。在许多情况下,发送二进制数据时,你可能会 在XML消息体中,根本不要嵌入二进制信息。这是较好的解决方法, ……还有一个更好的办法,使用SOAP根本不发送大的二进制blob。 |
不好意思,你的数据正在显示。根据Kyle所说,另一个典型的Web服务的“性能问题” 是,使用Web服务的层面非常、非常低——通常Web服务跟一个SQL语句相关,这是因为:
误解了SOA架构原则。一个优秀SOA架构的关键原则是你的服务 |
根据Kyle所说,这些情况通常发生在:
……如果设计是根据现有代码“自上而下”衍生出服务,这类服务 相反,在SOA架构的正确位置使用粗粒度的Web服务会更好。再次 |
模式(Schema)?我们不需要任何发臭的模式! Kyle指出,通常开发者试图重用现有代码来生成和解析作为Web服务实现基础的XML。这些实现通常使用XML解析器来编组/解组消息,同时使用Java HTTP类来发送和接收XML文档。使用Web服务时,通用的方法是,创建使用模式元素的WSDL文档,使XML不受阻地通过,然后在现有代码中对它们进行解析。
这个问题的症状是组织没有看到SOA承诺的好处,而且维护他们的 |
简单的解决方案是,每当写Web服务时,不管使用WS-*标准还是使用REST方法,都要确保你创建了代表你文档结构的完整准确的XML模式。
如果你正在构建WS-* Web服务,那么这个XML应该被包含 |
避免Kyle描述的陷阱似乎是个常识。不幸的是,我们的业界证明了,除非很好的理解和治理SOA实现,否则我们会继续一次又一次地重复犯同样错误。
【编辑推荐】