使用xml來傳遞訊息會給您的應用程式帶來許多好處：通過它您可以利用大量的api、跨平台支援、以及用來描述和操縱xml（例如xquery，xslt，xpath和xml schema）的通用工具。你不想關心的許多細節問題也可以由xml來處理——比如行結束、字元編碼、結構化資料和分界——這使您只需將精力集中於您的應用程式。由於上述所有的原因，能使用xml是非常好的。
儘管用xml來傳遞訊息存在巨大優勢，但是其缺點是效能問題：由於xml的設計方式，有些資料型別不能很好的與xml整合。由於xml是基於文字的形式，最顯著的是二進位制資料（即不能被表示為unicode字符集的任何東西）。
開發人員要做什麼呢？
使用url引用
最容易的解決辦法就是在你的xml中不包括這樣的資料，而是像html中使用url那樣在web上引用它。例如，如果你的應用程式的訊息需要包含乙個人的jpeg，那麼帶有嵌入式鏈結的xml可能如下所示：
如果資料是長時間穩定且對訊息的接收者而言是可用的，這種方式能夠發揮很好的作用。然而，如果資料是短暫的，或者資料的接收者沒有連線到web，這就不是乙個好的解決辦法。為了處理這些情況，資料必須隨著訊息進行傳送。
使用編碼
把二進位制的資料放入一條基於xml的訊息的最簡單的方法，就是使用類似base64的方式對其進行編碼，把它轉變成對xml 安全的一串字元（以及7位的mime傳輸，xml最初就是針對它設計的）。使用base64編碼，我們的xml 可能如下所示：
<?xml version='1.0' ?>
li4uymluyxj5igpwzwcgaw1hz2uuli4=
xml schema
定義了一種base64binary型別，這是一種足夠通用的方法，使您能夠照此識別已編碼的二進位制內容（它也定義一種hexbinary型別，這是乙個可選的編碼模式，但還不是很流行）。
這種編碼的不利方面是它的低效率；因為資料的二進位形式使用有限範圍的字符集來表示豐富的資料流，它通常比base64形式更簡潔。通常，對於給定的資料流，base64編碼會引入33%的冗餘尺寸，從而使xml訊息更大。
另外，對二進位制資料進行編碼和解碼會造成相當大的處理開銷，這反過來會影響使用它的應用程式的可擴充套件性和效能。
使用帶附件的soap訊息
這些問題促成了帶附件的soap訊息（
soap messages with attachments (swa)
）的開發。帶附件的soap訊息是一種特定於web services的技術，它使用mime multipart/related資料報來隨xml訊息傳送二進位制資料和其它附件，從而避免了編碼的開銷。用於我們的的乙個簡化的swa訊息可能如下所示：
content-type: multipart/related; boundary=mime_boundary; type=text/xml
--mime_boundary
content-type: text/xml; charset=utf-8
content-transfer-encoding: 8bit
<?xml version='1.0' ?>
--mime_boundary
content-type: image/jpeg
content-transfer-encoding: binary
content-id:
...binary jpeg image...
--mime_boundary--
我們可以看到，影象資料在乙個mime附件中。它是從帶有乙個cid（url）的soap訊息而被引用的，這個uri使用content-id mime頭的值來找到正確的附件。
這樣避免了編碼的開銷和冗餘，但是也帶來了一些新的問題。xml和web services的大部分價值在於使用generic xml工具來處理內容的能力——像xpat、xquery、xslt、xml 加密和數字簽名以及xml schema一樣。這些工具不處理非xml的內容；如果您想要對這些內容進行查詢、轉換、加密、簽名或者描述，您就需要使用一種不同的機制，甚至建立一種新的機制。
此外，由於swa還存在相當多的互操作性問題，以致於
ws-i
一直致力於研究（在寫作本文時）適合它們的特定的互操作性配置檔案。
實際上，帶有附件的soap訊息引進了一種新的訊息資料模型，因此，它不再是基於xml的訊息傳遞了。在2023年的早期，bea公司
和microsoft公司就開始關注並撰寫
關於這個問題的***
，並且開始探索其他可能的選擇。
mtom和xop的引入
在找出與swa相關的那些問題之後，我們開始研究制訂乙個具體的解決方案。這項工作從
proposed addendum to soap messages with attachments
（paswa）開始，並且w3c 的xml協議組（該組提出了soap 1.2）一直將它作為
message tran**ission optimization mechani**
（mtom）和
xml-binary optimized packaging
（xop）的規範加以研究。
上述內容背後的思想很簡單。 xop是xml的可選序列化方法，使您能夠將任何xml文件表示為xop資料報。在xop資料報裡，任何被命名為base64字串的事物都作為附件進行編碼，其方法與swa的方法非常相似。不過，資料和附件之間的鏈結不同：它不是依靠應用程式進行處理，而是由該格式自行處理。
例如，當我們文件在作為乙個xop資料報而被序列化時，可能如下所示：
content-type: multipart/related; boundary=mime_boundary; type=text/xml
--mime_boundary
content-type: text/xml; charset=utf-8
content-transfer-encoding: 8bit
<?xml version='1.0' ?>
xmlns:xbinc="...">
href="cid:[email protected]"/>
--mime_boundary
content-type: image/jpeg
content-transfer-encoding: binary
content-id:
...binary jpeg image...
--mime_boundary--
從xml觀點來看，該文件與上面的base64版本同構；也就是說，其中任何一種都可以編碼為另外一種，而不會造成資訊的丟失。與swa不同，xop使用xbinc:include元素顯式地將內容與正確的附件關聯起來，並避免了swa中存在的許多歧義性。它也保持xml 訊息的資料模型；因為它只是xml的一種可選編碼，實際上，可以將附件中的二進位制內容視為xml自身中的base64編碼的資料。
xop是乙個通用的機制；我們能用它來序列化任何種類的xml。在soap中
，mtom使xop序列化和反序列化成為可能，這是http繫結的擴充套件。隨著其他繫結被定義出來，它們也將包含xop支援。
從api角度來看，xop隱含著一些有趣的內容。如果乙個xml棧能夠理解xop編碼，那麼您的應用程式就根本不需要改變；例如，當它需要訪問時，它仍然能夠將所獲得內容的字元值看作base64編碼字串。如果xop正在使用中，那麼該實現可以即刻自動將其編碼。
這就能夠將xop透明地逐步部署到應用程式中，但是並不能產生期望的效能收益。為了產生期望的效能收益，應用程式需要通過使棧顯式地為它執行base64編碼和解碼來訪問二進位制內容的值空間，而不是詞法空間。
實際上，這相當容易做到。為了相容xop，需要用一種簡單方法來擴充套件xml api，從而訪問值空間。例如，
sax定義了characters()方法來處理字元資料，包括我們的元素。通過定義一種新方法——例如binary() 方法，自動地對base64編碼的內容進行合適的解碼，
或者當xbinc:include 存在時，取消對附件的引用。應用程式可以更容易地實現由xop提供的收益。
當我們考慮型別感知api，（像
xml beans
）時，事情變得更有意思了。因為它提供了訪問xml 內容的詞法空間和值空間的方法，所以有可能在類似xop的型別感知編碼中進行無形的分層。
1 6 理解相機和準備攝像附件
裝置 影象解析度 畫素 感測器對角線 mm 焦距 mm 對角視場 度 最大孔徑 mm iphone 4 2592x1936 5.68 3.85 72.8 f 2.8 iphone 4s 3264x2448 5.68 4.28 67.1 f 2.4 iphone 5,5c 3264x2448 5.68...
Web Services 摘要資訊
標準化是制約技術發展的乙個重要因素，也是人們在經歷了大量的異構 不相容問題後的深切體會。目前，eai 是企業進行資訊化改造的主要方法。web services 技術建立在標準性與開放性基礎之上。傳統的安全認證 訪問控制體系結構框架的不一致性使得整個安全認證 訪問控制體系的標準化難以得到控制。服務是封...
Remoting與Web Services的區別
概括的說remoting與web services的區別是 1 既支援tcp通道又支援http通道，傳輸速度快 2 即可傳輸xml的soap包又可傳輸二進位製流，效率高 3 remoteing主要用於c s結構專案 4 不一定要依賴iis伺服器 其實現的原理並沒有本質的區別，在應用開發層面上有以下區...