ما هي أفضل الممارسات في تحديد الصابون الخدمة (عام مقابلعملية محددة)?

Question

وضعي على النحو التالي:

لدي تطبيع قاعدة البيانات التي أحمل المعلومات الجغرافية حول المطارات.هيكل هو:

airport --is in--> city --is in--> country --is in--> continent

الآن أريد أن السماح للمستخدمين تسجيل هذه البيانات ، دون منحهم إمكانية الوصول المباشر إلى قاعدة البيانات.نحن بحاجة إلى أن نقدم هذه واجهة الإدارة من خلال خدمة ويب.

الآن, عندما يتعلق الأمر إلى تصميم الخدمة ، ركضنا في النقاش حول كيفية تحديد العمليات.توصلنا إلى حلول مختلفة:

الحل A:عمليات محددة

لكل من الجداول الأربعة (المطار, المدينة, البلد, القارة) نحدد 3 عمليات:

• إدراج
• الحصول على
• التحديث

هذا من شأنه أن يؤدي إلى 12 2 طلب/استجابة الأجسام = 24 الكائنات

لخلق حالة جديدة كل مطار مع كل التبعيات ، على الأقل 4 طلبات من شأنه أن يكون ضروريا.

الحل ب:عامة

هناك واحد فقط من العملية التي يتم التحكم فيها عن طريق المعلمات.هذه العملية هو قادر على خلق كل ما يلزم لإدارة قاعدة البيانات.

العملية سوف يقرر ما يجب القيام به و تنفيذ ذلك.إذا كان خطأ occures ، فإنه سيتم استرجاع كل شيء.

==> 1 العملية = 2 معقدة للغاية طلب/استجابة الكائنات

الحل C:الالتقاء في منتصف الطريق 1

أحد العامة في عملية طاولة, التي هي قادرة على تنفيذ الحصول على insert, update, تماما مثل حل ب ، ولكنها ركزت على طاولة واحدة لكل منهما.

==> 4 عمليات = 8 المعقدة طلب/استجابة الكائنات

الحل:Dنلتقي في المنتصف 2

واحدة عامة عملية في العمل (على إدراج أو حذف) ، التي يمكن أن تعمل على كل طاولة وحل التبعيات.

==> 3 عمليات = 6 قليلا أكثر تعقيدا طلب/استجابة الكائنات

على سبيل المثال

لأن هذا كان بالأحرى مجردة ، هير مثال مبسط على طلب الكائنات لإنشاء (JFK/نيويورك/الولايات المتحدة/أمريكا الشمالية):

الحل A:

طلب 1/4:

<insertContinent>North America</insertContinent>

طلب 2/4:

<insertCountry continent="North America">USA</insertCountry>

طلب 3/4:

<insertCity country="USA">New York</insertCity>

طلب 4/4:

<insertAirport city="New York">JFK</insertAirport>

الحل ب:

طلب 1/1:

<action type="insertCountry" parent="North America">USA</action>
<action type="insertAirport" parent="New York">JFK</action>
<action type="insertContinent" parent="">North America</action>
<action type="insertCity" parent="USA">New York</action>

الحل C:

طلب 1/4:

<countryAction type="insert" parent="North America">USA</countryAction>

طلب 2/4:

<airportAction type="insert" parent="New York">JFK</airportAction>

طلب 3/4:

<continentAction type="insert" parent="">North America</continentAction >

طلب 4/4:

<cityAction type="insert" parent="USA">New York</cityAction >

الحل:D طلب 1/1:

<insert airport="JFK" city="New York" country="USA" continent="North America" />

حل د يبدو أنيقة إلى حد ما بالنسبة لي, لذلك حاولت أن تضع هذا في XSD:

كود:

<complexType name="NewContinent">
    <sequence>
        <element name="NAME" type="string"></element>
    </sequence>
</complexType>

<complexType name="NewCountry">
    <sequence>
        <element name="ISOCODE" type="string"></element>
        <element name="NAME" type="string"></element>
        <choice>
            <element name="newCONTINENT" type="tns:NewContinent"></element>
            <element name="CONTINENT" type="string"></element>
        </choice>
    </sequence>
</complexType>

<complexType name="NewCity">
    <sequence>
        <element name="IATA" type="string"></element>
        <element name="NAME" type="string"></element>
        <choice>
            <element name="COUNTRY" type="string"></element>
            <element name="newCOUNTRY" type="tns:NewCountry"></element>
        </choice>
    </sequence>

</complexType>

<complexType name="NewAirport">
    <sequence>
        <element name="IATA" type="string"></element>
        <element name="NAME" type="string"></element>
        <choice>
            <element name="CITY" type="string"></element>
            <element name="newCITY" type="tns:NewCity"></element>
        </choice>
    </sequence>

</complexType>

طلب المقابلة ثم تبدو على النحو التالي:

<complexType name="Request">
    <choice>
        <element name="AIRPORT" type="tns:NewAirport"></element>
        <element name="CITY" type="tns:NewCity"></element>
        <element name="COUNTRY" type="tns:NewCountry"></element>
        <element name="CONTINENT" type="tns:NewContinent"></element>
    </choice>
</complexType>

الآن سؤالي: هذا هو حقا أفضل الحلول المتاحة ؟ هو XSD بما فيه الكفاية لفهم ما يجري ؟

Answer 1

ويفترض كتابة بروتوكول طبقة من شأنها أن فهم مختلف أنواع الرسائل.سوف تحتاج أيضا تطبيق طبقة إلى تحليل محتويات الرسالة.المناهج المختلفة أذكر لكم سوف تحول عبء تحليل بين هاتين الطبقتين.لذلك على سبيل المثال:

حل:بروتوكول طبقة يفعل كل تحليل وإرجاع البيانات و الأوامر.طبقة التطبيق يمكن فقط استخدام البيانات.هذا هو المعروف أيضا باسم RPC نمط.

الايجابيات:يمكنك التحقق من صحة الرسائل الخاصة بك.يمكنك تعيين رسائل مباشرة إلى تطبيق المكالمات.

سلبيات:إذا كنت بحاجة إلى إجراء تغيير على واجهة البروتوكول الخاص بك التغييرات.

حل ب:بروتوكول طبقة عودة اثنين من القيم و أمر.تطبيق طبقة يجب استخدام الأمر إلى تحليل القيم إلى أنواع.

الايجابيات:البروتوكول لا يتغير أبدا.

سلبيات:لا يمكن التحقق من صحة الرسائل.رمز التطبيق الخاص بك هو أكثر تعقيدا.

حل ج:بروتوكول طبقة عودة اثنين من أنواع معروفة و الأوامر التي يجب تحليلها.تطبيق طبقة يمكن أن مجرد تحليل الأوامر واستخدام البيانات.

الايجابيات:لا أستطيع التفكير في أي يبدو ليست جيدة جدا وسط.

سلبيات:يترك تحليل جزئيا فقط القيام به.

الحل D:بروتوكول طبقة يعود أنواع معروفة (طريقة تنفيذه) و الأمر العام.طبقة التطبيق يجب أن ننظر في البيانات التي تتلقاها وتحويل الأمر العام في أمر معين.هذا هو على غرار بقية العمارة.

الايجابيات:المكالمات متميزة العمليات بحيث يمكن على سبيل المثال ذاكرة التخزين المؤقت على الردود.

سلبيات:التعقيد في طبقة التطبيق

باقي نموذج عادة ما تنفذ بشكل مختلف مما كنت قد حددت.ويستخدم HTTP GET, POST, وضع, حذف رسائل التواصل التعسفي الوثائق.المعلمات يتم إعطاء جزء من URL.لذلك على سبيل المثال:

<insert airport="JFK" city="New York" country="USA" continent="North America" />

يصبح

<insert URL="airport?city=Chicago">ORD</insert>

أو إذا كنت تستخدم HTTP يصبح طلب POST إلى مطار URL مع المعلمة المدينة مع محتويات يجري المعلومات حول المطار.علما أن بعض هذا يصبح أكثر وضوحا مع مزيد من compliated البيانات حيث لديك عدة عناصر و أنواع مختلطة.على سبيل المثال إذا أردت أن ترسل المطار اختصار اسم طويل و الارتفاع.

أعتقد أن بقية العمارة يمكن أن تعمل بشكل جيد جدا على واجهة تصفون.طالما كل ما عليك القيام به هو دعم عمليات الخام.فإن هناك العديد من المواقع التي تعطيك إيجابيات وسلبيات بقية النمط المعماري.

أنا شخصيا أفضل RPC نمط (حل) مع بعض بقية فول الصفات.أريد البروتوكول للقيام تحليل العمل و التحقق من صحة الرسائل.هذا هو عادة الناس كيف تنفذ الصابون خدمة ويب الواجهات.

واجهة الخاص بك قد تبدو بسيطة اليوم ولكن غدا واحد من الزبائن سوف يطلب منك مكالمة جديدة لا تتلاءم مع بقية نموذج جيدا و ستجد نفسك التوتيد في القائمة أربع رسائل.

Answer 2

هذا هو السؤال القديم, و أنا متأكد من الخدمة قد كتب منذ زمن طويل ، ولكن أردت أن تساهم إجابة على أي حال.

مريحة النهج لتحديد مطار الموارد مثل هذا:

<airport href="/airports/JFK">
    <name>JFK</name>
    <city>New York</city>
    <country>USA</country>
    <continent>North America</continent>
</airport>

أو إذا كنت ترغب في استخدام متصفح متوافق microformat:

<div class="object airport" href="/airports/JFK">
    <ul class="attributes"> 
        <li class="name">JFK</li>
        <li class="city">New York</li>
        <li class="country">USA</li>
        <li class="continent">North America</li>
    </ul>
</div>

هذا المورد يكون موجودا في URI مثل /airports/JFK, التي سيتم استردادها مع GET طريقة تحديث مع PUT طريقة حذف مع DELETE الأسلوب.

في تصميم مثل هذا ، URI /airports/ تمثل وعاء الموارد جميع المطارات في قاعدة البيانات ، محددات مثل /airports/?city=New+York و /airports/?country=USA سيكون المرشحات على الحاوية للعودة مجموعة فرعية من المطارات.أن يكون كل من هذه GET أساليب و الموارد تحتوي على قائمة من مطار الموارد كما هو محدد أعلاه ، إما في الكامل (منذ أنهم صغيرة) أو مع عدد قليل من سمات مفيدة ، href أن النقاط الكاملة من الموارد لكل مطار.

أخيرا, إضافة مورد جديد يمكن أن يكون إما PUT الطريقة على مطار الكامل URI ، أو POST طريقة /airports/.في كلتا الحالتين الجسم الطلب المطار الموارد كما هو مبين أعلاه.الفرق بين الطريقتين هو الذي يقرر النهائي URI المطار:العميل يقرر PUT والخدمة يقرر POST.واحد الذي تستخدمه يعتمد على ما إذا كان أو لا يمكن للعملاء الخاص بك تحديد معقول صحيح URI.عادة الخدمة تقرر لأن محددات تحتوي على رقمي المعرف الفريد والخدمة يجب أن تختار ذلك.

الآن بالطبع سؤالك الأصلي كان عن الصابون, عدم الراحة.أود أن والمضي قدما في اقامة مريحة تصميم ولقد وصفت, ثم وصف الموارد أنواع معقدة باستخدام XSD و الصابون الخدمة مع الإجراءات التي مكررة GET, PUT, DELETE, ، POST عمليات خدمة مريحة.هذا وسوف تعطيك RPC ما يعادل:

class Airport
    has String name
    has String city
    has String country
    has String continent
    method void update(name, city, country, continent)
    method void delete()

class AirportList
    method Airport[] get(opt name, opt city, opt country, opt continent)
    method void add(name, city, country, continent)