BÁO cáo tìm HIỂU về PARLAY

1 HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG BÁO CÁO TÌM HIỂU VỀ PARLAY X HỌ VÀ TÊN: ĐỖ ĐỨC CƯỜNG TRỊNH VĂN ANH TRẦN TUẤN ANH PHẠM VĂN DÙNG LỚP : M12CQCT01-B Hà Nội - Năm 20113 Parlay X Web Dịch vụ Multimedia Messaging API 66.1 Giới thiệu về Parlay X hoạt động nhắn Các phần sau đây mô tả ngữ nghĩa của mỗi hoạt động hỗ trợ cùng với các chi tiết thực hiện cụ thể cho Parlay X Gateway. Các bảng sau đây, mô tả các thông số thông báo đầu vào / đầu ra cho mỗi hoạt động, được lấy trực tiếp từ X đặc điểm kỹ thuật xiên. Oracle người dùng dịch vụ nhắn thực hiện một tập hợp con của X 2.1 đặc điểm kỹ thuật nhắn đa phương tiện xiên. Đặc biệt Oracle người dùng dịch vụ nhắn hỗ trợ các giao diện SendMessage và ReceiveMessage. Các MessageNotification và MessageNotificationManager giao diện không được hỗ trợ. 66,2 Gửi tin nhắn giao diện Giao diện SendMessage cho phép bạn gửi tin nhắn đến một hoặc nhiều địa chỉ người nhận bằng cách sử dụng các SendMessagehoạt động, hoặc có được tình trạng giao hàng cho một tin nhắn gửi trước đó bằng cách sử dụng các hoạt động getMessageDeliveryStatus. Các yêu cầu sau đây áp dụng: • Một địa chỉ người nhận phải phù hợp với yêu cầu định dạng địa chỉ của Oracle người dùng dịch vụ nhắn (ngoài việc có một URI hợp lệ). Định dạng chung là delivery_type : protocol_specific_address , chẳng hạn như email: hướng @ miền , sms: 5551212 hoặc im: người dùng @ jabberdomain . • Một số nhân vật không được phép vào các URI, nếu nó là cần thiết để đưa vào một địa chỉ họ có thể được mã hóa hoặc thoát. Tham khảo các javadoc cho java.net.URI để biết chi tiết về cách tạo một URI mã hóa đúng cách. • Trong khi các WSDL xác định rằng địa chỉ người gửi có thể là bất kỳ chuỗi, Oracle người dùng dịch vụ Nhắn tin yêu cầu rằng họ có địa chỉ nhắn hợp lệ. • Oracle người dùng dịch vụ nhắn yêu cầu bạn xác thực địa chỉ người gửi trên một loại cơ sở cho mỗi giao hàng. Vì vậy, cho địa chỉ người gửi để áp 2 dụng cho một người nhận một loại giao hàng nhất định, nói EMAIL, địa chỉ người gửi cũng phải có loại giao EMAIL. Từ hoạt động này cho phép nhiều địa chỉ người nhận nhưng chỉ có một địa chỉ người gửi, địa chỉ người gửi chỉ áp dụng cho người nhận với các loại giao hàng tương tự. • Oracle người dùng dịch vụ nhắn không hỗ trợ giao diện MessageNotification, và do đó không xuất trình biên lai giao hàng, ngay cả khi một receiptRequest được chỉ định. Nói cách khác, các tham số receiptRequest được bỏ qua. 66.2.1 SendMessage hoạt động Bảng 66-1 mô tả mô tả thông báo cho sendMessageRequest đầu vào trong SendMessage hoạt động. Bảng 66-1 SendMessage vào tin nhắn mô tả Phần Tên Phần Loại Tùy chọn Mô tả địa chỉ XSD: anyURI [0 không bị chặn] Không Địa chỉ đích cho tin nhắn này. senderAddress xsd: string Vâng Nhắn địa chỉ người gửi. Tham số này không được phép cho tất cả các nhà cung cấp bên thứ 3. Các Parlay X máy chủ phải xử lý này theo một SLA cho các ứng dụng cụ thể và do đó việc sử dụng nó có thể dẫn đến một PolicyException. Tiêu đề xsd: string Vâng Tựa đề. Nếu ánh xạ tới tin nhắn SMS, tham số này được sử dụng như các senderAddress, ngay cả khi một senderAddress riêng biệt 3 Phần Tên Phần Loại Tùy chọn Mô tả được cung cấp. ưu tiên MessagePriority Vâng Ưu tiên của tin nhắn. Nếu không có mặt, mạng gán ưu tiên dựa trên các nhà điều hành policy.Charging để áp dụng cho tin nhắn này. sạc chung: ChargingInformation Vâng Sạc để áp dụng cho tin nhắn này. receiptRequest chung: SimpleReference Vâng Xác định các thiết bị đầu cuối ứng dụng, tên giao diện và tương quan được sử dụng để thông báo cho các ứng dụng khi tin nhắn đã được gửi đến một thiết bị đầu cuối hoặc nếu giao hàng là không thể. Bảng 66-2 mô tả sendMessageResponse thông điệp đầu ra cho các Sendmessage hoạt động. Bảng 66-2 sendMessageResponse ra tin mô tả Phần Tên Phần Loại Tùy chọn Mô tả kết quả xsd: string Không Định mối tương quan này được sử dụng trong một hoạt động gọi getMessageDeliveryStatus thăm dò ý kiến cho tình trạng giao hàng của tất cả các tin nhắn được gửi. 4 66.2.2 getMessageDeliveryStatus hoạt động Các getMessageDeliveryStatus hoạt động được tình trạng giao hàng cho một tin nhắn được gửi trước đó. Đầu vào "requestIdentifier" là "kết quả" giá trị từ một hoạt động SendMessage. Đây là cùng một định danh được gọi là tin nhắn ID trong tài liệu hướng dẫn nhắn khác. Bảng 66-3 mô tả các getMessageDeliveryStatusRequest tin đầu vào cho các getMessageDeliveryStatus hoạt động. Bảng 66-3 getMessageDeliveryStatusRequest đầu vào tin nhắn mô tả Phần Tên Phần Loại Tùy chọn Mô tả registrationIdentifier xsd: string Không Định liên quan đến yêu cầu tình trạng giao hàng. Bảng 66-4 mô tả các thông điệp đầu ra getMessageDeliveryStatusResponse cho getMessageDeliveryStatus hoạt động. Bảng 66-4 getMessageDeliveryStatusResponse ra tin mô tả Phần Tên Phần Loại Tùy chọn Mô tả kết quả DeliveryInformation [0 không bị chặn] Vâng Một loạt các tình trạng của tin nhắn được gửi trước đó. Mỗi phần tử mảng đại diện cho một tin nhắn gửi, địa chỉ đích của nó và tình trạng giao hàng của nó. 5 66,3 Nhận được tin nhắn giao diện Giao diện ReceiveMessage có ba hoạt động. Các getReceivedMessages các cuộc thăm dò hoạt động của máy chủ cho bất kỳ tin nhắn nhận được từ việc gọi cuối cùng của getReceivedMessages . Lưu ý rằng getReceivedMessages không nhất thiết phải trả lại bất kỳ nội dung tin nhắn, nó thường chỉ trả về siêu dữ liệu tin nhắn. Hai hoạt động khác, getMessage và getMessageURIs , được sử dụng để lấy nội dung tin nhắn. 66.3.1 getReceivedMessages hoạt động Điều này hoạt động thăm dò máy chủ cho bất kỳ tin nhắn nhận được. Lưu ý các yêu cầu sau: • Tham số ID đăng ký là một chuỗi xác định địa chỉ thiết bị đầu cuối mà ứng dụng muốn nhận tin nhắn. Xem các cuộc thảo luận về giao diện ReceiveMessageManager để biết thêm chi tiết. • X đặc điểm kỹ thuật xiên nói rằng nếu các ID đăng ký không được xác định, tất cả các thông điệp cho ứng dụng này sẽ được trả lại. Tuy nhiên, WSDL cho biết các thông số ID đăng ký là bắt buộc. Do đó thực hiện của chúng tôi xử lý các chuỗi rỗng ("") là "không-quy định" giá trị. Nếu bạn gọi getReceivedMessages với chuỗi sản phẩm nào như ID đăng ký của bạn, bạn sẽ có được tất cả các thông điệp cho ứng dụng này. Vì vậy chuỗi sản phẩm nào không phải là một giá trị cho phép của ID đăng ký khi gọi startReceiveMessages. • Theo X đặc điểm kỹ thuật xiên, nếu nội dung tin nhắn nhận được là "văn bản ASCII thuần túy", sau đó nội dung tin nhắn được trả lại ngay bên trong các đối tượng MessageReference, và messageIdentifier (tin nhắn ID) phần tử là vô giá trị.Thực hiện của chúng tôi đối xử với bất kỳ nội dung với Content-Type "text / plain", và với mã hóa "us-ascii" như "văn bản ASCII thuần túy" cho các mục đích của hoạt động này. Theo các đặc điểm kỹ thuật định dạng, nếu không mã hóa được quy định, "us-ascii" được giả 6 định, và nếu không có Content-Type được chỉ định, "text / plain" được giả định. • Tham số ưu tiên hiện đang bị bỏ qua. Bảng 66-5 mô tả các getReceivedMessagesRequest tin đầu vào cho các getReceivedMessages hoạt động. Bảng 66-5 getReceivedMessagesRequest đầu vào tin nhắn mô tả Phần Tên Phần Loại Tùy chọn Mô tả registrationIdentifier xsd: string Không Xác định việc cung cấp bước off- line cho phép các ứng dụng để nhận được thông báo tiếp nhận tin nhắn theo các tiêu chuẩn quy định. ưu tiên MessagePriority Vâng Các ưu tiên của các tin nhắn để dò ý kiến từ Parlay X cổng. Tất cả các thông điệp của các ưu tiên quy định và cao hơn được lấy ra. Nếu không quy định, tất cả các thư sẽ được trả lại, có nghĩa là, giống như việc quy định "thấp". Bảng 66-6 mô tả các getReceivedMessagesResponse thông điệp đầu ra cho các getReceivedMessages hoạt động. Bảng 66-6 getReceivedMessagesResponse ra tin mô tả 7 Phần Tên Phần Loại Tùy chọn Mô tả registrationIdentifier xsd: string Không Xác định việc cung cấp bước off- line cho phép các ứng dụng để nhận được thông báo tiếp nhận tin nhắn theo các tiêu chuẩn quy định. ưu tiên MessagePriority Vâng Các ưu tiên của các tin nhắn để dò ý kiến từ Parlay X cổng. Tất cả các thông điệp của các ưu tiên quy định và cao hơn được lấy ra. Nếu không quy định, tất cả các thư sẽ được trả lại.Này bằng việc xác định thấp. 66.3.2 getMessage hoạt động Các getMessage hoạt động lấy nội dung tin nhắn, sử dụng một ID tin nhắn từ một lời kêu cầu trước của getReceivedMessages.Không có cơ quan SOAP trong tin nhắn trả lời, nội dung được trả lại như một tập tin đính kèm SOAP duy nhất. Bảng 66-7 mô tả các getMessageRequest tin đầu vào cho các getMessage hoạt động. Bảng 66-7 getMessageRequest đầu vào tin nhắn mô tả Phần Tên Phần Loại Tùy chọn Mô tả messageRefIdentifier xsd: string Không Danh tính của tin nhắn. Không có getMessageResponse thông điệp đầu ra cho các getMessage hoạt động. 8 66.3.3 getMessageURIs hoạt động Các getMessageURIs lấy nội dung tin nhắn như một danh sách các URI. Lưu ý các yêu cầu sau: • Các URI là URL HTTP có thể được dereferenced để lấy nội dung. • Nếu thông báo gửi vào có Content-Type của "nhiều phần dữ liệu", sau đó có nhiều URI trở lại, mỗi phần nhỏ. Nếu các Content-Type không phải là "chia", sau đó một URI duy nhất được trả về. • Theo các đặc điểm kỹ thuật X xiên, nếu các tin nhắn trong nước một phần nội dung văn bản, định nghĩa là "cơ thể thông báo nếu nó được mã hóa dưới dạng văn bản ASCII", nó được trả về ngay bên trong các đối tượng MessageURI. Đối với mục đích thực hiện của chúng tôi, bạn xác định hành vi này như sau: o Nếu tin nhắn của Content-Type là "text / *" (bất kỳ loại văn bản), và nếu tham số charset là "us-ascii", sau đó nội dung được trả về nội tuyến trong các đối tượng MessageURI. Không có URI trở lại vì không có nội dung khác so với những gì được trả về nội tuyến. o Nếu của tin nhắn Content-Type là "multipart /" (bất kỳ loại nhiều phần dữ liệu), và nếu một phần cơ thể đầu tiên của Content-Type là "text /" với ký tự "us-ascii", sau đó một phần được trả về nội tuyến trong các đối tượng MessageURI, và không có URI trả lại tương ứng với phần đó. o Theo các đặc điểm kỹ thuật MIME, nếu tham số ký tự bị bỏ qua, giá trị mặc định "us-ascii" được giả định. Nếu tiêu đề Content-Type không được chỉ định cho các thông báo, sau đó một Content-Type của "text / plain" được giả định. Bảng 66-8 mô tả các getMessageURIsRequest tin đầu vào cho các getMessageURIs hoạt động. Bảng 66-8 getMessageURIsRequest đầu vào tin nhắn mô tả 9 Phần Tên Phần Loại Tùy chọn Mô tả messageRefIdentifier xsd: string Không Danh tính của các tin nhắn để tải. Bảng 66-9 mô tả các getMessageURIsResponse thông điệp đầu ra cho các getMessageURIs hoạt động. Bảng 66-9 getMessageURIsResponse ra tin mô tả Phần Tên Phần Loại Tùy chọn Mô tả kết quả MessageURI Không Có chứa thông điệp hoàn chỉnh, bao gồm các phần văn bản của tin nhắn, nếu có như vậy, và một danh sách các tài liệu tham khảo cho các tập tin đính kèm tin nhắn, nếu có. 66,4 Oracle mở rộng để Parlay X nhắn Các đặc điểm kỹ thuật Parlay X nhắn để lại một số phần của dòng tin nhắn không xác định. Khu vực chính những gì còn lại không xác định là quá trình để ràng buộc một khách hàng đến một địa chỉ để tiếp nhận đồng bộ (thông qua giao diện ReceiveMessage). Oracle người dùng dịch vụ nhắn bao gồm một giao diện mở rộng để xâu X để hỗ trợ quá trình này. Việc gia hạn được thực hiện như một WSDL riêng biệt trong một Oracle XML không gian tên để chỉ ra rằng nó không phải là một phần chính thức của Parlay X. Khách hàng có thể chọn để không sử dụng giao diện bổ sung này hoặc sử dụng nó trong một số cách mô-đun như vậy mà tin nhắn logic lõi của họ vẫn còn đầy đủ phù hợp với đặc điểm kỹ thuật X xiên. 10 . THÔNG BÁO CÁO TÌM HIỂU VỀ PARLAY X HỌ VÀ TÊN: ĐỖ ĐỨC CƯỜNG TRỊNH VĂN ANH TRẦN TUẤN ANH PHẠM VĂN DÙNG LỚP : M12CQCT01-B Hà Nội - Năm 20113 Parlay X Web. rộng để Parlay X nhắn Các đặc điểm kỹ thuật Parlay X nhắn để lại một số phần của dòng tin nhắn không x c định. Khu vực chính những gì còn lại không x c định