คำถามติดแท็ก soa

หนึ่งในปัญหาสำคัญที่ฉันได้เห็นเกิดขึ้นในระบบที่มี microservices คือวิธีการทำธุรกรรมทำงานเมื่อพวกเขาครอบคลุมบริการที่แตกต่างกัน ภายในสถาปัตยกรรมของเราเองเราใช้ธุรกรรมแบบกระจายเพื่อแก้ไขปัญหานี้ แต่พวกเขามาพร้อมกับปัญหาของตนเอง โดยเฉพาะอย่างยิ่งการหยุดชะงักได้รับความเจ็บปวดจนถึงขณะนี้ ตัวเลือกอื่นน่าจะเป็นตัวจัดการทรานแซคชันที่กำหนดเองซึ่งรู้จักการไหลในระบบของคุณและจะดูแลการย้อนกลับสำหรับคุณในฐานะที่เป็นกระบวนการพื้นหลังซึ่งครอบคลุมทั่วทั้งระบบของคุณ (ดังนั้นมันจะบอกบริการอื่น ๆ และหากพวกเขาล้มเหลวให้แจ้งพวกเขาในภายหลัง) มีตัวเลือกอื่นที่ยอมรับหรือไม่ ทั้งคู่ดูเหมือนจะมีข้อเสีย คนแรกอาจทำให้เกิดการหยุดชะงักและปัญหาอื่น ๆ ได้ส่วนที่สองอาจส่งผลให้ข้อมูลไม่สอดคล้องกัน มีตัวเลือกที่ดีกว่านี้ไหม?

80 architecture  soa  microservices 

ฉันเพิ่งอ่านบทความที่ยอดเยี่ยมนี้ในสถาปัตยกรรม microservice: http://www.infoq.com/articles/microservices-intro มันระบุว่าเมื่อคุณโหลดหน้าเว็บใน Amazon แล้วไมโครไซต์กว่า 100 รายการจะร่วมมือเพื่อให้บริการหน้านั้น บทความนั้นอธิบายว่าการสื่อสารระหว่างไมโครไซต์ทั้งหมดสามารถทำได้ผ่าน API เท่านั้น คำถามของฉันคือเหตุผลที่ไม่ดีที่จะบอกว่าการเขียนฐานข้อมูลทั้งหมดสามารถทำได้ผ่าน API เท่านั้น แต่คุณสามารถอ่านได้โดยตรงจากฐานข้อมูลของบริการไมโครต่างๆ ตัวอย่างเช่นสามารถพูดได้ว่ามีเพียงไม่กี่มุมมองฐานข้อมูลที่สามารถเข้าถึงได้นอกบริการไมโครเพื่อให้ทีมที่ดูแลบริการไมโครรู้ว่าตราบใดที่พวกเขารักษามุมมองเหล่านี้เหมือนเดิมแล้วพวกเขาสามารถเปลี่ยนโครงสร้างฐานข้อมูลของบริการไมโคร ต้องการ. ฉันทำอะไรบางอย่างหายไปหรือเปล่า มีเหตุผลอื่นอีกไหมทำไมข้อมูลควรอ่านผ่าน API เท่านั้น? บริษัท ของฉันเล็กกว่า Amazon อย่างมาก (และจะเป็นเสมอ) และจำนวนผู้ใช้สูงสุดที่เราสามารถมีได้ประมาณ 5 ล้านคน

64 architecture  web-services  soa  microservices  modularization 

ทุกคนในปัจจุบันทำSOAแม้ว่าบางคนจะไม่เข้าใจสิ่งที่เป็นจริง ดังนั้นพวกเขาจึงทำผิด การใช้สิ่งนั้นเป็นการเปรียบเทียบฉันรู้ว่าRESTคืออะไร(หรืออย่างน้อยฉันก็คิดว่าฉันทำ) และต้องการทำบางอย่าง แต่ฉันต้องการที่จะทำมันถูกต้อง ดังนั้นคำถามของฉันคือวิธีที่เหมาะสมในการทำ REST คืออะไร

36 rest  soa  resources  implementations 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ฉันถูกถามในวันนี้ว่าฉันมีประสบการณ์กับ "Service Oriented Architecture" หรือไม่และฉันคิดว่าฉันทำ แนวคิดสำหรับฉันดูเหมือนสับสนมากฉันไม่รู้ว่าคุณจะตอบคำถามนั้นได้อย่างไร ฉันใช้คำว่า Googling ในความพยายามที่จะให้คำจำกัดความสั้น ๆ ของแนวคิดและความแตกต่างจากสถาปัตยกรรมอื่น ๆ หลังจากอ่านบทความจำนวนหนึ่งแล้วเธรดทั่วไปที่ฉันดูเหมือนจะสามารถค้นหาได้คือระบบที่มีองค์ประกอบหลายอย่างที่พูดคุยกันผ่านอินเทอร์เฟซบางชนิดซึ่งอาจมีความต้องการเล็กน้อยสำหรับ XML / SOAP ดูเหมือนว่าเกือบทุกแอปพลิเคชันสามารถกำหนดเป็น SOA ได้โดยเฉพาะแอปพลิเคชันบนเว็บ เทอมนี้ตกหลุมพราง "Web 2.0" และกลายเป็นคำที่มีความหมายไม่ว่าคุณต้องการให้มันหมายถึงอะไร? ฉันจะออกจากฐานที่นี่หรือไม่ เมื่อพวกคุณได้ยินคำนี้มันมีความหมายอะไรกับคุณไหม? ถ้าเป็นเช่นนั้นฉันจะชอบคำจำกัดความสั้น ๆ ที่แสดงให้เห็นอย่างชัดเจนว่าอะไรคืออะไรและไม่ใช่ SOA โดยเฉพาะ

25 terminology  soa 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ฉันยังใหม่ต่อการพัฒนาของ Workflow และฉันไม่คิดว่าฉันจะได้รับ "ภาพรวมขนาดใหญ่" หรือบางทีอาจจะพูดให้แตกต่างกันเครื่องมือเหล่านี้ไม่ได้ "คลิก" ในหัว ดังนั้นดูเหมือนว่า บริษัท ต้องการสร้างแบบธุรกิจเพื่ออธิบายกระบวนการและในบางคนตัดสินใจว่าพวกเขาสามารถใช้เครื่องสถานะเช่นโปรแกรมเพื่อควบคุมกระบวนการจากเส้นและกล่องเช่นไดอะแกรม สิบปีต่อมาเครื่องมือเหล่านี้มีขนาดใหญ่และซับซ้อนมาก (บริษัท ของฉันกำลังเล่นกับ WebSphere และฉันได้เข้าร่วมการฝึกอบรมเป็นสัตว์ประหลาดแม้กระทั่งเครื่องมือเวิร์กโฟลว์รุ่นที่เรียกว่า "minimalist" เช่น Activiti มีขนาดใหญ่และซับซ้อนแม้ว่าจะไม่ซับซ้อนเท่ากับสัตว์ร้ายที่เป็นของ WebSphere) อะไรเป็นประโยชน์อย่างมากในการทำเช่นนี้? ฉันสามารถเข้าใจไดอะแกรมเส้นและกล่องอย่างง่ายที่มีประโยชน์ แต่สิ่งเหล่านี้เท่าที่ฉันสามารถบอกได้ว่าเป็นภาษาการเขียนโปรแกรมแบบเห็นภาพ ณ จุดนี้พร้อมเงื่อนไขและลูป โปรแกรมเมอร์ที่นี่ดูเหมือนจะทำงานเป็นจำนวนมากในไลน์และเลเยอร์กล่องซึ่งสำหรับฉันแล้วดูเหมือนว่าจะเป็นภาษาการเขียนโปรแกรมเชิงภาพขั้นพื้นฐานจริงๆ หากคุณกำลังจะไปที่ไกลทำไมไม่ใช้ภาษาสคริปต์บางอย่าง? มีคนขว้างลูกน้อยออกไปด้วยการอาบน้ำหรือเปล่า? เส้นและกล่องถูกนำไปสู่ระดับที่ไร้สาระหรือฉันแค่ไม่เข้าใจคุณค่าทั้งหมดนี้หรือไม่? ฉันต้องการเห็นข้อโต้แย้งในการป้องกันเรื่องนี้โดยคนที่ทำงานกับเทคโนโลยีนี้และเข้าใจว่าทำไมมันถึงมีประโยชน์ ฉันไม่เห็นคุณค่าของมัน แต่ฉันรู้ว่าฉันใหม่กับสิ่งนี้เช่นกันและอาจยังไม่ได้รับมัน

22 java  workflows  soa  bpm 

สมมติว่าคุณกำลังมองหาการแยกแอปพลิเคชันของคุณลงในบริการ มีเหตุผลที่ดีบ้างไหมในการนำแนวทาง SOA มาใช้กับการสร้างไลบรารี่ API ที่สามารถโหลดได้โดยแอพพลิเคชั่นที่ต้องการ

22 api  soa  services 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ในขณะที่เรียกดู SO วันนี้ฉันพบคำถามนี้ที่นี่และเริ่มด้วย: แน่นอนว่าคุณจะบอกฉันว่าสบู่ไม่ได้ให้ความสำคัญกับสิ่งใดเลยและฉันก็บังคับให้ใช้มัน พบคำแถลงมากมายเช่นนี้จนถึงตอนนี้อันนี้เพิ่งกระตุ้นให้ฉันถามคำถามนี้ REST มีการใช้งาน SOAP มีการใช้งานในบางสถานที่ที่พวกเขาตัดกันเป็นฟังก์ชันการทำงาน แต่ไม่สามารถใช้แทนกันได้ ดังนั้นฉันจึงสงสัยว่าทำไมผู้คนถึงคิดว่า SOAP นั้น "เลิกใช้แล้ว"? มันเป็นความไม่รู้? ความซับซ้อนของรายละเอียดของ SOAP และ WS- *? ส่วนที่เหลือ hype? อะไร? หากคุณคิดว่าเลิกใช้สบู่แล้วโปรดบอกฉันทีว่าทำไม ฉันอยากรู้!

20 web-services  soa  soap 

เบื้องหน้า เรากำลังเปลี่ยนจากแพลตฟอร์มเสาหินเป็นสถาปัตยกรรมที่เน้นการบริการมากขึ้น เราใช้หลักการ DDD ขั้นพื้นฐานมากและแยกโดเมนของเรากับบริบทที่แตกต่างกัน แต่ละโดเมนมีการกระจายและเปิดเผยบริการผ่านเว็บ API (REST) เนื่องจากลักษณะของธุรกิจของเราเรามีบริการเช่นการจอง , บริการ , ลูกค้า , ผลิตภัณฑ์ฯลฯ เรายังได้ติดตั้งเซิร์ฟเวอร์ข้อมูลประจำตัว (ขึ้นอยู่กับเซิร์ฟเวอร์ข้อมูลประจำตัวของ Thinktecture 3) ซึ่งมีบทบาทหลักคือ: การพิสูจน์ตัวตนจากศูนย์กลาง (ให้ข้อมูลรับรองว่ามันเป็นปัญหาโทเค็น) เพิ่มการอ้างสิทธิ์ในโทเค็นเช่น: ขอบเขตของลูกค้า (ตามลูกค้าฉันหมายถึงแอปพลิเคชันที่ทำการร้องขอ), ตัวระบุลูกค้า (ตามลูกค้าฉันหมายถึงบุคคลที่ใช้แอปพลิเคชัน) นอกจากนี้เรายังแนะนำบทบาทของAPI เกตเวย์ซึ่งเป็นศูนย์กลางการเข้าถึงจากภายนอกสู่บริการของเรา API Gateway มีฟังก์ชันที่ไม่ต้องการความรู้อย่างลึกซึ้งเกี่ยวกับโดเมนภายในเช่น: Reverse proxy: กำหนดเส้นทางคำขอที่เข้ามาในบริการภายในที่เหมาะสม การกำหนดเวอร์ชัน: เวอร์ชันของ API เกตเวย์จับคู่กับเวอร์ชันต่างๆของบริการภายใน การตรวจสอบความถูกต้อง: คำขอของลูกค้ารวมถึงโทเค็นที่ออกโดยเซิร์ฟเวอร์ประจำตัวและ API เกตเวย์ตรวจสอบโทเค็น (ตรวจสอบให้แน่ใจว่าผู้ใช้คือใครบอกว่าเธอเป็น) การควบคุมปริมาณ: จำกัด จำนวนการร้องขอต่อลูกค้า การอนุญาต สิ่งที่เกี่ยวข้องกับการอนุญาตนี้ไม่ได้รับการจัดการใน API …

19 api  microservices  soa  authorization 

ฉันต้องการรวม Spring Framework ในโครงการของฉันเข้ากับฝั่งเซิร์ฟเวอร์โดยเฉพาะ ดังนั้นฉันไม่ต้องการวางไว้ในโฟลเดอร์ WEB-INF ของไฟล์ war ฉันควรใส่ applicationContext.xml ไว้ในแต่ละเลเยอร์ (หมายถึงแต่ละโครงการตั้งแต่แบ่งเป็นโครงการที่แตกต่างกันหรือไม่ (Services, Domain และ DAO) การปฏิบัติที่ดีคืออะไร?

18 java  soa  spring 

เมื่อเร็ว ๆ นี้ฉันได้อ่านรูปแบบการรวมองค์กรของ Hohpe และ Woolf หนังสือของ Thomas Erl บางตัวเกี่ยวกับ SOA และดูวิดีโอและพ็อดแคสต์ต่างๆโดย Udi Dahan และคณะ บน CQRS และระบบขับเคลื่อนเหตุการณ์ ระบบในที่ทำงานของฉันต้องทนทุกข์ทรมานจากการมีเพศสัมพันธ์สูง แม้ว่าแต่ละระบบจะมีฐานข้อมูลเป็นของตนเองในทางทฤษฎี ในทางปฏิบัติหมายความว่ามีฐานข้อมูลขนาดใหญ่หนึ่งระบบที่ใช้ทั้งหมด ตัวอย่างเช่นมีข้อมูลลูกค้าหนึ่งตาราง สิ่งที่ฉันได้อ่านส่วนใหญ่ดูเหมือนว่าจะแนะนำข้อมูลที่ผิดปกติเพื่อให้แต่ละระบบใช้เฉพาะฐานข้อมูลของตน ฉันคิดว่านี่เป็นวิธีหนึ่งในการบังคับใช้ขอบเขตใน SOA - แต่ละบริการควรมีฐานข้อมูลของตัวเอง แต่จากนั้นฉันอ่านสิ่งนี้: /programming/4019902/soa-joining-data-across-multiple-services และมันบอกว่านี่เป็นสิ่งที่ผิดที่ต้องทำ การแยกฐานข้อมูลดูเหมือนจะเป็นวิธีที่ดีในการแยกระบบออก แต่ตอนนี้ฉันสับสนเล็กน้อย นี่เป็นเส้นทางที่ดีใช่ไหม เคยแนะนำหรือไม่ว่าคุณควรแยกฐานข้อมูลบนเปิดบริการ SOA บริบท DDD Bounded แอปพลิเคชัน ฯลฯ

17 soa  integration  cqrs  eai  domain-driven-design 

ฉันได้อ่านเกี่ยวกับบริการไมโครเมื่อไม่นานมานี้และนี่คือข้อสรุปบางอย่างที่ฉันได้รับ (โปรดแก้ไขฉันหากฉันผิดที่จุดใด) สถาปัตยกรรมบริการไมโครเป็นไปด้วยดีกับการออกแบบที่ขับเคลื่อนด้วยโดเมน โดยทั่วไปแล้วหนึ่ง MS หมายถึงบริบทที่มีขอบเขตหนึ่ง ถ้า micro-service Aต้องการฟังก์ชันที่อยู่ใน micro-service BโมเดลของฉันอาจผิดและAและB ควรเป็น micro-service / BC หนึ่งอัน การสื่อสารแบบซิงโครนัสระหว่างบริการไมโคร (คำขอ HTTP โดยตรง) ไม่ดีทำให้ขัดต่อวัตถุประสงค์ของบริการไมโครและแนะนำการมีเพศสัมพันธ์ระหว่างส่วนประกอบ การสื่อสารแบบอะซิงโครนัสระหว่างบริการเป็นที่ต้องการ บริการควรเผยแพร่กิจกรรมไปยังคิวข้อความเพื่อให้บริการอื่น ๆ สามารถสมัครและประมวลผลส่วนหนึ่งของเหตุการณ์หรือใช้เพื่อทำซ้ำส่วนของข้อมูลที่จำเป็นสำหรับบริบทของพวกเขา วิธีนี้บริการสามารถดำเนินการตามคำขอแม้บริการอื่น ๆ จะหยุดทำงานซึ่งไม่ได้เกิดขึ้นในการสื่อสารแบบซิงโครนัส ถ้า micro-service Aเผยแพร่เหตุการณ์, micro-service Bสมัครสมาชิกกับเหตุการณ์นั้นและสร้างเหตุการณ์ใหม่เป็นผลลัพธ์, micro-service Aไม่ควรเป็นการประมวลผลเหตุการณ์ที่สร้างขึ้นใหม่, ซึ่งจะเป็นการอ้างอิงแบบวงกลม ในกรณีนี้เราควรแนะนำบริการไมโครที่สามหรือรวมAและBเข้ากับบริการไมโครAB บริการไมโครเป็นจริงคำที่ทำให้เข้าใจผิด เราควรพยายามเพื่อบริบทขนาดเล็ก แต่ไม่จำเป็นต้องเป็นกรณี คำไม่ควรเป็น "บริการไมโคร" แต่ " ใหญ่พอที่จะทำงานบริการ " บริการไมโครช่วยให้เราสามารถแนะนำฟังก์ชั่นใหม่ได้อย่างง่ายดายและไม่ต้องกลัวว่าเราจะทำลายทั้งระบบ มันสามารถทำได้โดยการแนะนำบริการใหม่หรือ refactoring หนึ่งในที่มีอยู่ …

15 architecture  domain-driven-design  soa  microservices 

หนึ่งในหลักการออกแบบการบริการ SOA หลักคือหลักการบริการการรวมบริการ ( https://en.wikipedia.org/wiki/Service_composability_principle ) แนวคิดก็คือการสร้างบริการใหม่โดยใช้สิ่งที่มีอยู่เป็นหน่วยการสร้างจะสามารถพัฒนาบริการใหม่ได้อย่างรวดเร็ว ชนิดคล้ายกับวิธีที่คุณเรียกวิธีการที่มีอยู่ของวัตถุเมื่อคุณใช้วิธีการใหม่ นี่คือสิ่งที่การเพิ่มประสิทธิภาพการผลิตส่วนใหญ่จาก SOA ควรมาจาก มีคนทำสิ่งนี้จริงๆในทางปฏิบัติหรือไม่? ฉันได้เห็นสิ่งนี้ซ้ำไปซ้ำมาอย่างไม่มีที่สิ้นสุดในข้อความที่เป็นลายลักษณ์อักษร แต่ยังไม่เคยมีประสบการณ์การใช้งานจริงมาใช้ ข้อความส่วนใหญ่ไม่ได้กล่าวถึงการจัดการธุรกรรมใด ๆซึ่งดูเหมือนว่าฉันจะเป็นอุปสรรคที่ใหญ่ที่สุดในการตระหนักถึงบริการที่รวบรวมได้ ก่อนอื่นคุณต้องแก้ไขปัญหาการทำธุรกรรมก่อนที่จะสามารถเขียนบริการที่ไม่สำคัญ แน่นอนถ้าตัวอย่างมีบริการ "findCurrentTime ()" และ "writeLogMessage ()" มันง่ายที่จะไม่กังวลเกี่ยวกับการทำธุรกรรม แต่ไม่เมื่อมีตัวอย่างในโลกแห่งความจริงเช่น "depositMoney ()" และ "drawMoney () " ฉันรู้สองตัวเลือก: ใช้งานธุรกรรมจริงกับ WS-Atomic Transaction หรือ ใช้โซลูชันที่อิงตามค่าตอบแทนซึ่งชดเชยการเรียกไปยัง A ด้วย "CancA ()" หรือ somesuch หากการเรียกไปยัง B ล้มเหลว ทั้งสองอย่างดูมีปัญหามาก / ใกล้จะใช้ไม่ได้กับฉัน: ธุรกรรม …

15 web-services  soa  transaction 

ฉันกำลังสร้างแอปพลิเคชันใหม่และกำลังอ่านเกี่ยวกับสถาปัตยกรรมบริการไมโคร สถาปัตยกรรมเองนั้นมีความหมายอย่างมากจากมุมมองของการพัฒนาการปรับใช้และการจัดการวงจรชีวิต อย่างไรก็ตามปัญหาหนึ่งที่เกิดขึ้นคือเกี่ยวกับวิธีจัดการข้อมูลหลัก ตัวอย่างเช่นฉันมี 2 แอพ - พูดแอปขายและแอปจองตั๋ว สมมติว่าแอพทั้งสองนี้สร้างขึ้นเป็นบริการไมโครของตัวเอง อย่างไรก็ตามแอพทั้งสองนี้เมื่อมีการใช้งาน (สมมติว่ามีการใช้งานแยกกันว่า Sales ใช้ MongoDB และ Ticketing ใช้ MariaDB) จะต้องมีการเข้าถึงอินสแตนซ์ข้อมูลหลักเดียวกันเช่นบัญชีผลิตภัณฑ์ ซึ่งหมายความว่าจะมีแอปสำหรับเจ้าของข้อมูลเอนทิตีหลักที่กำหนด (เช่นบัญชีที่อาจเป็นแอปขาย) และผู้มีส่วนได้เสีย (เช่นแอปออกบัตรจะต้องมีข้อมูลเกี่ยวกับบัญชี) มีหลายวิธีที่สามารถทำได้: - การจำลองข้อมูลจากต้นแบบไปยังผู้มีส่วนร่วม - อ่านแบบซิงโครนัสจากฝ่ายที่สนใจไปที่ต้นแบบ (การพึ่งพาการซิงค์ไม่แนะนำโดยกระบวนทัศน์สถาปัตยกรรมไมโครบริการ) - พื้นที่เก็บข้อมูลส่วนกลาง แม้แต่ในบัญชีก็สามารถมีส่วนหลักซึ่งเป็นเรื่องปกติสำหรับทั้งการขายและการออกตั๋ว (เช่นชื่อบัญชีที่อยู่ ฯลฯ ) อย่างไรก็ตามบางแง่มุมของบัญชีอาจเกี่ยวข้องกับการขายเท่านั้นและอื่น ๆ ที่เกี่ยวข้องกับการออกตั๋วเท่านั้น ความคิด / แนวปฏิบัติที่ดีที่สุด / ความคิดเห็นเกี่ยวกับตัวเลือกใด ๆ ที่กล่าวถึงข้างต้น?

14 soa  services 

สถานที่ที่ฉันทำงานอยู่กำลังพยายามสร้างกฎพื้นฐานและการอภิปรายที่เรามีอยู่ในขณะนี้คือห้องสมุดท้องถิ่นและบริการเว็บสำหรับการใช้รหัสซ้ำ บริการบนเว็บดูเหมือนจะเป็นตัวเลือกยอดนิยมใน บริษัท ส่วนใหญ่และนั่นคือสิ่งที่นักพัฒนาส่วนใหญ่ที่นี่โน้มตัวเข้าหา ฉันไม่เห็นว่าคุณจะสามารถใช้บริการเว็บเพื่อการทำงานอย่างจริงจังได้อย่างไร ฉันจะเรียกใช้บริการหลาย ๆ สายอย่างปลอดภัยได้อย่างไรถ้าฉันไม่สามารถใช้งานธุรกรรมได้? สมมติว่าฉันมีงาน cron ที่คว้าลูกค้าจากฐานข้อมูลของเราที่ตรงตามเงื่อนไขที่พวกเขาต้องได้รับแจ้ง พวกเขาจะส่งแฟกซ์อีเมลและตั๋วถูกสร้างขึ้นเพื่อติดตามปัญหาภายใน นั่นคือ 3 การบริการที่แตกต่างกันซึ่งจะเกิดขึ้นสำหรับลูกค้าแต่ละรายในวง หากมีข้อผิดพลาดเกิดขึ้นที่ใดก็ตามในนั้นอาจเป็นไปได้ว่ามีการส่งแฟกซ์และอีเมลไปยังลูกค้า แต่ไม่มีการสร้างตั๋ว หรือแย่กว่านั้นงาน cron นี้อาจมีข้อผิดพลาดที่ทำให้มันล้มเหลวที่จุดเดียวกันทุกครั้งและมันซ้ำอีเมลลูกค้ารายเดียวกัน หากห้องสมุดเป็นท้องถิ่นทั้งหมดทุกอย่างก็จะถูกห่อด้วยธุรกรรมและจะไม่มีสิ่งใดเกิดขึ้น แต่เราใช้บริการเว็บในตัวอย่างนี้ โปรดทราบว่าวิธีการอีเมลและแฟกซ์จะแทรกข้อมูลลงในตารางคิวที่ได้รับการสำรองฐานข้อมูลซึ่งจะถูกจัดการโดยกระบวนการงาน cron แยกต่างหาก ดังนั้นการโทรไปยังวิธีการบริการ "ส่งอีเมล" และ "ส่งแฟกซ์" อาจถูกยกเลิกได้หากไม่จำเป็น ตัวเลือกคือการใส่รหัสทั้งหมดนี้ไว้ในเว็บเซอร์วิสดังนั้นเว็บเซอร์วิสจะเรียกวิธีการสร้างอีเมลแฟกซ์และตั๋วในการทำธุรกรรม แต่เรากำลังสร้างวิธีการบริการเว็บเพื่อใช้ธุรกรรม ไม่มีเหตุผลที่ถูกต้องที่เราจะต้องเรียกวิธีนี้จากทุกที่ยกเว้นสคริปต์ cron อันนี้ โดยทั่วไปคุณจะจัดการกับวิธีนี้อย่างไร

14 web-services  soa  services 

บริษัท ของเรากำลังเริ่มต้นการริเริ่ม SOA ที่ค่อนข้างใหญ่ เรากำลังทำสิ่งต่าง ๆ มากมายถูกต้อง: มีการสื่อสารที่ดี เงินสำหรับเครื่องมือตามความเหมาะสม และเราได้นำความเชี่ยวชาญที่ดีบางอย่างมาช่วยเราในการเปลี่ยนแปลง เรากำลังพยายามพัฒนามาตรฐานที่เราสามารถปฏิบัติตามเป็นกลุ่มและหนึ่งในมาตรฐานที่เสนอนั้นรบกวนฉันไม่น้อย: เรามีมาตรฐานในรูปแบบที่ทุกการดำเนินการใช้วัตถุคำขอและส่งกลับวัตถุตอบสนอง ฉันรู้ว่านี่เป็นวิธีมาตรฐานมากกว่าหรือน้อยกว่าสำหรับคนจำนวนมาก แต่ฉันถามว่าทำไมฉันถึงต้องรำคาญ (ฉันไม่ค่อยดีเท่าไหร่ที่มีปัญญาที่ได้รับฉันต้องการบางอย่าง) บริการส่วนใหญ่ที่ฉันจะให้คือการดึงข้อมูลเมตาขององค์กรแบบง่าย ๆ ตัวอย่างเช่นค้นหานโยบายความปลอดภัยสำหรับผู้ใช้เฉพาะ สิ่งนี้ต้องการรหัสผู้ใช้และไม่มีอะไรอื่น มาตรฐานบอกฉันว่าฉันควรห่อคำขอนี้ในวัตถุและห่อนโยบายที่ส่งคืนในวัตถุตอบกลับ ความไม่สงบของฉันได้รับการขยายโดยดูที่ WSDL ที่สร้างขึ้นจากสัญญาของเรา WCF สร้างคำขอและข้อความตอบกลับโดยอัตโนมัติและตัดคำแม้แต่วัตถุคำขอ / ตอบกลับ ฉันเข้าใจอย่างถ่องแท้ว่าหากคุณกำลังร้องขอที่ซับซ้อนดังนั้นวัตถุอินพุตที่ซับซ้อนได้รับการรับประกัน นั่นคือสิ่งที่คุณจะทำแม้ว่าบริการจะไม่เกี่ยวข้อง คำถามของฉันคือเหตุผลที่ฉันควรห่อคำขอและคำตอบโดยอัตโนมัติเมื่อ: มันทำให้การบริการที่เรียบง่ายแสดงออกน้อยลง คุณจะทำมันต่อไปสำหรับบริการที่ซับซ้อน WCF สร้างข้อความร้องขอ / ตอบกลับ ฉันได้พบข้อโต้แย้งต่อไปนี้ในความโปรดปรานของวิธีการนี้: สนับสนุนการกำหนดเวอร์ชันโดยอนุญาตให้พารามิเตอร์ทางเลือกเลื่อนลงในวัตถุคำขอ ย้อนกลับไปในวันนี้ฉันทำ COM ค่อนข้างยุติธรรมและฉันจะพิจารณาสิ่งนี้เกือบเป็นรูปแบบการต่อต้านสำหรับการกำหนดเวอร์ชัน สำหรับบางสิ่งฉันคิดว่ามันจะช่วยได้ แต่ฉันคาดหวังว่ามันจะช่วยคุณได้คุณมีวัตถุพารามิเตอร์อยู่แล้ว จะช่วยให้ข้อมูลทั่วไปและพฤติกรรมที่จะแยกไปที่ชั้นฐาน อันนี้มีน้ำหนักกับฉัน มันพาคนออกจากพฤติกรรมสไตล์ RPC และต่อพฤติกรรมการส่งข้อความ ฉันได้อ่านสิ่งนี้บนเว็บไซต์ของ Microsoft …

12 soa  wcf