Web Services Platform Architecture [Electronic resources] : SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Web Services Platform Architecture [Electronic resources] : SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More - نسخه متنی

Steve Mills

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







9.2. Future Directions


WS-MetadataExchange is a public specification offered under royalty-free terms. It likely will be submitted to a standards organization to undergo formal standardization. It's difficult to predict the outcome of that process, but some of the limitations of the current specification should be eliminated. Following are three of the changes that you might expect as this process proceeds forward.

  • Support for multidialect and multi-identifier requests The current specification allows you to request all the metadata for an endpoint or to restrict it to a single dialect or identifier. This seems like an unnecessary limitation. Allowing you to request metadata from multiple dialects would provide additional control for requesters over the returned metadata.

  • Multiprotocol access Currently, there is no mechanism to bootstrap metadata exchange interactions in the most generic case unless the default protocol binding is assumed to apply. In many situations, other protocols need to be used, however. Dealing with this limitation would likely require WS-Addressing support.

  • Mechanisms for identifying support for WS-MetadataExchange in WSDL service descriptions It's assumed that service endpoints support WS-MetadataExchange in addition to their business interfaces. This fact needs to be clearly specified in the WSDL description of the service; a mechanism to do so will need to be defined. (Although adding a port to the service definition is straightforward, it's probably not the most convenient approach from the usability perspective.)



    / 149