क्यों वेब सेवा

Question

के रूप में होस्ट किए जाने पर डब्ल्यूसीएफ 'ठीक से' अमूर्त प्रकारों का उपभोग/खुलासा नहीं करता है, मैं हाल ही में वेब सेवाओं को डिजाइन कर रहा हूं लेकिन हाल ही में कभी भी 'जटिल' डब्ल्यूसीएफ सेवा का खुलासा नहीं करना पड़ा। मैं अमूर्त प्रकारों के लिए डब्ल्यूसीएफ में "उचित समर्थन" की स्पष्ट कमी पर परेशान था। सुनिश्चित करें कि - आप उनका उपयोग कर सकते हैं - सुनिश्चित करें कि आप उन्हें 'काम' के लिए प्राप्त कर सकते हैं ... तुम सिर्फ तुम क्या चाहते अंत नहीं है ...

पहली समस्या यह है कि अगर आप के साथ एक wsdl से कोड उत्पन्न एक अमूर्त प्रकार आपको बहुत अलग कोड मिलता है क्योंकि यह xmlserializer पर वापस आता है, न कि DataContractSerializer। यह स्पष्ट रूप से वांछनीय से थोड़ा सा है ... मैं फैंसी नए तेज़ धारावाहिक का उपयोग करना चाहता हूं, कृपया धन्यवाद ... (और सेवा/डेटाकंट्रैक्ट के साथ आने वाले सभी)

फ्लिप पक्ष पर - यदि आप पहले कोड से शुरू करें और एक वेब सेवा के रूप में एक उचित रूप से जिम्मेदार अमूर्त डब्ल्यूसीएफ कक्षा का पर्दाफाश करें, wsdl में "अमूर्त वर्ग" तकनीकी रूप से ठोस बनाने के लिए सार = "सत्य" विशेषता नहीं है ... यह वही नहीं है जो मैं चाहता हूं ..

मुझे एक कामकाज मिला है लेकिन इसमें 'हैकरी' की पागल राशि शामिल है जहां मैं पहले wsdl/xsd अनुबंध बना देता हूं, किसी भी सार = "सत्य" को हटा देता हूं (ओह - चलिए इसका उल्लेख नहीं करते कि मैं उपयोग नहीं कर सकता xsd में विशेषताएँ हम करेंगे) और फिर परिणाम svcuitl ... लेकिन अब मुझे एसी # एपीआई के साथ छोड़ दिया गया है जिसमें एक कंक्रीट अमूर्त वर्ग है और फिर मैं संशोधित करने की आवश्यकता है कि अमूर्त कीवर्ड को जोड़ने के लिए ... यह 'काम करता है' लेकिन यह एक विशाल पिटा है - और आसानी से 'स्क्रिप्ट योग्य' नहीं है ...

यह सब सिर्फ बेकार है! मुझे आशा है कि कोई मुझे स्पष्ट रूप से समझा सकता है कि 'क्यों' है ... मैं उन उत्तरों का स्वागत करता हूं जो "ठोस" संसाधनों का हवाला देते हैं लेकिन मैं वास्तव में व्यक्ति को बताने के लिए इंतजार कर रहा हूं - उचित दस्तावेज के साथ (जैसे अधिमानतः अच्छा ओएल डॉन बॉक्स खुद) क्यों यह वास्तव में है ... क्योंकि मुझे बस यह नहीं मिला ...

धन्यवाद सब - अगर कोई और विवरण चाहें - कृपया मुझे बताएं!

एक नमूना अनुरोध के अलावा के लिए अपडेट किया - सी # के साथ शुरू

[ServiceContract] 
public interface IShapeTest 
{ 
    [OperationContract] 
    AbsShape EchoShape(AbsShape shape); 
} 

public class ShapeTestImpl : IShapeTest 
{ 
    public AbsShape EchoShape(AbsShape shape) 
    { 
    return shape; 
    } 
} 

[KnownType(typeof(Square))] 
public abstract class AbsShape 
{ 
    [DataMember] 
    public int numSides; 
} 

public class Square : AbsShape 
{ 
    public Square() : base() 
    { 
    numSides = 4;//set the numSides to 'prove' it works 
    } 
} 

अपेक्षित प्रकार:

<xs:complexType name="AbsShape" abstract="true"> <!--NOTE abstract="true"--> 
    <xs:sequence> 
    <xs:element minOccurs="0" name="numSides" type="xs:int"/> 
    </xs:sequence> 
</xs:complexType> 

वास्तविक उत्सर्जित प्रकार:

<xs:complexType name="AbsShape"> <!--NOTE the lack of abstract="true"--> 
    <xs:sequence> 
    <xs:element minOccurs="0" name="numSides" type="xs:int"/> 
    </xs:sequence> 
</xs:complexType> 

Answer 1

खैर यह क्योंकि WCF नहीं करता है ऑब्जेक्ट पास करें, यह संदेश पास करता है। यह रिमोटिंग नहीं है, इसलिए क्लाइंट पर समाप्त होने वाला प्रकार आपके जैसा सर्वर पर नहीं है - यह केवल विभिन्न गुणों के लिए एक होल्डिंग क्लास है। कार्यान्वयन "अमूर्त =" सत्य "बस कोई समझ नहीं आता है। संदेश केवल डेटा हैं - क्लाइंट को कैसे पता चल जाएगा कि आप किस प्रकार का ठोस उपयोग कर सकते हैं, क्योंकि आप कक्षाओं को साझा नहीं कर रहे हैं, लेकिन बस संदेश का प्रतिनिधित्व करते हैं।

Answer 2

" सार "एक कार्यान्वयन विस्तार है। इसकी सेवा अनुबंध में कोई जगह नहीं है। स्वाभाविक रूप से, जैसे ही आप जोर देते हैं कि आपके कॉलर को पता होना चाहिए कि आप एक अमूर्त प्रकार लौट रहे हैं, डब्ल्यूसीएफ को एक धारावाहिक पर वापस आना चाहिए जो इस तथ्य का पर्दाफाश कर सकता है: और आप 'XmlSerializer के साथ फंस किया जा रहा करने के लिए वापस फिर से

मैं तुम्हें सार का उपयोग कर रहे हैं, क्योंकि कि OO जिस तरह से चीजें करना है संदेह है लेकिन तुम OO नहीं कर रहे हैं, तो आप वेब सेवाओं कर रहे हैं -।।। एसओए वहाँ एक अंतर है

Answer 3

इस प्रश्न का आधार यह है कि डब्ल्यूसीएफ को एक एक्सएसडी कॉम्प्लेक्स टाइप टाइप को एक सार तत्व के साथ एक सी # अमूर्त वर्ग के रूप में सत्य के रूप में चिह्नित करना चाहिए।यदि आप WSDL spec on future extensibility, देखते हैं तो आप इस उदाहरण को देखेंगे कि कैसे स्पेस इस तत्व को एक्सएसडी सुविधा का उपयोग करता है ताकि "तत्व आइटम" को जोड़ने के बिना WSDL spec को संशोधित करने की आवश्यकता हो।

एक्सएसडी सार विशेषता का उद्देश्य अन्य एक्सएसडी "प्रकारों" को आधार प्रकार से परिभाषाओं का वारिस करने की अनुमति देना है। ऐसा लगता है कि @dovholuk क्या करने के लिए डब्ल्यूसीएफ की तलाश में है, लेकिन वास्तव में यह एक्सएसडी प्रकार परिभाषा के लिए एक उपकरण है। इस एक्सएसडी फीचर में सी # कक्षा संरचनाओं में एक्सएमएल के क्रमिकरण पर कोई असर नहीं पड़ता है क्योंकि इसका उपयोग एक्सएसडी परिभाषाओं के भीतर किया जाना है। तो @blowdart & @ जोहान सैंडर्स दोनों का संक्षेप में, डब्ल्यूसीएफ संदेश विनिमय पर एक अमूर्त है, जिसकी एक्सएसडी-आधारित प्रकार परिभाषा एक कार्यान्वयन विस्तार है।

Answer 4

उपयोग [XmlSerializerFormat] सार प्रकार पर गुण

Answer 5

विशेषता "सार = सच" एक प्रकार की विरासत के साथ ही डबल्यूएसडीएल जब आप जावा ईई का उपयोग में संरक्षित है। ऑब्जेक्ट मॉडल में "अमूर्त" या "विस्तार" जैसे पारंपरिक जावा कीवर्ड का कोई भी उपयोग डब्लूएसडीएल और एक्सएसडी में संरक्षित है। कोई विशेष विशेषता या मैंगलिंग आवश्यक नहीं है।

डब्ल्यूसीएफ सेवाएं डब्लूएसडीएल में अमूर्त विशेषता उत्पन्न करने में असफल रही। डब्लूसीएफ भी ऑब्जेक्ट मॉडल विरासत को पार करने में विफल रहता है, जिसके लिए डब्ल्यूएसडीएल में उचित एक्सएसडी विरासत के परिणामस्वरूप ज्ञात टाइप टाइप की आवश्यकता होती है।

डब्ल्यूसीएफ क्लाइंट्स एक सेवा से डब्लूएसडीएल से अमूर्त प्रकार उत्पन्न करेंगे जो किसी प्रकार के सार के साथ-साथ किसी भी प्रकार के लिए विरासत को संरक्षित रखेगा (विज़ुअल स्टूडियो में "सेवा संदर्भ" का उपयोग करके जावा ईई में क्लाइंट स्थापित करने के लिए उदाहरण के लिए सेवा)।

तो डब्ल्यूसीएफ क्लाइंट प्रॉक्सी के लिए डब्लूएसडीएल में परिभाषित अमूर्त प्रकारों का सम्मान करता है लेकिन यह डब्लूएसडीएल सृजन के लिए सेवा में अमूर्त प्रकार नहीं बनाता है (शायद कुछ खास ध्यान के बिना, विरासत के लिए आवश्यक ज्ञात प्रकार की विशेषता)।