نقشه راه GIS

درخواست مشاوره

09120049370

8 صبح تا 12 شب

09120049370

Telegram Whatsapp Youtube
کاربرد جی ای اس

خلاصه

ارکستراسیون وب سرویس (WS) را می توان به عنوان یک مفهوم اساسی در معماری های سرویس گرا (SOA) و همچنین در زیرساخت های داده های مکانی (SDI) در نظر گرفت. در سال‌های اخیر در SOA، راه‌حل‌های پیشرفته‌ای توسعه یافتند، مانند تحقق سرویس‌های وب هماهنگ‌شده بر اساس سرویس‌های وب با دانه‌بندی دقیق‌تر با استفاده از نمادهای استاندارد و موتورهای ارکستراسیون موجود. حتی اگر بتوان مفاهیم را در زمینه SDI ترسیم کرد، در سطح مفهومی، پیاده سازی ها اهداف متفاوتی را هدف قرار می دهند. به عنوان یک شکل تخصصی از یک وب سرویس رایج، یک کنسرسیوم فضایی باز (OGC) وب سرویس (OWS) برای یک هدف خاص بهینه شده است. در سطح فناوری، وب سرویس‌ها به استانداردهایی مانند زبان توصیف خدمات وب (WSDL) یا پروتکل دسترسی به اشیاء ساده (SOAP) وابسته هستند. با این حال OWS متفاوت است. در نتیجه، مفهوم جدیدی برای ارکستراسیون OWS مورد نیاز است که بر روی رابط ارائه شده توسط OWS کار کند. چنین مفهومی در این اثر ارائه شده است. مؤلفه اصلی یک موتور هماهنگ سازی است که در یک سرور خدمات پردازش وب (WPS) یکپارچه شده است که از یک زبان خاص دامنه (DSL) برای شرح گردش کار استفاده می کند. مفهوم توسعه‌یافته پایه‌ای برای تحقق عملکردهای جدید، مانند آزمایش گردش کار، و بهینه‌سازی گردش کار است.
کلید واژه ها: 

سیستم اطلاعات جغرافیایی (GIS) ; زیرساخت داده های مکانی (SDI) ; خدمات پردازش وب (WPS) ؛ زبان دامنه خاص (DSL) ; تنظیم و ارکستراسیون

 

 

1. معرفی

زیرساخت‌های داده‌های مکانی (SDI) که تا حدی از معماری‌های سرویس‌گرا (SOA) تکامل یافته‌اند، به طور فزاینده‌ای محبوب می‌شوند در حالی که از نظر مفهومی با ویژگی‌های SOAهای اصلی سازگار هستند [ 1 ]. اصطلاح SOA به مفهومی اشاره دارد که در آن عملکرد با استفاده از مجموعه ای از خدمات قابل استفاده مجدد ارائه می شود. یک مفهوم کلیدی در SOA، هماهنگ سازی خدمات وب (WS) است که برای SDI ها به کار گرفته شده است. استفاده از ارکستراسیون به ویژه در SDI مفید است زیرا محاسبات معمولاً طولانی هستند و داده فشرده هستند و بنابراین برای پردازش از راه دور مناسب تر هستند [ 2 ].
کنسرسیوم فضایی باز (OGC) [ 3 ] استانداردهایی را برای سرویس های وب جغرافیایی که به تقویت قابلیت همکاری بین سرویس های مکانی اختصاص داده شده اند، تعریف و نگهداری می کند [ 4 ]]. بنابراین، OGC به خدمات وب خود توصیفی متکی است. استانداردهای ارائه شده تنظیم می کنند که یک سرویس وب OGC (OWS) چگونه باید باشد، در حالی که کنسرسیوم وب جهانی (W3C) استاندارد وب سرویس زبان توصیف خدمات وب (WSDL) فقط نحوه توصیف خدمات وب را نشان می دهد. با این حال استانداردهای OGC از استانداردهای خدمات وب مانند WSDL یا پروتکل دسترسی ساده به اشیا (SOAP) پشتیبانی می کنند، اما نیازی به استفاده از آنها ندارند. OWS مستقیماً بر روی پروتکل انتقال ابرمتن (HTTP) عمل می کند. از طریق استفاده از اصل SOA در نظر گرفته شده است که با سرویس های وب رایج سازگار باقی بمانند. OWS عملیات‌هایی را درست مانند سرویس‌های وب رایج ارائه می‌کند، اگرچه ساختار، پیام‌های مبادله‌شده و بارگذاری آن‌ها توسط پروتکل از پیش تعریف شده‌اند. در واقع، امکانات یک OWS از امکاناتی که WSDL ارائه می دهد بیشتر است [5 ]. همه OWS دارای یک عملیات GetCapabilities مشترک هستند که اطلاعات اولیه در مورد سرویس، ارائه دهنده سرویس و محتویات ارائه شده را ارائه می دهد [ 6 ]. با این حال، استفاده از WSDL در SDI به طور مداوم توسط OGC تنظیم نمی شود. در برخی موارد OWS یک توضیح WSDL را از طریق عملیات GetCapabilities ارائه می دهد. در چنین حالتی، بخش هایی از اطلاعات ارائه شده مانند توضیحات رابط فنی به صورت اضافی ارائه می شود. همچنین برای بازیابی خودکار توضیحات باید تماسی برقرار شود و این مفهوم منسوخ شود. نوع OWS هدف و تعامل بیشتر با سرویس را مشخص می کند.
با توجه به توضیحات آن، سرویس پردازش وب (WPS) یک مورد خاص است. WPS برای ارائه قابلیت‌های پردازش برای داده‌های مکانی در نظر گرفته شده است، اما همچنین می‌تواند به عنوان رابطی برای سرویس‌های موجود در حال حاضر نیز خدمت کند. این سرویس عملکردی را با استفاده از مفهوم فرآیند ارائه می دهد. یک فرآیند شامل قابلیت های پردازش سمت سرور است که می توان آنها را از طریق عملیات ارائه شده توسط سرور WPS میزبان کشف کرد و به آنها دسترسی داشت. این عملیات ها GetCapabilities هستند که از OWS رایج DescribeProcess برای بازیابی اطلاعات دقیق در مورد فرآیندهای خاص و اجرا برای شروع یک فرآیند به ارث رسیده اند. SDI ها در درجه اول به ارائه قابلیت همکاری نحوی اختصاص داده شده اند. بنابراین WPS به عنوان تنها استاندارد OGC برای اهداف پردازش عمومی برای هر محاسبه سمت سرور بسیار مهم است.
با استفاده از WSDL برای اتصال به یک WPS، نه تنها کاستی های OWS فوق الذکر اعمال می شود، بلکه افزونه های خاص WPS نیز در نظر گرفته نمی شوند، به عنوان مثال، سرویس با سه عملیات آن را می توان توصیف کرد، همانطور که فرآیندهای آن می تواند توضیح داده شود. در اینجا WPS با یک عدم تطابق مفهومی با WSDL مواجه است. با این حال، در پیاده سازی های رایج، این به طور متفاوتی حل می شود. به عنوان مثال، در PyWPS [ 7 ] سرویس و فرآیندها را می توان به طور جداگانه توصیف کرد، در 52 درجه شمالی WPS [ 8 ] یک توصیف صرفاً برای سرویس استفاده می شود.
ارکستراسیون در SOA معمولاً با استفاده از موتورهای ارکستراسیون وب سرویس (WSOE) در ترکیب با زبان توصیف گردش کار انجام می شود. به عنوان مثال، زبان اجرای فرآیند کسب و کار (BPEL). اغلب WSDL به عنوان یک فناوری پشتیبانی درگیر می شود. خدمات ارکستر شده توسط موتور ارکستراسیون ارائه می شود. اگرچه در موارد فردی این نوع ارکستراسیون می تواند برای SDI اعمال شود، مشکلات به طور منظم گزارش می شوند [ 9 ]. با این حال، ابزارها و نرم‌افزارهایی که از یک ارکستراسیون راحت و کاربردی پشتیبانی می‌کنند، هنوز وجود ندارند. علاوه بر این، گردش‌های کاری مبتنی بر داده‌های علمی به توصیف گردش کار پیچیده‌تری نیاز دارند [ 10 ].
به طور کلی می توان بیان کرد که رویکردهای موجود ارکستراسیون OWS به یک پشته فناوری پیشرفته که توسط W3C WS، BPEL و WSDL، با یا بدون SOAP و استانداردهای بعدی WS-* تعریف شده است، بستگی دارد. سازگاری OWS با تکنیک‌های موجود W3C معمولاً با افزودن لایه‌های تطبیقی ​​بیشتر به پشته پروتکل به دست می‌آید، همانطور که با SOAP اتفاق افتاد که کل سیستم را پیچیده‌تر و بیشتر کرد. در حالی که این امکان همکاری با W3C WS را فراهم می کند، انسجام مفهومی را با سایر OWS کاهش می دهد و مزایای OWS را بلااستفاده می گذارد. به عنوان مثال، استفاده از BPEL ممکن است در نهایت منجر به این واقعیت شود که رویکردهای ارکستراسیون فعلی OWS به دلیل پیچیدگی و نیاز به تخصص فنی در فناوری اطلاعات، برای استفاده توسط کاربران دامنه آماده نیستند.
هدف پروژه تحقیقاتی RichWPS غلبه بر این کاستی ها با ساده سازی طراحی فنی و همچنین تعامل کاربر است. مفهوم کلیدی اعمال شده برای این یک زبان خاص دامنه (DSL) است که از نزدیک در پشته فناوری ارائه شده OGC ادغام می شود، در حالی که درجات آزادی استفاده نشده ای که WS رایج ارائه می دهد بسته می شود. مطمئناً، این به این واقعیت منجر می شود که کارشناسان فناوری اطلاعات / انفورماتیک به احتمال زیاد فاصله فزاینده ای را با مفاهیم جدید تجربه خواهند کرد و روندی دنبال می شود که از جریان فناوری W3C WS متفاوت است. به دلایل سازگاری، RichWPS باید آن را مرتب کند.
این مقاله محیط ارکستراسیون RichWPS و مجموعه نرم افزار را ارائه می دهد. محیط نمونه اولیه برای ارکستراسیون بر اساس یک موتور ارکستراسیون در ترکیب با یک DSL استفاده می شود. در مرحله اول، ارکستراسیون بر روی WPS تمرکز دارد. موتور ارکستراسیون در یک سرور WPS قرار می گیرد. فرآیندهای WPS را با زنجیر کردن آنها هماهنگ می کند و ترکیب را به عنوان فرآیند WPS منتشر می کند و در نتیجه آن را برای ترکیب بعدی در دسترس قرار می دهد.
علاوه بر ارکستراسیون، RichWPS به مسائل مختلف تحقیقاتی بیشتر در مورد تاریخچه ابرداده برای داده های پردازش شده، کشف گردش کار، جستجوی معنایی برای مدل سازی گردش کار، اشکال زدایی گردش کار و ترکیب مجدد جریان های کاری موجود در زمان اجرا به منظور دستیابی به عملکرد بهتر، رسیدگی می کند. با شناسایی کاستی‌های فعلی در مورد تجربه کلی کاربر، هدف نرم‌افزار توسعه‌یافته ارائه سطح بالاتری از قابلیت استفاده به منظور پیشبرد WPS به سمت کاربرد عملی است. اطلاعات بیشتر درباره RichWPS را می‌توانید در اینجا بیابید: http://richwps.github.io .
محتوای بعدی معماری کلی را با تمرکز بر کشف، مدل‌سازی و ارکستراسیون واقعی توصیف می‌کند. فصل اول کارهای مرتبط را تشریح می کند و تصمیمات طراحی حاصل را برای RichWPS توضیح می دهد. پس از آن، مهمترین زمینه های کار از جمله شرح گردش کار و مفهوم مدل سازی به تصویر کشیده می شود. سپس فصل مجاور با تشریح وضعیت پروژه و همچنین وظایف آتی، بر روی کارهای معلق تمرکز می کند. در نهایت یک نتیجه از کار در زمینه زمینه تحقیق استخراج می شود.

2. مفهوم معماری

همانطور که قبلا ذکر شد، تحقیقات زیادی در زمینه ارکستراسیون انجام شده است. مفهوم‌سازی و پیاده‌سازی گردش‌های کاری ژئوپردازش شامل رویکردهای متفاوتی است که از زنجیره شفاف سمت مشتری OWS [ 11 ] تا استفاده از هماهنگ‌سازی گردش کار خودسازمان‌دهی کامل با استفاده از معناشناسی [ 2 ] را شامل می‌شود.

2.1. تکنولوژی های جریان اصلی

در منطقه geospatial رایج ترین راه برای استفاده از ارکستراسیون OWS زنجیره WS است. طبق ISO 19119 زنجیر زنی عبارت است از “توالی از خدمات که در آن برای هر جفت سرویس مجاور، وقوع اولین اقدام برای وقوع عمل دوم ضروری است” [ 12 ].
زنجیر زنی را می توان با استفاده از سه الگوی مختلف اعمال کرد: زنجیر شفاف، نیمه شفاف و مات. الگوهای استفاده شده میزان دانش یک کاربر از یک زنجیره خدمات خاص را تعیین می کند. در زنجیره شفاف، کاربر مسئول کشف سرویس، ارزیابی و دستور اجرای زنجیره است. بنابراین او به تمام جزئیات خدمات دسترسی دارد. در زنجیره شفاف، کاربر از یک زنجیره خدمات از پیش تعریف شده استفاده می‌کند که توسط WSOE ارائه می‌شود، بنابراین از تمام سرویس‌های شرکت‌کننده آگاه است و ممکن است بتواند اطلاعات وضعیت را از سرویس‌های شرکت‌کننده نظرسنجی کند، اگرچه هیچ تأثیری در اجرا ندارد. در زنجیره غیر شفاف، زنجیره توسط یک WSOE به عنوان یک سرویس ارائه می شود و کاربر اصلاً اطلاعاتی در مورد زنجیره ندارد، فقط می تواند از آن استفاده کند. اگرچه زنجیره سازی شامل ساختارهای کنترلی نمی شود، اجرای موازی،11 ، 13 ]. بنابراین، فقدان ساختارهای کنترلی چیزی است که زنجیره را از ارکستراسیون به طور کلی متمایز می کند.
هنگام پرداختن به ارکستراسیون، به ویژه در قالب زنجیرهای شفاف و غیر شفاف، مسائل تکراری وجود دارد که باید مورد توجه قرار گیرد. به ویژه، هنگام تنظیم یک گردش کار، توضیحات خدمات موجود باید وجود داشته باشد. هنگام انجام یک مدل‌سازی دستی، باید ابزارهای مدل‌سازی مناسب در دسترس باشد و در نهایت راه‌حلی برای شرح گردش کار و راهی برای ارائه آن در دسترس باشد. سیستم های موجود این مسائل را به گونه ای متفاوت حل می کنند.
بسیاری از معماری‌های گردش کار بر انطباق تکنیک‌های شناخته شده و اثبات‌شده SOA و استانداردهای ارائه‌شده W3C و سازمان توسعه استانداردهای اطلاعات ساختاریافته (OASIS) متکی هستند. از آنجایی که برخی از این تکنیک ها اغلب در زنجیره OWS اعمال می شوند، در اینجا نیز مورد بحث قرار می گیرند [ 13 ]. در کنار استاندارد WS، W3C اول از همه WSDL [ 14 ] را برای توصیف رابط WS ارائه می دهد. همراه با استانداردهای WS*، SOAP [ 15 ] برای معرفی ویژگی های پیچیده تر، به عنوان مثال، برای امنیت [ 16 ] به این اضافه می کند. در [ 17] نویسندگان در مورد آخرین پیشرفت در زمینه ترکیب WS و فناوری‌های WS بحث و بررسی می‌کنند. قابل توجه این است که پس از سال 2006 تلاش تحقیقاتی کاهش یافت. نویسندگان [ 18 ، 19 ، 20 ، 21 ، 22 ] رویکردهای قبلی نسبت به این موضوعات را مورد بررسی قرار می دهند، اما با بحث در مورد ترکیب گردش کار خودکار جامع بر اساس معناشناسی، از محدوده مدل سازی و اجرای ساده گردش کار فراتر می روند.
چندین نهاد استانداردسازی مانند Java specification Request 207، OASIS، Object Management Group و Workflow Management Coalition تلاش هایی را برای توسعه استانداردها و زبان های توصیف گردش کار انجام دادند. در [ 23 ] نویسنده فن آوری های ارکستراسیون WS موجود و پیشینه آنها را خلاصه می کند. بر این اساس، بیشتر ارکستراسیون توسط نوعی موتور گردش کار در ترکیب با زبان توصیف گردش کار منطبق تحقق می یابد. محبوب‌ترین زبان‌های توصیف گردش کار عبارتند از زبان تعریف فرآیند XML [ 24 ]، زبان هنوز یک گردش کار [ 25 ] و BPEL. نمونه های بیشتری از زبان ها در [ 26 ] مورد بحث قرار گرفته است. به دلیل عملکرد گسترده آن، BPEL عملاً تبدیل شداستاندارد برای ارکستراسیون WS (مبتنی بر W3C) [ 17 ، 27 ]. این یک زبان مبتنی بر XML است که توسط یک موتور BPEL مانند Apache ODE [ 28 ] اجرا می‌شود و به WSDL بستگی دارد. از آنجایی که تکیه بر XML BPEL برای استفاده توسط انسان در نظر گرفته نشده است، اما ویرایشگرهای گرافیکی در دسترس هستند [ 29 ].
علاوه بر این، زبان‌های ارکستراسیون و رقص مبتنی بر اسکریپت وجود دارند که برای کاربران انسانی مناسب‌تر هستند و از ساختارهای کنترلی پیشرفته پشتیبانی می‌کنند. مشهورترین نمایندگان عبارتند از موتور مترجم زبان ارکستراسیون جاوا (JOLIE) [ 30 ] و Orc [ 31 ].]. JOLIE یک مفسر زبان برنامه نویسی سرویس گرا و تمام عیار با زبان مطابق است. این مبتنی بر جاوا است و یک نحو شبیه جاوا/C ارائه می دهد. به این ترتیب زبان دارای جنبه های محاسباتی و همچنین ترکیبی است. هدف آن ارائه یک زبان برنامه نویسی برای تعریف سرویس های پایه، سازماندهی آنها در یک SOA، و رفتار ارکسترهای مسئول نظارت بر تعاملات میان سرویس ها است که در نتیجه از فناوری های ارتباطی مختلف پشتیبانی می کند، به عنوان مثال، SOAP [ 32 ].]. اسکریپت هایی که گردش های کاری تشکیل شده را توصیف می کنند، می توانند به عنوان WS جدید توسط موتور مفسر ارائه شوند. برای پشتیبانی از توسعه دهندگان، JOLIE همراه با مجموعه ای از ابزارها است، به عنوان مثال، برای تبدیل WSDL به کد و کد به WSDL یا JOLIE به جاوا. با پشتیبانی از ساختارهای کنترلی، نیازهای زنجیره ای را افزایش می دهد.
به عنوان یکی دیگر از راه حل های مبتنی بر اسکریپت، هدف زبان برنامه نویسی Orc ارائه زبانی برای هماهنگی کار با مجموعه ای از ویژگی های قابل مدیریت است. بنابراین به مترجم Orc-to-Java متکی است. تعاریف مورد نیاز رابط WS از اسناد WSDL که URI آنها در اسکریپت Orc مشخص شده است استخراج می شود. کلاس های جاوای به دست آمده را می توان در هر برنامه جاوا استفاده کرد [ 33 ].
در نهایت راهی برای استفاده از جاوای ساده یا زبان‌های برنامه‌نویسی مشابه برای برنامه‌ریزی گردش‌های کاری هماهنگ به صورت دستی وجود دارد. ابزارهای مختلفی در دسترس هستند که از کاربران با تولید خرد WS پشتیبانی می کنند. در مورد جاوا، این ابزار Java2WSDL [ 34 ] است و در بسیاری از IDE ها موجود است. علاوه بر این، به طور ضمنی توسط مترجم Orc فوق الذکر نیز استفاده می شود.

2.2. ارکستراسیون OWS

اگرچه OWS و W3C WS هر دو WS هستند، اما به یک شکل کار نمی کنند: در حالی که W3C WS به SOAP RPC و WSDL متکی هستند، OWS از XML-RPC [ 35 ] استفاده می کند. در نتیجه هدف OGC ارائه قابلیت همکاری بهتر است [ 11 ، 36 ]. بنابراین، OWS رایج علاوه بر پشتیبانی از عملیات خود توصیفی خود برای WSDL و SOAP چیزی را ارائه می‌کند که آنها را برای رویکردهای ارکستراسیون مبتنی بر W3C در دسترس قرار می‌دهد. رویکردهای موجود برای زنجیره شفاف و غیرشفاف OWS بر BPEL تمرکز دارند، اگرچه کاربرد آنها در محیط OGC مستعد است [ 37 ]. همچنین، پشتیبانی از تماس های ناهمزمان نمی تواند اعطا شود [ 13]. خدماتی که در زنجیره‌های خدمات OWS ظاهر می‌شوند معمولاً خدمات پوشش وب (WCS)، سرویس ویژگی‌های وب (WFS)، خدمات نقشه وب (WMS) همانطور که در [ 11 ] بیان شد و علاوه بر آن WPS هستند.
در [ 38 ] رویکردهای استفاده از موتورهای مختلف BPEL برای زنجیربندی در زمینه سناریوی تهدید بمب شرح داده شده است. نویسندگان بیان می کنند که هماهنگ سازی با موتورهای آزمایش شده (ActiveBPEL 2.0، Oracle BPEL Process manager 10.1.2) به دلیل چندین مشکل مشکل دارد. فراتر از جنبه های دیگر، این مشکلات مربوط به ارائه اسناد WSDL برای OWS، پیاده سازی SOAP در سمت OWS و پشتیبانی از دست رفته اتصال HTTP توسط موتورهای BPEL است. در [ 35 ] نیز همینطور است. در [ 39 ] این مشکلات نیز بیان شده و برای غلبه بر آن توسط OGC مجدداً بیان شده است. در مثال‌های ارائه‌شده، گردش‌های کاری هماهنگ به‌عنوان W3C WS به مشتریان ارائه شد، اما ممکن است در SDI مناسب نباشد.
در مقاله‌های زیر، گردش‌های کاری تشکیل‌شده برای استفاده در یک SDI با استفاده از یک سرور WPS تطبیقی ​​که به عنوان یک رابط برای WSOE عمل می‌کند، در دسترس قرار گرفته‌اند. به عنوان مثال می تواند به عنوان یک پوشش یا به عنوان یک پروکسی برای یک WSOE عمل کند و گردش کار را به عنوان یک فرآیند منتشر کند. با انجام این کار، در یک SDI، گردش کار به روشی مطابق با OGC قابل دسترسی است و قابلیت همکاری به چالش کشیده نمی شود. این روش در [ 2 ، 13 ، 37 ] توضیح داده شده است]. در آن راه حل یک موتور BPEL تقریبی است، درست همانطور که توضیح داده شد. تماس‌ها با گردش کار توصیف‌شده BPEL به یک سرور WPS شمالی 52 درجه هدایت شده و به موتور BPEL هدایت می‌شوند. در نتیجه، برای اعمال WPS برای اجرای گردش کار، مکانیزمی برای استقرار (un-) پیاده سازی شده است. این مکانیسم WPS Transactional (WPS-T) نامیده می شود و برای ادغام در استاندارد WPS 2.0 به عنوان یک افزونه در نظر گرفته شده است. WPS-T با تصور اولیه خود قادر به استقرار هر نوع منبعی از جمله فرآیندهای WPS است.
با تعریف گسترده‌اش، پیاده‌سازی WPS برای تصاحب عملکرد WSOE در زمینه SDI مناسب است. همچنین، استاندارد با هدف پشتیبانی از گردش‌های کاری زنجیره‌ای [ 5 ] توضیح داده شد. به این ترتیب یک گردش کار برای استفاده مجدد در یک ترکیب دیگر در دسترس است. اگرچه استفاده از WPS روشی عملی برای ارائه گردش‌های کاری هماهنگ در SDI است، اما مسائل ذکر شده در بالا دست نخورده باقی می‌مانند.
زنجیره‌سازی را می‌توان صرفاً با استفاده از مشخصات WPS انجام داد، زیرا امکان تودرتو کردن درخواست‌ها را به صورت متوالی در یکدیگر فراهم می‌کند [ 5 ]. پس از دریافت تماس، اولین درخواست در سمت سرور اجرا می شود. سپس درخواست‌های باقی‌مانده به نمونه بعدی WPS ارسال می‌شوند و به همین ترتیب. پس از اتمام تمام درخواست‌ها، نتیجه در طول زنجیره فراخوانی برگردانده می‌شود. این روش در سرور Deegree WPS [ 9 ] و در Geoserver [ 40 ] پیاده سازی شده است.
روش دیگری برای استفاده از WPS خالص، گنجاندن مستقیم منطق تماس و کلاینت ها در فرآیند WPS در زمان کامپایل است [ 5 ، 36 ]. دو رویکرد آخر نقص آشکاری در انعطاف‌پذیری، گزینه‌های اشتراک‌گذاری و نیاز به کارشناسان بسیار آموزش دیده برای توسعه فرآیندهای WPS جدید دارند.
یکی دیگر از زمینه های مهم، مدل سازی گردش کار است. همانطور که در بالا گفته شد ویرایشگرهای گرافیکی برای اکثر زبان های ارکستراسیون مبتنی بر W3C در دسترس هستند. محیط‌های توسعه کامل برای ترکیب سرویس مانند Taverna [ 41 ] با موفقیت برای کار با WSDL توصیف‌شده سازگار شده‌اند و امکان‌سنجی نشان داده شد [ 42 ]. این امر Taverna را به یک گزینه قابل توجه برای مدل سازی گردش کار و یک نمونه خوب تبدیل می کند.
در نهایت، برخی از مسائل در تحقیق که در این کار نیز به آنها پرداخته شده است، مانند گنجاندن معناشناسی در شرح خدمات استاندارد [ 13 ]، مدیریت انتقال داده های بزرگ [ 27 ]، هماهنگ سازی خدمات [ 43 ] و استراتژی هایی برای بهبود همچنان برجسته هستند. عملکرد [ 13 ، 43 ].

2.3. معماری

محیط ارکستراسیون RichWPS رویکردهای قبلی را برای اجرای روشی جایگزین از ارکستراسیون WPS اتخاذ می کند. به سه زمینه کاری می پردازد: کشف، مدلینگ و ارکستراسیون. بر اساس این زمینه ها، سه مؤلفه اصلی برای رسیدگی به این چالش ها ایجاد شد. شکل 1 مؤلفه ها را نشان می دهد: SemanticProxy، مسئول کشف. ModelBuilder، مسئول مدل سازی؛ و سرور RichWPS، مسئول ارکستراسیون واقعی است. یک خط چین نشان دهنده یک ارتباط “می داند” در حالی که یک خط کشیده شده نشان دهنده “ارتباط” است.
رویکردهای مبتنی بر زنجیره‌بندی توسط درخواست‌های تودرتو که در مشخصات WPS ارائه شده بود، رد شد، زیرا گردش‌های کاری حاصل برای سایر کاربران یا برای استفاده در ترکیب‌های بعدی در دسترس نیستند. همچنین گزینه هایی برای استفاده از ساختارهای کنترل وجود ندارد.
رویکردهای بررسی شده که از یک زبان هدف عمومی (جاوا، …) یا یک زبان خاص دامنه (JOLIE، Orc) و پیاده سازی دستی استفاده می کردند، ارزیابی شده و با توجه به مناسب بودن برای افراد غیرمتخصص فناوری اطلاعات کنار گذاشته شده اند، اگرچه عملکرد و پشتیبانی ارائه شده برای ساختارهای کنترلی امیدوارکننده است. دلیل دیگر این تصمیم، استفاده اولیه از WSDL برای توضیحات WPS است که باید در اینجا حل شود.
Ijgi 03 01334 g001 1024
شکل 1. مروری بر اجزای RichWPS.
اگرچه راه حل های کلاسیک، به عنوان مثال، مبتنی بر BPEL امیدوارکننده هستند، مشخص شد که عدم تطابق مفهومی رویکردهای W3C و رویکردهای OGC به طور بالقوه با توسعه یک محیط ارکستراسیون اختصاصی بهتر ارائه می شود. در نتیجه، مفهوم اصلی استفاده از یک موتور ارکستراسیون اختصاصی برای اجرای توضیحات گردش کار سفارشی و استفاده از ویژگی های ارائه شده OWS و WPS است. بنابراین از مسائل WSDL و SOAP و همچنین ناسازگاری های جزئی با پیاده سازی های خاص جلوگیری می شود. برای استقرار WPS-T از [ 37 ] پذیرفته شده و گسترش یافته است.
توضیحات سفارشی استفاده شده برای استفاده از OWS بهینه شده اند. بنابراین، یک زبان مبتنی بر اسکریپت، زبان ارکستراسیون RichWPS (ROLA)، توسعه یافت. ROLA برای گردش‌های کاری جغرافیایی بهینه‌سازی شده است و به جای هماهنگ‌سازی OWS و گردش‌های کاری علمی به جای W3C WS و گردش‌های کاری فرآیند تجاری، بهینه‌سازی شده است.
در استراتژی انتخاب شده، توسعه یک DSL کلیدی برای غلبه بر پشته فناوری مورد نیاز برای ارکستراسیون کلاسیک است. اشکال توسعه یک موتور ارکستراسیون جدید در این مورد پذیرفته شده است. با این حال، با ادغام موتور ارکستراسیون مستقیماً در یک سرور WPS که از رابط WPS 1.0 و WPS-T برای استقرار و عدم استقرار گردش کار استفاده می کند، می توان بیشتر هزینه ها را کاهش داد. همچنین، این راه حل قابلیت همکاری را در محیط خدمات تعریف شده توسط OGC و همچنین کاهش پیچیدگی با اجتناب از موتور ارکستراسیون به عنوان یک جزء اضافی تقویت می کند.
ممکن است معلوم شود که ROLA برای استفاده توسط کاربران دامنه مناسب‌تر است، زیرا طوری طراحی شده است که نزدیک به زبان‌های طبیعی باشد تا خوانایی در مقایسه با تعاریف مبتنی بر XML افزایش یابد. همچنین، با کمک ModelBuilder به کاربر، مدل سازی و استقرار را می توان بدون تماس مستقیم با ROLA انجام داد. بنابراین ROLA با نوع گرافیکی خود سازگار است. با در نظر گرفتن ماهیت گسترده رابط، همراه با فضای داخلی قابل طراحی رایگان موتور ارکستراسیون و ROLA، RichWPS برای چیزی بیش از زنجیر باز است.
علاوه بر این، رویکرد ارائه شده مبنایی برای پرداختن به چندین مورد تکراری در زمینه WPS فراهم می‌کند، به عنوان مثال، برای بهبود کیفیت خدمات (QoS)، می‌توان یک ترکیب مجدد پویا از گردش‌های کاری انجام داد، یا فرآیندهای واقع در سرور WPS میزبان را می‌توان انجام داد. دسترسی داخلی، بدون استفاده از ارتباطات شبکه. به این ترتیب QoS به ترکیبی از کیفیت یا ویژگی های یک سرویس مانند در دسترس بودن یا زمان پاسخ می پردازد [ 44 ].
با این وجود، برای خدمت به موتور ارکستراسیون، یک ابزار مدلسازی مورد نیاز است که از ROLA پشتیبانی کند. بنابراین یک ویرایشگر مدل گرافیکی به نام ModelBuilder در دست توسعه است. ModelBuilder به عنوان یک برنامه کاربردی سمت کلاینت برای تعامل با سرور RichWPS عمل می کند. با الهام از Taverna Workbench [ 41 ]، می‌توان از آن برای مدل‌سازی گردش کار و مدیریت چرخه عمر گردش‌های کاری استفاده کرد. علاوه بر این، ModelBuilder را می توان برای آزمایش، اشکال زدایی و تجزیه و تحلیل عملکرد توسعه داد.
برای عملکرد مناسب ModelBuilder و همچنین خدمات آتی، به اطلاعاتی در مورد خدمات موجود در شبکه قابل دسترسی نیاز دارد. برای مدل‌سازی حداقل به توضیحات رابط فرآیندهای WPS نیاز دارد. گسترش شرح فرآیند امکان استفاده از جستجوهای پیشرفته را فراهم می کند. می توان فرض کرد که جمع آوری داده های جامع در شروع سیستم، به عنوان مثال، با درخواست آدرس های OWS از پیش تنظیم شده با استفاده از توانایی های خود توصیفی آنها، راه حل عملی نخواهد بود. راه اندازی به تعویق می افتد و کاربر باید همه خدمات موجود را بداند. همچنین غنی‌سازی داده‌ها با اطلاعات معنایی به روشی کارآمد قابل استفاده نخواهد بود. بنابراین ارائه داده به یک سرویس دایرکتوری برون سپاری می شود که برای سایر مشتریان نیز قابل دسترسی است. چارچوب توصیف منابع (RDF) برای توصیف این خدمات استفاده می شود. RDF قابل گسترش است و اجازه می دهد تا یک انتقال صاف به استفاده از عملیات های فعال معنایی مانند جستجوهای معنایی انجام شود. با استفاده از اصل داده های پیوندی، این سرویس همچنین می تواند در محیط های RDF موجود ادغام شود. این باعث می شود آن را با سرویس کاتالوگ برای وب (CSW) که در غیر این صورت یک گزینه بود، ناسازگار می کند. جزء سرویس دایرکتوری SemanticProxy نامیده می شود. این باعث می شود آن را با سرویس کاتالوگ برای وب (CSW) که در غیر این صورت یک گزینه بود، ناسازگار می کند. جزء سرویس دایرکتوری SemanticProxy نامیده می شود. این باعث می شود آن را با سرویس کاتالوگ برای وب (CSW) که در غیر این صورت یک گزینه بود، ناسازگار می کند. جزء سرویس دایرکتوری SemanticProxy نامیده می شود.
در نهایت سرور RichWPS و SemanticProxy برای استفاده در محیط های توزیع شده مانند ابر مفهوم سازی شده اند. اگرچه، پیکربندی کامل به خصوص با توجه به SemanticProxy و اجرای داده های مرتبط اجتناب ناپذیر است، که مستلزم آن است که توضیحات منابع RDF را می توان از URI شناسایی آنها به دست آورد. با استراتژی استقرار انتخاب شده، استقرار فرآیند را می توان تنها توسط کاربران دامنه انجام داد و پشتیبانی توسط مدیران سیستم تنها در راه اندازی اولیه مورد نیاز است.
RichWPS یک رویکرد جدید از WPS را تشکیل می دهد که WPS رایج را با ابزارهای جدید ارکستراسیون گسترش می دهد. یک فرآیند WPS هماهنگ توصیف شده و یک روش برای استقرار تعیین شد. از آنجایی که WPS ابتدا یک رابط را توصیف می کند، استاندارد فقط تحت تأثیر پسوند WPS-T قرار می گیرد. بدیهی است که ایجاد ویژگی های واحد، به عنوان مثال ROLA یا عملیات برای آزمایش و پروفایل در استاندارد WPS جالب خواهد بود. جدول 1 نمای کلی RichWPS را در مقایسه با ارکستراسیون کلاسیک بر اساس BPEL ارائه می دهد. مشاهده می شود که اکثر مزایایی که RichWPS نشان می دهد در تعامل با OWS نهفته است، در حالی که BPEL در SOA های کلاسیک قوی است.
جدول
جدول 1. ویژگی های RichWPS در مقایسه با راه حل های مبتنی بر BPEL.

3. زمینه های فعالیت

با در دست داشتن مفهوم، گزینه های پیاده سازی در قسمت زیر ارائه شده است. حوزه های مهمی از کار انتخاب می شوند تا با جزئیات بیشتر ارائه شوند.

3.1. ارائه داده ها

در ابتدا، ارائه داده، به معنای عمدتاً اجرای SemanticProxy، ارائه شده است. SemanticProxy یک رابط REST مبتنی بر HTTP برای درخواست اشیاء توصیف WPS و اشیاء توصیف فرآیند و همچنین برای ایجاد، به روز رسانی و حذف اشیاء ارائه می دهد. به این ترتیب می توان داده ها را حفظ کرد. در تکرارهای بعدی توسعه، یک کشف خودکار برای به روز نگه داشتن سرویس مورد نیاز است. چارچوب میکرو وب SPARK [ 45 ] برای پیاده سازی استفاده می شود.
فرمت تبادل داده RDF/XML، یکی از نمادهای RDF موجود است. برای کارهای مربوط به RDF، SemanticProxy بر OpenRDF Sesame [ 46]. مبنای RDF بر منابعی است که می‌توان آن‌ها را با عباراتی توصیف کرد که از یک موضوع، محمول و مفعول تشکیل شده‌اند. موضوعات، محمول ها و اشیاء می توانند خود منابع باشند و بنابراین با گزاره های دیگری توصیف شوند. به این ترتیب رابطه بین منابع در RDF می تواند به عنوان یک نمودار نمایش داده شود. یک شیء نیز می تواند لفظی باشد. برای داشتن پایه ای برای بیانیه ها به دایره لغات نیاز است. خود واژگان از جملات تشکیل شده است. W3C در حال حاضر واژگانی را برای دامنه های خاص ارائه می دهد. در تکرارهای بعدی، استفاده از واژگان موجود مانند OWL-S در نظر گرفته می‌شود، اما در حال حاضر هیچ فضایی برای این کار وجود ندارد. واژگانی ایجاد می شود که داده ها بر اساس آن ساختار یافته اند. از آنجایی که RDF کاملاً با مفهوم سرویس دایرکتوری سازگار نیست، پیوندها به منابعی که به توضیحات دیگر تعلق دارند نیز به طور کامل تنظیم می شوند.
ویژگی خاص RDF این است که عبارات می توانند خارج از مرزهای سیستم به یکدیگر اشاره کنند. این امکان پذیر است زیرا به هر منبع یک شناسه جهانی منحصر به فرد در قالب یک URI اختصاص داده شده است. ارائه اطلاعات از طریق این URI در یک وب سرور یک اصل اساسی داده های پیوندی است.

3.2. مدل سازی

RichWPS ModelBuilder جزء نرم افزار اصلی برای مدل سازی ارکستراسیون است. ارکستراسیون OWS معمولاً یک کار نسبتاً پیچیده است که تا به حال باید توسط کاربرانی انجام شود که دانش تخصصی علوم رایانه دارند. برای ارائه روش‌های ارکستراسیون برای سایر کاربران، به عنوان مثال، متخصصان حوزه‌های مکانی، ModelBuilder به گونه‌ای طراحی شده است که یک رابط کاربری گرافیکی با کاربری آسان ارائه دهد که ایجاد و مدیریت مدل را ساده می‌کند.
در ابتدا بررسی شد که آیا میز کار منبع باز Taverna می تواند به عنوان سازنده مدل استفاده شود یا خیر. با این حال، Taverna برای یک منطقه وسیع از کاربرد طراحی شده است و به مجموعه‌های بزرگی از نرم‌افزار با عملکردی نیاز دارد که توسط RichWPS مورد نیاز نیست. همچنین، بخش‌های مرتبط Taverna، به‌ویژه رابط کاربری گرافیکی، وابستگی‌های زیادی برای استفاده مجدد دارند. بنابراین تصمیم گرفته شد تا یک اپلیکیشن سفارشی کوچک و چابک تر توسعه دهیم.
با ModelBuilder، رویه ارکستراسیون انتزاعی می شود و می توان آن را در یک ویرایشگر مدل گرافیکی، که جزء اصلی رابط کاربری گرافیکی است، طراحی کرد. این به کاربران امکان می دهد عناصری را که نمایانگر خدمات دانلود و WPS موجود هستند، به صورت گرافیکی مرتب کنند. با اتصال عناصر، می توان جریان کار و داده مورد نظر را طراحی کرد. نماد استفاده شده برای نمودار قابل انتقال به ROLA است. یک اسکرین شات با یک مدل نمونه در شکل 2 نمایش داده شده است. یک فرآیند با کادری نشان داده می شود که عنوان آن روی آن کشیده شده و ورودی های آن در بالا و خروجی های آن در پایین قرار دارد. حروف روی ورودی ها و خروجی ها نشان می دهد که آیا یک پورت از یک نوع داده لفظی، یک جعبه مرزی یا یک نوع داده پیچیده استفاده می کند. ورودی ها و خروجی های گردش کار اطراف به صورت جعبه های مربعی معمولاً در بالا و پایین نمودار ارائه می شوند.
سرویس‌ها ممکن است به پارامترهای ورودی متعددی نیاز داشته باشند و ممکن است خروجی‌های داده متعددی را برای نتیجه ارائه دهند، بنابراین کاربران می‌توانند ورودی‌ها و خروجی‌های فرآیند خاصی را به هم متصل کنند. اقدامات ویرایش رایج، مانند افزودن، جابجایی و حذف عناصر نیز ارائه می شود. جنبه‌های قابلیت استفاده با مکانیزم یکپارچه واگرد/دوباره بهبود می‌یابد.
ModelBuilder را می توان طوری پیکربندی کرد که از اطلاعات فرآیند و سرویس غنی شده معنایی از RichWPS SemanticProxy استفاده کند. این اطلاعات ویژگی‌های عملکردی و غیرعملکردی سرویس‌ها و فرآیندهای موجود را توصیف می‌کند، که کاربران را قادر می‌سازد تا فرآیندهای WPS مناسب را در طول فاز مدل‌سازی جستجو و انتخاب کنند. نمای درختی فرآیندهای WPS موجود را نمایش می دهد. کاربران به راحتی می توانند با دوبار کلیک کردن روی گره نمای درختی یا با کشیدن و رها کردن گره ها به ویرایشگر مدل، آنها را به مدل فعلی اضافه کنند.
Ijgi 03 01334 g002 1024
شکل 2. تصویری از ModelBuilder با یک مدل گردش کار گرافیکی.
روش مدل‌سازی با نمایش اطلاعات حساس به زمینه پشتیبانی می‌شود. در میان سایر موارد، این می تواند اطلاعات پردازشی (شناسه، چکیده و غیره ) باشد، اما همچنین نکاتی برای نشان دادن اعتبار اتصالات. کمک‌های بصری با پنجره‌های ورود به سیستم همراه هستند که به کاربر اجازه می‌دهد تا رویدادهای برنامه را بازیابی و دنبال کند. علاوه بر این، از راهنمای ابزار برای ارائه اطلاعات دقیق خاص برای عناصر رابط کاربری گرافیکی بدون بارگذاری بیش از حد یا خراب کردن رابط کاربری استفاده می شود. مدل های ارکستراسیون ایجاد شده را می توان در سیستم فایل ذخیره و بارگذاری کرد.
مکانیزم اعتبارسنجی در ModelBuilder برای بررسی تطابق نوع داده و ساختار وابستگی گنجانده شده است. پس از تأیید اعتبار، مدل‌های ارکستراسیون را می‌توان ذخیره، به‌روزرسانی و در سرور RichWPS مستقر کرد. برای رسیدن به این هدف، داده های مدل به طور خودکار به ROLA ترجمه می شوند. بنابراین وابستگی‌های بین فرآیندها تجزیه و تحلیل شده و دستور اجرا تعیین می‌شود. سپس فرم سریال شده را می توان گام به گام به ROLA ترجمه کرد. در صورت وجود دو یا چند فرآیند موازی قابل اجرا، ترتیب دلخواه بین این فرآیندها تعیین می شود. سپس در سمت سرور، موتور ارکستراسیون اسکریپت ROLA را تفسیر می کند و با استفاده و اجرای فرآیندهای WPS مرتب شده و موجود، یک فرآیند WPS جدید (یا به روز شده) را درک می کند. برای اجرای فرآیند ایجاد شده می توان از یک برنامه کلاینت WPS استفاده کرد. همچنین، اجرا را می توان در ModelBuilder فراخوانی کرد. علاوه بر این، ModelBuilder برای آزمایش/اشکال‌زدایی، پروفایل‌سازی و مدیریت چرخه حیات فرآیند، مقصد مشتری است.

3.3. شرح و اجرا مدل

رابط بین RichWPS ModelBuilder و سرور RichWPS بر اساس WPS-T [ 37 ] است. این در شکل اقتباسی از برنامه افزودنی WPS 2.0 آینده WPS Transactional (WPS-T، کار/پیش نویس منتشر نشده) استفاده می شود. از اهمیت قابل توجهی برخوردار است زیرا پیش شرط بکارگیری پارادایم کد متحرک است [ 47]. این نه تنها استقرار فرآیند ساده را امکان پذیر می کند، بلکه استقرار (نیمه) خودکار را نیز امکان پذیر می کند و در نتیجه می تواند محیط های پویا را برای بهبود عملکرد (به عنوان مثال، آوردن کد به داده ها) و به اشتراک گذاری عملکرد با تحقق سرویس های ad-hoc تحقق بخشد. خود برنامه افزودنی عملیات اضافی را برای استقرار در حین پرواز و عدم استقرار فرآیندها فراهم می کند. بنابراین، عملیات اجباری DeployProcess و UndeployProcess معرفی می شوند. پشتیبانی از انواع مختلف کد فرآیند با استفاده از به اصطلاح DeploymentProfiles و بر اساس DeploymentSchemas، که در هنگام کشف قابل دسترسی هستند، به دست می آید. استقرار یک فرآیند با ارائه دو بخش انجام می شود: (1) شرح فرآیند و (2) واحد اجرا. ProcessDescription برای تعریف و قرارداد رابط فرآیند با استفاده از شناسه فرآیند و ورودی و خروجی های لازم، همانطور که در مشخصات WPS تعریف شده است، استفاده می شود. ExecutionUnit می تواند هر نوع داده ای باشد، به عنوان مثال، یک فایل باینری یا اسکریپت اجرایی. اینکه سرور از فرمت پشتیبانی می‌کند یا نه، توسط DeploymentProfiles موجود مشخص می‌شود.
در زمینه پروژه RichWPS، توضیحات ExecutionUnit با استفاده از ROLA و DeploymentProfile مطابق با آن انجام می شود. ROLA به گونه ای طراحی شده است که فرآیند و داده محور باشد و موارد اضافی را که ممکن است هنگام مخلوط کردن دامنه های (1) انقباض رابط و (2) شرح گردش کار رخ دهد حذف کند. تحقق بر اساس یک DSL خارجی به جای XML یا زبان های توصیف گردش کار است.
یک نمایش گردش کار متنی با استفاده از یک DSL خارجی، که در مقایسه با یک DSL داخلی، امکان تولید زبان ساده‌تر را فراهم می‌کند، محقق شد [ 48 ]. آن زبان بر اساس یک دستور زبان سفارشی است که می تواند برای محیط های نرم افزاری مختلف استفاده شود. با این حال، انتخاب یک DSL خارجی نسبت به یک DSL داخلی، XML یا زبان‌های خاص، مستقیماً بر تلاش‌های طراحی و پیاده‌سازی اولیه تأثیر می‌گذارد.
برای حفظ خوانایی، نمایش گردش کار قرار است صرفاً دنباله ای از فراخوانی به فرآیندهای موجود باشد. اگرچه، با توجه به تفسیر بعدی، نمایش متنی حاوی اطلاعات لازم برای، به عنوان مثال، پردازش موازی است. همانطور که در فصل بالا توضیح داده شد، نماد گرافیکی مطابق، مدل سازی بصری را امکان پذیر می کند. در مقایسه با نمایش متنی مورد نظر، نماد گرافیکی دارای درجه بالاتری از اطلاعات است. شرایطی که با تقسیم آن اطلاعات به دامنه ها و مصنوعات نامگذاری شده بالا (1) و (2) رخ می دهد.
به طور کلی، پیاده سازی زبان در یک رویه تکراری انجام می شود. تکرار اول بر عناصر اصلی زبان، ضروری برای دستیابی به زنجیره های فرآیند ساده تمرکز دارد. تکرار دوم به پارامترسازی و استفاده گسترده‌تر از پروتکل WPS به منظور پیاده‌سازی زنجیره‌های فرآیند پیچیده‌تر و بهره‌گیری از مشخصات داده‌شده می‌پردازد. با این حال، برای نزدیک شدن به یک مدل‌سازی علمی‌تر، جنبه‌های خاصی مانند سازگاری، شرایط، حلقه‌ها، محاسبات پایه و مدیریت استثنا نیز باید در نظر گرفته شوند [ 10 ]]. همچنین، هنگام فکر کردن به منابع داده، انتخاب دقیق مجموعه داده‌های خاص، به عنوان مثال انتخاب عنصر n یک مجموعه، باید در نظر گرفته شود. بنابراین، تکرار سوم بر مفاهیم پیشرفته‌تر مدل‌سازی گردش کار تمرکز دارد.

3.4. مفهوم زبان و پیاده سازی

طراحی زبان بر سه مفهوم کلیدی استوار است: (1) فرآیندهای در دسترس و محدود از راه دور باید به صراحت از هم متمایز شوند تا بتوانند اجرا را افزایش دهند. (2) اتصالات برای فرآیندهای از راه دور و محلی به طور بالقوه می تواند توسط فرآیندهای معادل مبادله شود. (3) انقباض رابط و شرح گردش کار به عنوان دو حوزه مجزا در نظر گرفته می شوند، حتی اگر عناصر مشترکی داشته باشند و به یکدیگر وابسته باشند. تفکیک این نگرانی ها با هدف حفظ خوانایی اسکریپت است و برای پنهان کردن پیچیدگی پروتکل هرجا که ممکن است استفاده می شود.
در حال حاضر، تمام این معیارها به تجلی متنی ناب منتهی می‌شوند که با ارائه چهار عنصر اصلی زبانی به زنجیره‌بندی فرآیند می‌پردازد. (1) مراجع برای ارجاع به عناصر زمان اجرا استفاده می شود، از جمله پارامترهای ورودی و خروجی تعریف شده توسط توضیحات رابط، و متغیرهای انتخاب آزاد که نتایج و مقادیر میانی را ذخیره می کنند.
(2) تخصیص ها برای تنظیم پارامترها یا متغیرهای خروجی استفاده می شوند. استفاده از تخصیص ها مشمول محدودیت هایی است، به عنوان مثال، مقادیر پارامترهای ورودی را نمی توان در زمان اجرا تغییر داد. در ترکیب با ارجاعات و بسیاری از انواع داده های اساسی، از انتساب ها برای هدایت جریان داده تا پارامترهای خروجی استفاده می شود. (3) پیوندها برای اعلام فرآیندها و تعریف نقطه پایانی مربوطه استفاده می شوند. آنها با کوتاه نویسی منحصر به فرد شناسایی و ارجاع می شوند. صحافی ها در صحافی های محلی و از راه دور متمایز می شوند. با استفاده از اتصالات محلی، به محیط زمان اجرا که مسئول اجرا است دستور داده می شود که از رابط های خارجی برای فراخوانی فرآیند استفاده نکند. اتصالات از راه دور علاوه بر این از طریق یک نقطه پایانی که با استفاده از URI کلاسیک شناسایی می شود، تعریف می شوند.
در نهایت، (4) Execute Statements برای گرد هم آوردن مراجع و اتصالات به منظور اجرای فرآیندهای WPS استفاده می شود. خود دستور execute به دو بخش برای پارامترهای ورودی و خروجی تقسیم می شود. بر خلاف تخصیص ها، این بخش ها برای اتصال مراجع زمان اجرا با پارامترهای خاص فرآیند استفاده می شوند.
جدول 2 نمای کلی از عناصر زبان را نشان می دهد.
جدول
جدول 2. مروری بر عناصر زبان.
همانند انتشار این مقاله، نمونه اولیه اولیه برای ارزیابی مفهوم محقق شده است. پیاده سازی آن بر اساس جاوا به عنوان زبان برنامه نویسی و چارچوب Xtext [ 49 ] برای تولید تجزیه کننده برای اسکریپت های ROLA است. تجزیه و اجرا در موتور ارکستراسیون انجام می شود که در سرور 52 درجه شمالی WPS V. 3.3.0 تعبیه شده است.

3.5. مانیتورینگ و پیکربندی مجدد پویا

با توجه به نیاز مکرر به بهبود QoS فرآیندهای WPS و گردش‌های کاری مکانی، یک مانیتور برای فرآیندهای WPS در حال حاضر در دست توسعه است. درخواست‌های اجرای برنامه‌ریزی‌شده برای فرآیندهای WPS انجام می‌شوند و زمان پاسخ و در دسترس بودن از طریق SemanticProxy ثبت و منتشر می‌شود. سایر مؤلفه‌ها ممکن است این داده‌ها را بخوانند و آن‌ها را با نیازهای خود مقایسه کنند تا آمادگی استفاده را تعیین کنند. مشکلات عمده ای که باید با آنها برخورد کرد این است که داده های آزمون را از کجا باید دریافت کرد و چگونه صحت نتایج پردازش را تأیید کرد.
مؤلفه‌ای که می‌تواند از داده‌های عملکرد برای بهبود خدمات استفاده کند، ModelBuilder است که کاربر می‌تواند با استفاده از داده‌ها تعیین کند که آیا فرآیندی که برای مدل‌سازی در نظر می‌گیرد، الزامات را برآورده می‌کند یا خیر. یکی دیگر سرور RichWPS است. با فرض اینکه سرور فرآیندهایی را می شناسد که معادل فرآیندها در توضیحات گردش کار خود هستند، می تواند فرآیندهای موجود در گردش کار را به طور خودکار با فرآیندهایی جایگزین کند که عملکرد بهتری ارائه می دهند. پیش شرط این امر، تطبیق معنایی برای یافتن دوقلوهای کاربردی است. این ممکن است در SemanticProxy اتفاق بیفتد.

4. چشم انداز

در حال حاضر RichWPS یک مجموعه نرم افزاری و محیط ارکستراسیون را برای OWS فراهم می کند که به ویژه بر روی WPS تمرکز دارد. سه مؤلفه اصلی SemanticProxy، ModelBuilder و RichWPS-Server با یکدیگر تعامل دارند تا یک محیط کاربر پسند را تحقق بخشند. یک زبان توصیف گردش کار معرفی شد که هدف آن کاهش فناوری و پیچیدگی قابلیت استفاده با فرض یک زمینه جغرافیایی است. در حالی که عملیات اساسی مانند کشف، مدل سازی، استقرار و اجرای گردش کار به صورت نمونه اولیه محقق شده است، برخی از کارها هنوز باز هستند.
گام بعدی در پروژه RichWPS گسترش پشتیبانی از OWS های بیشتر به خصوص WFS و WCS خواهد بود، زیرا در حال حاضر تمرکز بر WPS است.
علاوه بر این، تلاش بیشتری برای پیکربندی مجدد خودکار WPS هماهنگ شده سرمایه گذاری خواهد شد. همانطور که در فصل قبل به طور خلاصه توضیح داده شد، بهینه سازی باید در زمان اجرا با توجه به داده های QoS که توسط مانیتور ارائه می شود، انجام شود. این شامل استراتژی هایی برای تحقق تطابق معنایی نیز می شود.
اشکال زدایی یک فیلد جدید در منطقه در نظر گرفته شده است. می توان آن را در سطح ارکستراسیون به کار برد، به این صورت که نتایج موقت پس از اجرای تک فرآیندها در دسترس قرار می گیرند در حالی که اجرای بیشتر گردش کار ادامه دارد. اعمال کنترل های اجرایی دقیق مانند نقاط شکست یا اجرای گام به گام در نظر گرفته نشده است. یک تماس واحد برای جمع‌آوری نتایج موقت و بازگرداندن آنها پس از اجرای گردش کار، اولین گام عملی است. این موضوع بعداً رسیدگی خواهد شد.
به همین ترتیب، اندازه‌گیری عملکرد زمان‌های اجرا را می‌توان به عنوان بخشی از آزمایش انجام داد. پروفایل یک گردش کار نتایجی را به دست می‌دهد که فرآیندهای ضعیف را راحت‌تر و سریع‌تر از یک مانیتور شناسایی می‌کند و در عین حال سربار پیکربندی برای فرآیندهای منفرد را کاهش می‌دهد.
شرکای همکاری تاکید می کنند که نیاز به برنامه های افزودنی برای مستندسازی نتایج پردازش با ابرداده وجود دارد. از آنجایی که گستره مستندات و مفاهیم کاربردی در حال حاضر توضیح داده نشده است، این جنبه بسیار گسترده است و باید در پروژه بعدی به آن پرداخته شود.

5. نتیجه گیری ها

ارکستراسیون OWS با استفاده از WSOE در ترکیب با، به عنوان مثال، BPEL دارای اشکالات قابل توجهی است. محیط ارکستراسیون RichWPS رویکرد جدیدی از ارکستراسیون OWS را درک می کند. با پرداختن به خصوص OWS، RichWPS با استفاده از یک DSL که از مشخصات ارائه شده OGC برای ساده کردن طراحی گردش کار به میزان قابل توجهی استفاده می‌کند، بر چالش‌های مدل‌سازی گردش کار غلبه می‌کند.
RichWPS اجزای نرم افزاری لازم را فراهم می کند و از کاربر در وظایف مدل سازی گردش کار پشتیبانی می کند. اطلاعات در مورد OWS موجود برای مدلسازی گردش کار ضروری است. در RichWPS از یک سرویس دایرکتوری ارائه می شود که گزینه هایی برای جستجوی فعال معنایی نیز ارائه می دهد. این سرویس دایرکتوری SemanticProxy نام دارد. مدل سازی گردش کار را می توان با ModelBuilder انجام داد. این یک زبان نمودار گرافیکی پیچیده را ارائه می دهد که برای گردش های کاری مکانی بهینه شده است. ارکستراسیون واقعی با سرور RichWPS انجام می شود. پس از تکمیل مدل سازی، ModelBuilder می تواند برای استقرار و بازگشایی مدل های گردش کار بر روی سرور RichWPS استفاده شود. بنابراین مدل گرافیکی به یک DSL متنی ترجمه می شود. سرور RichWPS پس از استقرار، گردش کار را به عنوان یک فرآیند WPS در دسترس قرار می دهد.
با DSL و ModelBuilder الزامات برای سادگی و قابلیت استفاده برآورده شده است. از آنجایی که مفهوم کلی چندین گزینه برای ویژگی های جدید مانند اشکال زدایی یا بهبود عملکرد گردش کار ارائه می دهد، سازگاری و قابلیت همکاری نیز محقق شده است. در عین حال، مؤلفه اصلی، موتور ارکستراسیون با ارائه رابط های WPS برای تعامل، کاملاً با سیاست های تعریف شده OGC برای خدمات وب جغرافیایی سازگار است.

مراجع و یادداشت ها

  1. مولر، ام. برنارد، ال. Brauner, J. کد متحرک در زیرساخت‌های داده‌های مکانی – استقرار الگوریتم‌های پردازش جغرافیایی مبتنی بر سرویس وب. ترانس. GIS 2010 ، 14 ، 101-118. [ Google Scholar ] [ CrossRef ]
  2. فورستر، تی. شفر، بی. بارانسکی، بی. Brauner, J. خدمات وب جغرافیایی برای پردازش توزیع شده – برنامه ها و سناریوها. در خدمات وب جغرافیایی: پیشرفت در قابلیت همکاری اطلاعات ; Zhao, P., Di, L., Eds. IGI Global: Hershey PA, USA, 2011; صص 245-286. [ Google Scholar ]
  3. OGC. صفحه اصلی OGC. در دسترس آنلاین: http://www.opengeospatial.org/ (دسترسی در 17 اکتبر 2014).
  4. OGC. استانداردهای OGC در دسترس آنلاین: http://www.opengeospatial.org/standards/is (در 17 اکتبر 2014 قابل دسترسی است).
  5. Schut, P. Web Processing Service V 1.0.0 ; کنسرسیوم فضایی باز: Wayland، MA، ایالات متحده آمریکا، 2007. [ Google Scholar ]
  6. Whiteside, A. OGC Web Services Common Specification ; سند OGC؛ کنسرسیوم فضایی باز: Wayland، MA، ایالات متحده آمریکا، 2007. [ Google Scholar ]
  7. سپیکی، جی. بچی، ال. کازاگراند، ال. هالر، اس. اسکینتزوس، پی. de Jesus، J. PyWPS. در دسترس آنلاین: http://pywps.wald.intevation.org/ (دسترسی در 5 اوت 2014).
  8. ابتکار 52°North برای نرم افزار منبع باز Geospatial GmbH 52° North WPS. در دسترس آنلاین: http://52north.org/communities/geoprocessing/wps/ (در 5 اوت 2014 قابل دسترسی است).
  9. استولبرگ، بی. Zipf، A. رابط خدمات پردازش وب OGC برای هماهنگ سازی وب سرویس. در مجموعه مقالات وب و سیستم های اطلاعات جغرافیایی بی سیم هفتمین سمپوزیوم بین المللی، W2GIS 2007، کاردیف، انگلستان، 28-29 نوامبر 2007.
  10. اکرم، ع. مردیث، دی. آلن، آر. ارزیابی BPEL به گردش کار علمی. در مجموعه مقالات ششمین سمپوزیوم بین المللی IEEE در محاسبات خوشه ای و شبکه (CCGRID’06)، سنگاپور، سنگاپور، 16-19 مه 2006. جلد 1، ص 269–274.
  11. علامه، ن. زنجیره خدمات وب اطلاعات جغرافیایی. محاسبات اینترنتی IEEE. 2003 ، 7 ، 22-29. [ Google Scholar ] [ CrossRef ]
  12. ISO/TC ISO 19119:2005 — اطلاعات جغرافیایی — خدمات ; سازمان بین المللی استاندارد: ژنو، سوئیس، 2005.
  13. Schaeffer, B. OGC OWS-6 Geoprocessing Workflow Engineering Engineering Report ; کنسرسیوم فضایی باز: Wayland، MA، ایالات متحده آمریکا، 2009. [ Google Scholar ]
  14. زبان توصیف خدمات وب W3C (WSDL) نسخه 2.0 قسمت 1: زبان اصلی. در دسترس آنلاین: http://www.w3.org/TR/wsdl20/ (دسترسی در 17 اکتبر 2014).
  15. W3C SOAP Version 1.2 Part 1: Messaging Framework, (نسخه دوم) ویرایش. در دسترس آنلاین: http://www.w3.org/TR/soap12-part1/ (در تاریخ 17 اکتبر 2014 قابل دسترسی است).
  16. OASIS Web Services Security : SOAP Message Security 1 ; OASIS: برلینگتون، MA، ایالات متحده آمریکا، 2006.
  17. شنگ، QZ; کیائو، ایکس. Vasilakos، AV; سابو، سی. بورن، اس. Xu, X. ترکیب خدمات وب: مروری بر یک دهه. Icform. علمی 2014 ، 280 ، 218-238. [ Google Scholar ]
  18. دوستدار، س. Schreiner, W. نظرسنجی در مورد ترکیب خدمات وب. بین المللی J. Web Grid Serv. 2005 ، 1 ، 1-30. [ Google Scholar ] [ CrossRef ]
  19. رائو، جی. Su, X. بررسی روشهای ترکیب سرویس وب خودکار. در مجموعه مقالات اولین کارگاه بین المللی خدمات وب معنایی و ترکیب فرآیند وب، SWSWPC 2004، سن دیگو، کالیفرنیا، ایالات متحده آمریکا، 6 ژوئن 2004.
  20. سریواستاوا، بی. Koehler, J. ترکیب سرویس وب – راه حل های فعلی و مشکلات باز. در مجموعه مقالات کارگاه آموزشی ICAPS 2003 در مورد برنامه ریزی برای خدمات وب، ترنتو، ایتالیا، 10 ژوئن 2003; ص 28-35.
  21. میلانوویچ، ن. Malek, M. راه حل های فعلی برای ترکیب وب سرویس. محاسبات اینترنتی IEEE. 2004 ، 8 ، 51-59. [ Google Scholar ] [ CrossRef ]
  22. تر بیک، م. بوکیارون، آ. Gnesi, S. رویکردهای ترکیب سرویس وب: از استانداردهای صنعتی تا روش های رسمی. در مجموعه مقالات دومین کنفرانس بین المللی اینترنت و برنامه ها و خدمات وب (ICIW’07)، موریس، 13-19 مه 2007; صص 15-15.
  23. ایوانووا، ای. هماهنگی خدمات وب – استانداردها و راه حل ها. در مجموعه مقالات همایش علمی ملی “ریاضیات، انفورماتیک و علوم کامپیوتر” – خ. Cyril and St. Methodius University of Veliko Tarnovo, Veliko Tarnovo, بلغارستان, 12–13 مه 2006; صص 137-142.
  24. ائتلاف مدیریت گردش کار (WfMC) رابط تعریف فرآیند – زبان تعریف فرآیند XML (WFMC-TC-1025). در دسترس آنلاین: http://www.xpdl.org/standards/xpdl-2.2/XPDL%202.2%20(2012-08-30).pdf (دسترسی در 17 اکتبر 2014).
  25. ون در آلست، WMP; ter Hofstede، AHM YAWL: یک زبان گردش کار دیگر. آگاه کردن. سیستم 2005 ، 30 ، 245-275. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  26. Van der Aalst، WMP با جریان پیش نروید: استانداردهای ترکیب سرویس های وب در معرض دید قرار گرفتند. IEEE Intell. سیستم 2003 ، 18 ، 72-85. [ Google Scholar ]
  27. ژائو، پی. فورستر، تی. یو، پی. وب ژئوپردازش. محاسبه کنید. Geosci. 2012 ، 47 ، 3-12. [ Google Scholar ] [ CrossRef ]
  28. Apache Software Foundation Apache ODE. در دسترس آنلاین: http://ode.apache.org/ (دسترسی در 17 اکتبر 2014).
  29. Louridas, P. ارکستراسیون خدمات وب با bpel. نرم افزار IEEE 2008 ، 25 ، 85-87. [ Google Scholar ] [ CrossRef ]
  30. مونتسی، اف. جولی. در دسترس آنلاین: http://www.jolie-lang.org/ (دسترسی در 17 اکتبر 2014).
  31. پروژه زبان اورک دانشگاه تگزاس در آستین. در دسترس آنلاین: https://orc.csres.utexas.edu/ (دسترسی در 17 اکتبر 2014).
  32. مونتسی، اف. گوئیدی، سی. Zavattaro, G. برنامه نویسی سرویس گرا با جولی. وب سرور پیدا شد. 2014 . [ Google Scholar ] [ CrossRef ]
  33. چوی، ی. گارگ، ا. رای، اس. میسره، ج. وین، اچ. محاسبات هماهنگ در وب جهانی. در مجموعه مقالات پردازش موازی: هشتمین کنفرانس بین المللی یورو-پار، هایدلبرگ، آلمان، 27 تا 30 اوت 2002.
  34. بنیاد نرم افزار آپاچی Apache CXF. در دسترس آنلاین: http://cxf.apache.org/docs/java-to-wsdl.html (در 17 اکتبر 2014 قابل دسترسی است).
  35. کیهله، سی. هییر، سی. Greve, K. الزامات برای نسل بعدی زیرساخت‌های داده‌های مکانی مبتنی بر ژئوپردازش مبتنی بر وب و هماهنگ‌سازی خدمات وب. ترانس. GIS 2007 2008 ، 11 ، 819-834. [ Google Scholar ]
  36. فریس کریستنسن، ا. Ostländer، N. طراحی معماری خدمات برای پردازش جغرافیایی توزیع شده: چالش ها و جهت گیری های آینده. ترانس. GIS 2007 ، 11 ، 799-818. [ Google Scholar ] [ CrossRef ]
  37. Schaeffer, B. Towards a Towards a Tractional Web Processing Service. در مجموعه مقالات GI-Days، مونستر، آلمان، 16-18 ژوئن 2008.
  38. ویزر، آ. نیس، پ. Zipf, A. Orchestrierung von OGC Web Diensten im Katastrophenmanagement am Beispiel eines Emergency Route Service auf Basis der OpenLS Spezifikation. GIS-Zeitschrift für Geoinformatik 2006 ، 9 ، 35-41. [ Google Scholar ]
  39. Sonnet, J. OWS 2 Common Architecture: WSDL SOAP UDDI ; Open Geospatial Consortium Inc.: Wayland، MA، USA، 2004. [ Google Scholar ]
  40. راهنمای کاربر OpenPlans WPS Processes-GeoServer 2.5.x. در دسترس آنلاین: http://docs.geoserver.org/stable/en/user/extensions/wps/processes.html#process-chaining (در 24 ژوئن 2014 قابل دسترسی است).
  41. صفحه اصلی پروژه تاورنا. در دسترس آنلاین: http://www.taverna.org.uk/ (در 12 مه 2014 قابل دسترسی است).
  42. دی عیسی، جی. واکر، پی. گرانت، ام. Groom، S. WPS ارکستراسیون با استفاده از میز کار Taverna: رویکرد eScience. محاسبه کنید. Geosci. 2012 ، 47 ، 75-86. [ Google Scholar ] [ CrossRef ]
  43. براونر، جی. فورستر، تی. شفر، بی. بارانسکی، ب. به سوی یک دستور کار تحقیقاتی برای خدمات ژئوپردازش. در مجموعه مقالات دوازدهمین کنفرانس بین المللی AGILE در علم اطلاعات جغرافیایی (2009)، شیکاگو، IL، ایالات متحده آمریکا، 24-28 اوت 2009; جلد 1، ص 1-12.
  44. Menascé، DA; Mason, G. QoS مسائل در خدمات وب. 2002 . [ Google Scholar ] [ CrossRef ]
  45. Spark – یک چارچوب وب کوچک برای جاوا. در دسترس آنلاین: http://www.sparkjava.com/ (دسترسی در 14 مه 2014).
  46. openRDF.org. در دسترس آنلاین: http://www.openrdf.org/ (دسترسی در 14 مه 2014).
  47. مولر، ام. برنارد، ال. کدنر، دی. کد جابجایی – به اشتراک گذاری منطق پردازش جغرافیایی در وب. ISPRS J. Photogramm. Remote Sens. 2013 ، 83 ، 193-203. [ Google Scholar ] [ CrossRef ]
  48. Fowler, M. Domain Specific Languages , 1st ed.; Addison Wesley Professional: بوستون، MA، ایالات متحده آمریکا، 2010; صص 105-111. [ Google Scholar ]
  49. توسعه زبان Xtext آسان شد. در دسترس آنلاین: http://www.eclipse.org/Xtext/ (دسترسی در 14 مه 2014).

;کاربردهای GISمقالات

آموزش کاربردی ArcGISالهام ابراهیم زادهکاربرد جی ای اسکاربرد جی ای اس در زمین شناسی

بدون نظر

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

همواره حمایت دانشجویان عزیزمان همراه ما بوده و این سببب شده که گامی محکم به‌سوی ایجاد یک مرجع برای آموزش GIS برداریم. با این امید که بتوانیم قدردان حمایت شما بزرگواران باشیم.

  • خانه
  • آموزش
  • فیلم آموزشی
  • تماس با ما
  • درباره ما
  • وبلاگ
  • سمنان /خیابان کاشانی/ساختمان فناوری اطلاعات/پ 8
  • 09120049370