কেন পরিষেবা-ভিত্তিক ভাষা নেই?


11

সম্পাদনা:

আরও বিভ্রান্তির বাঁচার জন্য: আমি না ওয়েব সার্ভিস এবং এই ধরনের বিষয়ে কথা। আমি অভ্যন্তরীণভাবে অ্যাপ্লিকেশনগুলিকে কাঠামোগত করার বিষয়ে কথা বলছি, এটি কম্পিউটার কীভাবে যোগাযোগ করে তা নয়। এটি প্রোগ্রামিং ভাষা, সংকলক এবং কীভাবে অত্যাবশ্যক প্রোগ্রামিং দৃষ্টান্তটি প্রসারিত তা সম্পর্কে।

মূল:

অত্যাবশ্যক প্রোগ্রামিং ক্ষেত্রে আমরা গত ২০ বছরে (বা আরও বেশি) দুটি দৃষ্টান্ত দেখেছি: অবজেক্ট-ওরিয়েন্টেড (ওও), এবং পরিষেবা-ভিত্তিক (এসও) ওরফে। উপাদান-ভিত্তিক (সিবি)।

উভয় দৃষ্টান্তগুলি মডিউলগুলির নিজস্ব ধারণা প্রবর্তন করে আবশ্যক প্রোগ্রামিং দৃষ্টান্তটি প্রসারিত করে। ওও তাদেরকে অবজেক্টস (এবং ক্লাস) বলে এবং তাদের উভয় ডেটা (ক্ষেত্র) এবং পদ্ধতি (পদ্ধতি) একসাথে আবদ্ধ করতে দেয়। সুতরাং, বিপরীতে, ডেটা (রেকর্ড, মটরশুটি, ...) কোড (উপাদান, পরিষেবা) থেকে পৃথক করে।

তবে, কেবল ওওর কাছে প্রোগ্রামিং ভাষা রয়েছে যা স্থানীয়ভাবে এর দৃষ্টান্ত সমর্থন করে: স্মার্টটাক, সি ++, জাভা এবং অন্যান্য সমস্ত জেভিএম-তুলনীয়, সি # এবং অন্যান্য সমস্ত নেট নেট-কমপিটেবলস, পাইথন ইত্যাদি languages

এসওর মতো এ জাতীয় কোনও ভাষা নেই। এটি কেবলমাত্র প্রক্রিয়াকরণী ভাষা বা ওও ভাষার শীর্ষে বিদ্যমান: সিওএম / ডিসিওএম (বাইনারি, সি, সি ++), কর্বা, ইজেবি, স্প্রিং, গুইস (সমস্ত জাভা), ...

এই এসও ফ্রেমওয়ার্কগুলি তাদের ধারণাগুলির মাতৃভাষার সমর্থন থেকে স্পষ্টভাবে ক্ষতিগ্রস্থ হয়।

  • তারা পরিষেবা এবং রেকর্ড উপস্থাপনের জন্য ওও ক্লাস ব্যবহার শুরু করে। এটি এমন নকশাগুলির দিকে নিয়ে যায় যেখানে কেবলমাত্র পদ্ধতি (পরিষেবাদি) এবং কেবল ক্ষেত্রগুলি (রেকর্ড) রয়েছে এমন শ্রেণীর মধ্যে স্পষ্ট পার্থক্য রয়েছে। পরিষেবাগুলি বা রেকর্ডগুলির মধ্যে উত্তরাধিকার হ'ল ক্লাসের উত্তরাধিকার দ্বারা অনুকরণ করা হয়। প্রযুক্তিগতভাবে, এটি এত কঠোরভাবে রাখা হয় নি তবে সাধারণ প্রোগ্রামারগুলিতে দুটি চরিত্রের মধ্যে কেবল একটির জন্য ক্লাস করার পরামর্শ দেওয়া হয়।
  • তারা অনুপস্থিত অংশগুলি উপস্থাপন করতে অতিরিক্ত, বাহ্যিক ভাষা ব্যবহার করে: আইডিএল, এক্সএমএল কনফিগারেশন, জাভা কোডে টিকা, বা গুয়েসের মতো এম্বেডড ডিএসএল। এটি বিশেষত প্রয়োজন, তবে সীমাবদ্ধ নয়, কারণ পরিষেবাগুলির সংকলন পরিষেবা কোডেরই অংশ নয়। ওওতে, অবজেক্টগুলি অন্যান্য অবজেক্ট তৈরি করে যাতে এ জাতীয় সুবিধার প্রয়োজন হয় না তবে এসও এর জন্য কারণ পরিষেবাগুলি অন্যান্য পরিষেবাদি ইনস্ট্যান্ট করে না বা কনফিগার করে না।
  • তারা ওও (প্রারম্ভিক ইজেবি, সিওআরবিএ) শীর্ষে একটি অভ্যন্তরীণ-প্ল্যাটফর্ম প্রভাব স্থাপন করে যেখানে প্রোগ্রামারকে "ড্রাইভ" করার জন্য প্রয়োজনীয় সমস্ত কোড লিখতে হয়। ক্লাসগুলি কোনও পরিষেবার প্রকৃতির কেবলমাত্র একটি অংশকে উপস্থাপন করে এবং একসাথে একটি পরিষেবা গঠনের জন্য প্রচুর ক্লাস লিখতে হয়। সমস্ত বয়লার প্লেট প্রয়োজনীয় কারণ কোনও এসও সংকলক নেই যা প্রোগ্রামারের জন্য এটি করবে। এটি ঠিক যেমন কিছু লোকেরা ও-র জন্য সি-তে করেছিলেন যখন কোনও সি ++ ছিল না। আপনি কেবল রেকর্ডটি পাস করেছেন যা পদ্ধতিটির প্রথম পরামিতি হিসাবে বস্তুর ডেটা ধারণ করে। ওও ভাষায় এই প্যারামিটারটি অন্তর্নিহিত এবং সংকলকটি ভার্চুয়াল ফাংশন ইত্যাদির জন্য আমাদের প্রয়োজনীয় সমস্ত কোড তৈরি করে S সুতরাং এর জন্য এটি স্পষ্টভাবে অনুপস্থিত।
  • বিশেষত নতুন ফ্রেমওয়ার্কগুলি একটি ওও ভাষায় অনুপস্থিত অংশগুলি যুক্ত করতে ব্যাপকভাবে এওপি বা অন্তর্নিবেশ ব্যবহার করে। এটি প্রয়োজনীয় ভাষার ভাব প্রকাশ করে না তবে আগের পয়েন্টে বর্ণিত বয়লার প্ল্যাটফর্ম কোডটি এড়িয়ে চলে avo
  • কিছু ফ্রেমওয়ার্কগুলি বয়লার প্লেট কোড তৈরি করতে কোড জেনারেশন ব্যবহার করে। এক্সএমএল কনফিগারেশন ফাইল বা ওও কোডে টিকা রচনাগুলি এটির তথ্যের উত্স।

আমি উপরে উল্লিখিত সমস্ত ঘটনাকে এসওকে দায়ী করা যায় না তবে আমি আশা করি এটি স্পষ্টভাবে দেখায় যে এসও ভাষার প্রয়োজন রয়েছে। যেহেতু এই দৃষ্টান্তটি এত জনপ্রিয়: কেন সেখানে একটি নেই? অথবা হতে পারে কিছু শিক্ষাগত রয়েছে তবে কমপক্ষে শিল্পটি একটি ব্যবহার করে না।


1
উপাদান-ভিত্তিক আর্কিটেকচার এসওএর জন্য প্রয়োজনীয়তা হতে পারে তবে উপাদান-ভিত্তিক জন্য এসওএর প্রয়োজন হয় না। ওও সিস্টেমগুলি যা ডেটা স্ট্রাকচার থেকে পরিষেবাগুলি পৃথক করে না সেগুলিও উপাদান-ভিত্তিক হতে পারে।
ড্যানি ভারোদ

1
@ ড্যানি: আমি সিবি এবং এসওএ-র মধ্যে কোনও পার্থক্য করি না। আপনি যদি তাদের প্রত্যেকটির সংজ্ঞা পড়ে থাকেন তবে সেগুলি মূলত অভিন্ন। সিবি 2000-পূর্বের মত এবং 2000 এর পরে এসওএ-এর মতো কারণ সিবি কোনও সময়ে "মৃত" হিসাবে বিবেচিত হত এবং কেউ আর এই শব্দটি ব্যবহার করতে চায় নি। আমি এসওএকে ওয়েব পরিষেবা বা এই জাতীয় ক্ষেত্রে সীমাবদ্ধ করি না তবে প্রোগ্রামিং প্যারাডাইমটি উল্লেখ করি।
ওল্ফগ্যাং

আপনি দুজনের মধ্যে স্থগিত নাও করতে পারেন, তবে তারা আলাদা। সিবি এবং এর ব্যবহারগুলি সম্পর্কে আরও পড়ুন।
ড্যানি ভারোদ

আমি দীর্ঘ সময় ধরে সিবি এবং এসওয়ের মধ্যে পার্থক্য খুঁজতে চেষ্টা করেছিলাম। অন্য একটিরও দাবি করবে না এমন একটির কোনও বৈশিষ্ট্য খুঁজে পায়নি।
ওল্ফগ্যাং

উপাদান ভিত্তিক আর্কিটেকচারটি ইন্টারফেস ব্যবহার করে শ্রেণীর মধ্যে নির্ভরতা সংযোগ বিচ্ছিন্ন করতে দেখা যায়, সুতরাং নির্ভরতা ইনজেকশন সক্ষম করে। পরিষেবা ভিত্তিক আর্কিটেকচারের প্রয়োজন হয় তবে এটি অন্যান্য প্রয়োজনীয়তাও সরবরাহ করে, কারণ এটি পরিষেবা এবং ক্লায়েন্টদের দূরবর্তী হওয়া সমর্থন করে।
ড্যানি ভারোদ

উত্তর:


8

কারণ <5% কোডটি আসলে একটি পরিষেবা সংজ্ঞায়িত করছে এবং আমি যথেষ্ট পরিমাণে সময় নিয়ে তর্ক করব। ইন্টারফেসটি একবার সংজ্ঞায়িত হয়ে গেলে এটি বেশিরভাগ ক্ষেত্রে সম্পন্ন হয়। বাকি সময়টি ওও (বা বিকল্প ) গুলিতে জিনিসপত্র তৈরিতে ব্যয় করা হয় ।

সহজ কথায় বলতে গেলে সমস্যার সেই ছোট্ট টুকরোটির জন্য একটি বিশেষীকৃত ভাষা করা কোনও বড় জয় নয়। যদি কিছু হয় তবে দুটি ভাষা (একটি পরিষেবার জন্য এবং একটি বাস্তবায়ন / গ্রাহনের জন্য) কেবল যুক্ত সংহত জটিলতার জন্য জিজ্ঞাসা করছে।

[ওপিএস স্পষ্টির জন্য এটির অভ্যন্তরীণ অ্যাপ্লিকেশন বিন্যাস, অ্যাপ্লিকেশন সীমানা নয়] সম্পাদনা করুন:

এই ধরনের পরিষেবা বিন্যাস থাকার মূল লক্ষ্য পরিষেবার মধ্যে পাতলা টাচপয়েন্ট রয়েছে। আমার আসল কারণটি এখনও (ইমো) ধারণ করে এবং এর উত্তরে এই যুক্ত করে যে তুলনামূলকভাবে কয়েকটি সমস্যা সেগুলি ভিত্তিক একটি অভ্যন্তরীণ অ্যাপ্লিকেশন কাঠামোর দিকে ভাল মানায়। সুতরাং আপনি কেবল সমস্যার ক্ষুদ্র অংশকেই সম্বোধন করছেন না, সামগ্রিকভাবে সমস্যার একটি কম শতাংশ।


এটি একটি আকর্ষণীয় বিষয়। তবে আপনি এটি ওওতেও প্রয়োগ করতে পারেন: বেশিরভাগ সময় এটি আবশ্যক প্রোগ্রামিং এবং কেবল 5% ওও হয়। ওও হ'ল জরুরী কোড স্নিপেটগুলি একসাথে আঠালো করার উপায়, যখন এটি অত্যাবশ্যক কোড যা জিনিসগুলিকে কাজ করে। তবুও, আমরা এর জন্য বিশেষত ভাষা থাকার থেকে বৃহতভাবে উপকৃত হই। আমার বক্তব্যটি হ'ল এসও প্রোগ্রামগুলি ওও ভাষাগুলিতে লিখিত হয় কারণ এগুলি একই রকম বলে মনে হয় তবে এটি প্রশ্নে প্রদত্ত সমস্যাগুলিতে বাড়ে।
ওল্ফগ্যাং

@ ওল্ফগ্যাং আমার অভিজ্ঞতায় প্রয়োজনীয় কোডের পরিমাণ এতটা দুর্দান্ত নয়।
তেলস্তিন

@ ওল্ফগ্যাং যদি তা হয় তবে আপনি ওও লেপের সাথে সঠিক ওওপি ব্যবহার করছেন না, কেবল
প্রটেকচারাল

5

কার্যকরী ভাষাগুলি তাদের মূল ভিত্তিতে খুব পরিষেবা ভিত্তিক। তাদের উপর বস্তু তৈরি এবং কলিং ফাংশনগুলির পরিবর্তে আপনি ফাংশন তৈরি করেন এবং তাদের কাছে বার্তা পাঠান। এরলং এই কৌশলটির একটি প্রধান উদাহরণ, কারণ এটির ভাষাটির কার্যকরী দিকগুলি ছাড়িয়েও এর আন্ত-প্রক্রিয়া এবং এমনকি আন্তঃ-মেশিন যোগাযোগ তার মূল কাঠামোর মধ্যে অন্তর্নিহিত আপনাকে কোনও দূরবর্তী প্রক্রিয়াতে বার্তা প্রেরণ করতে দেয় যেমন এটি কোনও স্থানীয় প্রক্রিয়া were ।

অন্যান্য ভাষা যেমন স্কেলা, ক্লোজার এবং এফ # এছাড়াও "পরিষেবা-ভিত্তিক" শব্দার্থক সরবরাহ করে। সমস্যাটি এমন নয় যে তাদের অস্তিত্ব নেই, সাধারণ জনগণ তাদের ভয় পায় এবং তাই তারা এতটা জনপ্রিয় নয়।


3
এছাড়াও এরলংয়ের ওটিপি রয়েছে যা পরিষেবাগুলির ধারণা এবং এগুলি নির্ভরযোগ্য করে তোলার আশেপাশে তৈরি is একটি সার্ভার তৈরি করা যা কোনও ত্রুটির পরে পুনরুদ্ধার করবে ওটিপিতে সহজ। (এটি 10 ​​মিনিটের কাজের মতো লাগে)
জাচারি কে

3

পরিষেবা ওরিয়েন্টেশন / ইন্টিগ্রেশন সমস্যার স্থিতিশীল উত্তর ছিল। ইন্টিগ্রেশন আদর্শভাবে একটি সর্বজনীন সমাধান যা বিদ্যমান যে কোনও ভাষা, পণ্য, ডিভাইস, সংস্থানকে বড় চিত্রের সাথে ফিট করে।

কিছু নতুন ভাষার প্রয়োজন নেই, কারণ খুব সমস্যাটি ইতিমধ্যে অনেক বেশি ভাষা নিয়েই রয়েছে , যা উচ্চ আন্তঃব্যবহারযোগ্যতার ব্যয় করে।

তবে, এক ধরণের ভাষা চালু হয়েছিল, ওয়েব পরিষেবা সংজ্ঞা ভাষা। ডাব্লুএসডিএল হ'ল এসওএ'র মেটা ভাষা (এবং আরএইএসটি নামের WADL নামে আরও একটি পরিত্যক্ত রয়েছে)


2
এটি এমন ভাষা নয় যা আন্তঃব্যবহারের সমস্যা তৈরি করে। এটি অ্যাপ্লিকেশনগুলির কাঠামো। কিছু ভাষাগুলি আন্তঃব্যক্তিকর অ্যাপ্লিকেশনগুলি তৈরি করতে আরও উপযুক্ত।

2

আমি প্রশ্নটি ঘুরিয়ে দেব এবং জিজ্ঞাসা করব "একটি ভাষা কী হবে?"

মডিউলগুলির মধ্যে সেই চুক্তিগুলি কীভাবে লিখিত হবে?
অপারেশনের মৌলিক যান্ত্রিকতা কীভাবে কার্যকর হবে?

পরিষেবাদি-ভিত্তিক পরিষেবাগুলি হ'ল অ্যাপ্লিকেশনটির একটি সম্পত্তি, প্রয়োজনীয় ভাষা ব্যবহৃত হয় না। পরিষেবাটি এমন একটি নির্মাণ যা কোনও ফাংশনের উপর নির্ভর করে। ফাংশনটি এমন একটি নির্মাণ যা মেশিনের নির্বাহযোগ্য নির্দেশিকায় অপারেশনকে অনুবাদ করতে একটি প্রোগ্রামিং ভাষার মেকানিকের উপর নির্ভর করে।

বিপিইএল একটি এসও ভাষার সম্ভাব্য উদাহরণ, তবে এটি খুব উচ্চ স্তরের এবং এটি ব্যবহারের জন্য উপলব্ধ মডিউলগুলির উপর নির্ভর করে। এই মডিউলগুলি ঘুরেফিরে নন-বিপিইএল ভাষায় লিখিত হয় যাতে কাজ সম্পাদন করা যায় (ওরফে মেশিনের ভাষায় অনুবাদ করা))

দুর্দান্ত কিউ এবং আমাকে একটি ভাল মুহুর্তের প্রতিচ্ছবি দিয়েছে।


1
সবচেয়ে বড় সমস্যা হ'ল অবজেক্ট রেফারেন্স থেকে মুক্তি পাওয়া। আমার মনে হয় গুইস মাঝে মাঝে কেমন হয় তা দেখতে হবে। তবে জাভা সর্বদা পরিষেবাটির একটি নিখরচায় রেফারেন্সের প্রয়োজন সহ এগুলি নিয়ে তাদের অনেক লড়াই করতে হবে। একটি পরিষেবার জন্য, আপনার আসলে ধরণের প্রয়োজন, কোনও উদাহরণ নেই। Sing সিঙ্গলেটগুলি কেবল হ্যাকস।
ওল্ফগ্যাং

1

কত লোক সম্মত এবং একমত নয় তা দেখতে আমি আমার নিজের প্রশ্নের উত্তর দেব।

কিছু সম্ভাবনা:

  • এটি একটি এসও ভাষা নির্মাণ করা কঠিন বলে মনে হচ্ছে। বেশিরভাগ ক্ষেত্রে পরিষেবাগুলির বাস্তবায়ন এবং তাদের রচনা পৃথকীকরণের কারণে। বিশ্ববিদ্যালয়ে বেশ কয়েকটি একাডেমিক সমাধান শুনেছি (কোনও রেফারেন্স, দুঃখিত) না তবে এটি এটিকে শিল্পে পরিণত করার মতো মনে হয় না। তবে আমি এটিকে অজুহাত হিসাবে গণ্য করি, আসল কারণ নয়। ওও ভাষা এবং সংকলকগুলি প্রয়োগ করা বেশ কঠিন, তবুও বাজারে দীর্ঘকাল ধরে সমাধান রয়েছে।

  • প্রোগ্রামাররা এসও এর জন্য ওও ভাষা ব্যবহার করে কারণ তারা ওও বোঝে না এবং এটি কোনও ভুল উপায়ে ব্যবহার করে। আমি ভুল বলি কারণ ওওতে দুটি মৌলিক ধারণা রয়েছে যা এসও এর বিরোধিতা করে:

    1. কার্যকারিতা সেই শ্রেণিতে যায় যেখানে ডেটা থাকে যেখানে তারা কাজ করে। কোড এবং ডেটা একই মডিউলে একত্রিত হয়। অন্যান্য ক্লাসের ডেটা নিয়ে কাজ করে এমন আলাদা ক্লাস করা ওও স্টাইল নয়। এটি জালিঘোফেনের সরঞ্জাম-ও-উপকরণের পদ্ধতির (ডাব্লুএএম) যা এসও দৃষ্টান্তের সাথে মেলে।

    2. অবজেক্টস অন্যান্য অবজেক্ট তৈরি করে এবং অবজেক্টের নেটওয়ার্ক গঠন করে। তারা স্তরক্রম বা যে কোনও জটিল সম্পর্ক তৈরি করতে পারে। পরিষেবাগুলি সর্বদা বাইরে থেকে রচিত ফ্ল্যাট নেটওয়ার্কগুলি তৈরি করে। পরিষেবাগুলিতে সাধারণত কেবলমাত্র একটি উদাহরণ থাকে (সিঙ্গলটন) যেখানে অবজেক্টগুলি তাদের প্রতিনিধিত্ব করা সত্তার উপস্থিতি হিসাবে প্রায়শই তত্ক্ষণাতীত হয়। এসও রেকর্ডগুলি নেটওয়ার্কগুলিতে সংযুক্ত নয়।

  • ওওর কয়েকটি বৈশিষ্ট্য এসও-র সাথে অনুরূপ, বা এসও-র জন্য যা প্রয়োজন তা সহজ করার জন্য ব্যবহার করা যেতে পারে যাতে এটি কোনও ওও ভাষা ব্যবহার করার কাজে আসে।

    1. ওওর মধ্যে নির্ভরতা-বিপরীকরণ নীতিটি পরিষেবাগুলি বাহ্যিকভাবে রচনা করার অনুরূপ।

    2. সিঙ্গলটন অবজেক্টস সার্ভিসের মতো, অবজেক্ট কারখানাগুলি সার্ভিস লোকেটারের মতো।

    3. ওও এর ইন্টারফেসও রয়েছে যা সার্ভিস ইন্টারফেসের অনুরূপ।

    4. শ্রেণীর উত্তরাধিকার পরিষেবাদি ও রেকর্ডের উত্তরাধিকার হিসাবে একই (একই?) করতে পারে।

  • ওও এবং এসও বিভিন্ন ধরণের সমস্যার জন্য দরকারী। সুতরাং প্রতিটি অ্যাপ্লিকেশনগুলিতে এটি এখানে বা সেখানে যে কোনও উপমা ব্যবহার করার জন্য লোভনীয়। পৃথক ভাষা থাকার কারণে একই প্রোগ্রামের মধ্যে দুজনের মধ্যে স্যুইচিং বাধাগ্রস্ত হবে।

  • এসও কেবল একটি প্রোগ্রামিং দৃষ্টান্তই নয় এটি একটি প্রোগ্রাম আচরণও: ওয়েব সার্ভিসেস, অপারেটিং সিস্টেমের উপাদানগুলি ইত্যাদি এসও হয় তবে অগত্যা এসও ভাষায় লেখার দরকার নেই। এই জাতীয় "বাইনারি উপাদানগুলি" খুব প্রাকৃতিক এবং সফল। তবে এটি ভিন্ন বিষয়: প্রোগ্রামগুলি কীভাবে একে অপরের সাথে যোগাযোগ করে, প্রোগ্রামটি অভ্যন্তরীণভাবে কীভাবে যোগাযোগ করে তা নয়। আমার ধারণা, লোকেরা প্রায়শই যথেষ্ট মিশে যায়।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.