نقشه راه GIS

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

09120049370

8 صبح تا 12 شب

09120049370

کاربرد جی ای اس

 

خلاصه

شناسایی مکانیسم‌های مناسب برای اشتراک‌گذاری فرآیند و استفاده مجدد از طریق ترکیب، یک عامل کلیدی برای جذب مؤثر زیرساخت‌های جهانی رصد زمین در نظر گرفته می‌شود که در حال حاضر توسط جامعه تحقیقاتی بین‌المللی زمین‌فضایی دنبال می‌شود. طبق رویکرد کارگزاری، مدل‌سازانی که نیاز به اجرای گردش‌های کاری پیچیده دارند، ممکن است از برون‌سپاری ترکیب فرآیند به یک سرویس خارجی اختصاصی بهره ببرند. این کار معماری ما از یک کارگزار فرآیند را به عنوان یک سیستم اطلاعاتی توزیع‌شده برای ایجاد، اعتبارسنجی، ویرایش، ذخیره‌سازی، انتشار و اجرای گردش‌های کاری مدل‌سازی مکانی معرفی می‌کند. کارگزار چارچوب خدماتی را برای انطباق، استفاده مجدد و تکمیل منابع پردازش موجود (شامل مدل‌ها و خدمات مکانی به طور کلی) در قالب قابلیت همکاری فراهم می‌کند. گردش کار قابل اجرا راه حل توصیف شده به طور تجربی در چندین سناریو استفاده در زمینه پروژه های با بودجه اتحادیه اروپا و سیستم جهانی رصد زمین از سیستم ها استفاده شده است.
کلید واژه ها: 

وب مدل ; دلالی ; خدمات پردازش ; میانجیگری ؛ ترکیب خدمات ; سیستم های اطلاعات جغرافیایی ; زیرساخت های داده های مکانی

 

1. معرفی

شناسایی مکانیسم‌های مناسب برای اشتراک‌گذاری فرآیند و استفاده مجدد، یعنی با استفاده از ترکیب (که خط لوله، یا زنجیره‌بندی، ممکن است مورد خاصی در نظر گرفته شود)، یک عامل کلیدی برای جذب مؤثر زیرساخت جهانی رصد زمین در نظر گرفته می‌شود، که در حال حاضر دنبال می‌شود. توسط جامعه تحقیقاتی بین المللی در علوم زمین و فضایی، در ابتکاراتی مانند سیستم جهانی مشاهده سیستم های زمین (GEOSS).
چنین تسهیلاتی می‌تواند به طور مؤثر یکپارچه‌سازی و قابلیت همکاری مدل‌های علمی را برای آنچه که چندین رویکرد در سال‌های گذشته در سطوح فزاینده انتزاع و تعمیم پیشنهاد و توسعه داده‌اند، امکان‌پذیر کند [ 1 ].
در واقع، ابزارهای اولیه نرم‌افزاری stove-pipe به چارچوب‌های مدل‌سازی در سطح جامعه، سپس به راه‌حل‌های معماری مبتنی بر مؤلفه، و اخیراً با قدرت‌گیری توسط وب، شروع به پذیرش فناوری‌های معماری سرویس‌محور کرده‌اند، که به عنوان پدیدار شده‌اند. مکانیزمی برای مونتاژ خدمات فردی برای ایجاد برنامه های کاربردی سفارشی، همچنین در بخش جغرافیایی [ 2 ].
در واقع، GEOSS به طور خاص وظیفه توسعه به اصطلاح “مدل وب” را بر عهده دارد: یک زیرساخت مدل سازی پویا برای خدمت به محققان، مدیران، سیاست گذاران و عموم مردم. این متشکل از مدل‌هایی است که به‌طور آزادانه جفت شده‌اند که از طریق سرویس‌های وب تعامل دارند، و به طور مستقل توسعه، مدیریت و اجرا می‌شوند [ 3 ].
با این حال، تا به امروز، چالش‌های متعددی باقی مانده است و هم ارائه‌دهندگان خدمات و هم مصرف‌کنندگان باید به جنبه‌های تکنولوژیکی بسیار پیچیده بپردازند [ 4 ]. به طور خاص، سطح انتزاع راه‌حل‌های فعلی برای ترکیب سرویس برای پیاده‌سازی چشم‌انداز وب مدل بسیار پایین به نظر می‌رسد، که منجر به قابلیت استفاده محدود و جذب دشوار می‌شود.
برای رسیدگی به این مشکل، پیشنهاد شده است که کاربرانی که نیاز به اجرای گردش‌های کاری پیچیده، مانند مواردی که از مدل‌های محیطی نشات می‌گیرند، ممکن است از برون‌سپاری فعالیت‌های ترکیب به یک سرویس خارجی اختصاصی بهره ببرند، طبق Composition-as-a-Service. رویکرد CaaS) [ 5 ].
CaaS مفهومی را تعمیم می دهد که به عنوان زنجیره خدمات مدیریت شده با گردش کار (معروف به زنجیره شفاف) [ 2 ] شناخته می شود و مزایای مشابهی را نسبت به سیستم های کاملاً جفت شده، بسته و یکپارچه که در تنظیمات محلی GIS اجرا می شوند، ارائه می دهد، که عموماً نیاز به سفارشی سازی با سیم سخت، فاقد انعطاف پذیری، و پشتیبانی محدودی از توزیع فرآیند، اشتراک گذاری و استفاده مجدد ارائه می دهد.
در این کار، ما یک راه‌حل پیشرفته CaaS را ارائه می‌کنیم که ترکیب خدمات را به یک ظرفیت میانجی هوشمند که به عنوان یک کارگزار عمل می‌کند، واگذار می‌کند.
ما معماری یک کارگزار فرآیند را به عنوان یک سیستم اطلاعاتی توزیع‌شده برای ایجاد، اعتبارسنجی، ویرایش، ذخیره، انتشار و اجرای گردش‌های کاری مدل‌سازی مکانی در وب معرفی می‌کنیم. راه حل توصیف شده در چندین سناریو استفاده در چارچوب پروژه FP7 UncertWeb پیاده سازی، آزمایش و ارزیابی شده است. همچنین برای سناریوهای مدل‌سازی در چارچوب پروژه FP7 MEDINA و پایلوت پیاده‌سازی معماری GEOSS اعمال شده است.
سهم اصلی ما استفاده از رویکرد واسطه گری است، [ 6 ، 7 ] که ما با موفقیت برای کشف [ 8 ، 9 ، 10 ]، خدمات معنایی [ 11 ] و دسترسی [ 12 ، 13 ] (به عنوان مثال، در پروژه FP7 EuroGEOSS) به کار بردیم. [ 14 ، 15 ])، برای فعال کردن ترکیب سرویس سطح بالا و کاربر پسند، مطابق با معماری وب مدل GEOSS.
بخش بعدی مروری بر پیشینه تکامل رویکردهای مدل‌سازی و فناوری‌های مرتبط ارائه می‌کند. در بخش 3 رویکرد کارگزار فرآیند و ارزش افزوده آن را توضیح می دهیم. در بخش 4 ما معماری راه حل Process Broker خود را با تمرکز بر مدل مفهومی و عملکرد اصلی آن در تبدیل گردش های کاری انتزاعی به موارد اجرایی توضیح می دهیم. در بخش 5 ما در مورد پیاده سازی و ارزیابی نمونه اولیه آن گزارش می دهیم. در نهایت، در بخش 6 ما کار آینده نگر خود را در مورد موضوع نتیجه گیری و ترسیم می کنیم.

2. کارهای مرتبط

یک رویکرد مدل‌سازی ساده از ابزارهای نرم‌افزاری فردی برای اجرای شبیه‌سازی‌های انتخاب شده با هدف جوامع خاص بهره‌برداری می‌کند. به عنوان مثال، OpenModeller [ 16 ] یک ابزار متن باز است که یک رویکرد همبستگی را برای مدل‌سازی طاقچه اکولوژیکی پیاده‌سازی می‌کند. معمولاً یک رابط کاربری گرافیکی (GUI) به کاربر این امکان را می‌دهد تا پارامترها و الگوریتم‌های شبیه‌سازی را انتخاب کند و به خروجی دسترسی پیدا کند و تجسم کند. این ابزارها معمولاً منبع باز هستند تا از افزونه و سفارشی سازی پشتیبانی کنند. گاهی اوقات عملکردهای پیشرفته تر از طریق یک رابط سرویس باز در معرض دید قرار می گیرند. با این حال، ادغام چنین ابزارهایی در سناریوهای پیچیده‌تر می‌تواند دشوار باشد، زیرا قابلیت‌های مفید برای ترکیب، مانند ورود به سیستم و مدیریت رویداد، ممکن است اجرا نشوند.
نیاز به مدل‌سازی تعاملی منجر به طراحی چارچوب‌هایی مانند Object Modeling System، ModCom، The Invisible Modeling Environment، OpenMI و غیره می‌شود . اینها در چندین جنبه متفاوت هستند که منعکس کننده نیازهای مختلف جوامع هدف هستند، از جمله دامنه دامنه (تک در مقابل چند رشته ای)، عملکرد (زنجیره سازی مدل در مقابل شبیه سازی گام به گام) و فناوری (تک در مقابل چند رشته ای). چند پلتفرم). اگرچه این چارچوب‌ها عملکردهای ارزشمندی را ارائه می‌کنند، اما محدودیت‌هایی را نیز بر توسعه‌دهندگان مدل و یکپارچه‌کننده‌ها تحمیل می‌کنند، مانند نیاز به یک زبان برنامه‌نویسی خاص یا پلت فرم توسعه/استقرار. چنین محدودیت هایی دامنه کاربرد را محدود می کند و می تواند موانع ورود را افزایش دهد. از آنجایی که این چارچوب‌ها معمولاً محیط‌های بسته هستند، قابلیت همکاری مدل‌های توزیع‌شده فضایی، یا مدل‌های پیاده‌سازی شده در چارچوب‌های مختلف، می‌تواند محدود باشد.
معماری‌های مبتنی بر مؤلفه (CBAs) مکانیسم‌ها و تکنیک‌هایی را برای توسعه واحدهای پیاده‌سازی فنی درشت و در عین حال قابل استفاده مجدد که از زمینه آگاه هستند، در بر می‌گیرد. در یک CBA، واحدهای نرم‌افزار به‌عنوان «مولفه‌هایی» کپسوله می‌شوند که از طریق رابط‌های کاملاً تعریف شده با یکدیگر تعامل دارند. این واحدهای قابل مدیریت نرم افزار را می توان در برنامه های کاربردی پیچیده در “برنامه های کانتینری” خاص تشکیل داد. به عنوان مثال، ابزارهای معروف Kepler [ 17 ] و Taverna [ 18 ] هستند که به طور گسترده توسط جوامع تحقیقاتی خاص برای مدیریت گردش کار علمی استفاده می شود. برای بهبود قابلیت استفاده در جوامع دیگر، رابط های کاربری مبتنی بر وب کاربر پسند در حال بررسی هستند.
یک گام بیشتر به سمت مدل‌سازی متقابل مبتنی بر معماری سرویس‌گرا (SOA) است. در اینجا، مدل‌ها به عنوان خدمات در معرض نمایش قرار می‌گیرند، بنابراین توافق‌نامه‌های قابلیت همکاری از محیط فنی به مشخصات رابط تغییر می‌کنند، مانند CBA. یک مثال، سرویس وب eHabitat برای مدل‌سازی اکولوژیکی [ 19 ] است. این رویکرد ادغام سیستم‌های قدیمی و مدل‌های توزیع‌شده فضایی را به نحوی نزدیک‌تر به اصول وب مدل ممکن می‌سازد، که عبارتند از: [ 1 ]

  • دسترسی باز—هرکسی می‌تواند یک سرویس برای اشتراک‌گذاری مدل خود ایجاد کند و هر کسی (یا هر ماشینی) می‌تواند به آن دسترسی داشته باشد.
  • حداقل موانع ورود – جذب آسان هم برای ارائه دهندگان منابع (مدل نویسانی که مدل خود را در وب به اشتراک می گذارند) و هم برای کاربران (به عنوان مثال، مدل سازان دیگر که آن مدل ها را در خود ترکیب می کنند، یا کاربران نهایی که خروجی را در مرورگر خود تجسم می کنند).
  • رویکرد سرویس‌محور – دسترسی توسط سرویس‌ها (به عنوان مثال ، خدمات وب) از چارچوب خدمات توزیع شده همه منظوره ( به عنوان مثال ، WWW) ارائه می‌شود و منابع تخصصی از منابع توزیع شده عمومی هستند (به عنوان مثال ، منابع WWW).
  • مقیاس پذیری – رشد تصاعدی ذاتاً توسط فناوری های وب پشتیبانی می شود.
در دهه گذشته، چندین راه حل برای فعال کردن ترکیب سرویس و مدیریت گردش کار ارائه شده است، که اغلب در رابطه با مسائل وب معنایی [ 20 ، 21 ] است.
W3C و OASIS از جمله مروجین اصلی قابلیت همکاری و استانداردسازی هستند که به ترتیب بر ایجاد اجماع و ایجاد توسعه، همگرایی و پذیرش در زمینه فناوری های وب و استانداردهای کسب و کار الکترونیکی تمرکز دارند. کنسرسیوم فضایی باز (OGC) یک گروه کاری دامنه گردش کار را فعال کرد تا یک انجمن برای رسیدگی به مسائل مربوط به گردش های کاری مکانی ایجاد کند.
استانداردهای باز، مانند پشته WS-* از مشخصات W3C برای ترکیب سرویس، WSDL و سرویس پردازش وب OGC (WPS) [ 22 ] به انتزاع سیستم حاصل از فناوری های پیاده سازی اتخاذ شده، و پشتیبانی از مدل سازی در وب کمک می کند. استاندارد OASIS به طور گسترده برای اجرای گردش کار در حوزه تجارت الکترونیک، WS-BPEL (یا به طور خلاصه BPEL)، برای کاربردهای علمی در نظر گرفته شده است [ 23 ].
با توجه به پیچیدگی و مسائل قابل حمل BPEL، مدل استاندارد فرآیند کسب و کار و علامت گذاری (BPMN) به عنوان یک فرمت کاربر پسندتر برای ضبط گردش کار پیشنهاد شده است، که ممکن است یک فرآیند BPEL از آن تولید شود [ 24 ].

3. رویکرد کارگزار فرآیند

ارائه‌دهنده یک مدل محیطی باید وظایف پیچیده فناوری را انجام دهد تا آن را در وب در دسترس قرار دهد. یک رابط رسمی برای مدل باید طراحی و توسعه یابد، ترجیحاً مطابق با مشخصات استاندارد (مثلاً SOAP یا WPS) و مهمتر از آن، ارائه یک توصیف عملی، دقیق (و در حالت ایده آل بدون ابهام) از آن رابط و انتشار آن ضروری است. آن را در یک رجیستر، برای اینکه مدل قابل جستجو و استفاده باشد. به همین ترتیب، مصرف کنندگان احتمالی مدل باید بتوانند توصیف آن را بازیابی و تفسیر کنند تا آن را در جریان کاری خود ادغام کنند.
این با سناریوی فعلی وب متفاوت است، جایی که انتشار یک سند را می توان بدون دانش زیادی در مورد نحوه کار وب انجام داد، به لطف ابزارهای بصری که معمولاً به مهارت های برنامه نویسی نیاز ندارند. ابزارهای ترکیب‌بندی خاص از سیم‌کشی بصری منابع وب و ویجت‌های رابط کاربری گرافیکی با هم پشتیبانی می‌کنند و امکان تولید mashup‌هایی را فراهم می‌کنند که ارزش داده‌ها را غنی می‌کنند. این ابزارها به دیدگاه جدیدی از وب، به اصطلاح Web 2.0 کمک می کنند، که در آن سهم کاربران قابل توجه است.
رویکرد Process Broker با استفاده از یک سرویس خارجی اختصاصی، چارچوب همکاری لازم را برای انطباق، استفاده مجدد و تکمیل منابع پردازش موجود (شامل مدل‌ها و خدمات مکانی به طور کلی) در قالب گردش‌های کاری قابل اجرا، برای ترکیب سرویس اعمال می‌کند. 25 ].
به این ترتیب، کاربر می تواند از نیاز به یک زیرساخت ترکیب رها شود و از نکات فنی تعاریف گردش کار (تطبیق نوع، شناسایی نقاط پایانی سرویس های خارجی، مسائل الزام آور و غیره ) بکاهد تا بهتر بر هدف خود تمرکز کند. کاربرد.
علاوه بر این، Process Broker می‌تواند توصیه‌هایی به دست آمده از یک پایگاه دانش انبوه از تعاملات و بازخورد کاربر، احتمالاً مبتنی بر فناوری‌های Web 2.0، برای کمک به کاربر در طول طراحی و اجرا، به عنوان مثال، پیشنهاد مدل‌ها یا مقادیر پارامترهای اضافی که معمولاً در موارد استفاده می‌شوند، ارائه دهد. علاقه. یا کاربر ممکن است یک تعریف جریان کار تا حدی انتزاعی ارائه دهد و از توصیه های Process Broker برای اتصال آن به نمونه های خدمات اجرایی استفاده کند.
این موضوع در زمینه‌های علمی چند رشته‌ای، که در آن جوامع مختلف ممکن است از یکدیگر بهره ببرند، از طریق اعمال نفوذ و به اشتراک گذاشتن دانش به دست آمده از طریق ترکیب مدل، از اهمیت خاصی برخوردار است.
در واقع، رویکرد کارگزار فرآیند از ترکیب پیشرفت‌های اخیر در محاسبات سرویس‌محور با اصول تحقیقات مشترک و شبکه‌های اجتماعی به طور کلی پشتیبانی می‌کند. شاید بتوان آن را یک قابلیت اساسی مدل وب در نظر گرفت.
روند اخیر ICT مجازی سازی منابع منجر به معرفی مفاهیمی مانند Infrastructure-as-a-Service (IaaS)، Platform-as-a-A-Service (PaaS) و Software-as-a-Service (SaaS) شده است. IaaS قدرت محاسباتی مجازی و فضای ذخیره‌سازی را فراهم می‌کند که در آن مصرف‌کننده می‌تواند نرم‌افزار دلخواه را، اغلب با قابلیت‌های پیشرفته‌ای مانند تعادل بار، اجرا کند. یک مثال معمولی آمازون EC2/S3 است. PaaS محیط های توسعه برنامه را فراهم می کند که از زبان های برنامه نویسی مختلف و عملکردهای رایج مانند دسترسی به پایگاه داده، کش کردن و غیره پشتیبانی می کند.. به عنوان مثال Google App Engine است. SaaS دسترسی مستقیم را، معمولاً از طریق یک مرورگر وب، به برنامه‌هایی که روی زیرساخت محاسباتی اجرا می‌کنند، فراهم می‌کند. تکامل آن بر اساس مدل خدمات ابری نیز به عنوان فرآیند کسب و کار به عنوان یک سرویس (BPaaS) شناخته می شود. Google Docs یکی از پرکاربردترین SaaS/BPaaS است [ 26 ]. رویکرد CaaS Process Broker تا حدودی در سطح متوسطی بین PaaS و SaaS قرار دارد: عملکرد “اجرای فرآیند” آن ممکن است به سطح برنامه (به عنوان مثال ، SaaS) مرتبط باشد، در حالی که “ترکیب فرآیند” آن از نظر عملکردی شبیه به یک سطح پایین تر است. پلتفرم محاسباتی سطحی، که برنامه های کاربردی دلخواه را می توان روی آن پیاده سازی کرد (به عنوان مثال ، PaaS).

4. معماری کارگزار فرآیند

طراحی Process Broker [ 27 ] بر اساس منطق زیر است: پشتیبانی از استفاده مجدد و ادغام منابع موجود (رویکرد سیستم از سیستم). ادغام با زیرساخت مشترک GEOSS (GCI) و اصول وب مدل. با خط پایه استاندارد OGC مطابقت داشته باشد.
با استفاده از رویکرد واسطه گری-SOA [ 6 ]، ما یک سرویس میانجی هوشمند طراحی کردیم که دو نقش اصلی را ایفا می کند: به عنوان یک ارکستر، می تواند خدمات لازم را به ترتیب صحیح برای اجرای یک گردش کار پیچیده فراخوانی کند. به عنوان یک واسطه، می‌تواند عدم تطابق را در مدل‌های رابط و (متا) داده‌های سرویس‌های فراخوانی شده مدیریت کند و همچنین به کاربر در مراحل طراحی و اجرا کمک کند.
یک جنبه تکنولوژیکی کلیدی Process Broker استفاده از BPMN برای رمزگذاری گردش کار است. از این رو، هر ویرایشگر استاندارد BPMN می تواند برای ویرایش یک گردش کار در مرحله طراحی استفاده شود. برخلاف BPEL که معمولاً مورد استفاده قرار می‌گیرد، BPMN توسعه داده شده است تا کاربران را قادر سازد تا نمایش‌های گرافیکی قابل درک گردش کار را به عنوان یک پل استاندارد بین طراحی فرآیند و پیاده‌سازی تعریف کنند [ 24 ]. ما BPMN را به BPEL ترجیح دادیم زیرا دومی به توصیفات WSDL متکی است که در حال حاضر در OGC به خوبی پذیرفته نشده است.
یک رابط اجرای وب به کاربر اجازه می دهد تا اجرای ناهمزمان جریان های کاری را که توسط Process Broker در دسترس است، انتخاب، شروع و نظارت کند. برای دسترسی ماشین به ماشین، Process Broker یک رابط استاندارد WPS را برای اجرای گردش کار، و همچنین یک رابط را به یک رجیستری داخلی بر اساس استانداردهای جغرافیایی فراگیر ISO 19115 و ISO 19119 نشان می دهد [ 28 ، 29 ]]، جایی که گردش‌های کاری منتشر شده به همراه کتابخانه مدل‌ها و مؤلفه‌های پشتیبانی شده توسط Process Broker ذخیره می‌شوند. این رجیستری داخلی با ثبت خدمات GCI که به تمام نمونه‌های خدمات مکانی ارائه شده به GEOSS اشاره می‌کند، ادغام می‌شود. این طرح از قابلیت استفاده مجدد ماژول های نرم افزار موجود، مانند تعداد فزاینده پلاگین های میانجی که GEO Discovery & Access Broker [ 30 ] را توانمند می کند، پشتیبانی می کند.
در ادامه این فصل، مدل مفهومی Process Broker و یکی از عملکردهای اصلی آن را توضیح می دهیم: مکانیزمی که از تبدیل BP های انتزاعی به موارد ملموس (اجرا) پشتیبانی می کند. معماری سیستم کامل Process Broker یک چارچوب خدمات کامل را برای مدلسازی منابع تعریف می کند که چندین عملکرد دیگر را پیاده سازی می کند [ 27 ].

4.1. مدل مفهومی

شکل 1 مفاهیم مورد علاقه برای کارگزار فرآیند را با روابط متقابل آنها نشان می دهد.
شکل 1. مدل مفهومی کارگزار فرآیند.
مفهوم پایه فرآیند کسب و کار است ، به عنوان مثال ، پدیده انتزاعی کلی که کاربر می خواهد شبیه سازی کند، معمولاً برای پاسخ به یک سؤال “چه می شود اگر”، همانطور که در شکل 2 نشان داده شده است. یک فرآیند کسب و کار در مرحله طراحی به یک مدل رسمی فرآیند کسب و کار مدل می شود. از آنجایی که نهاد مفهومی ذکر شده باید از زمینه مشخص باشد، در ادامه این مقاله ممکن است به “مدل فرآیند کسب و کار” به سادگی به عنوان “فرایند تجاری” (به طور خلاصه BP) اشاره کنیم. مرحله طراحی با رویکرد ترکیب مشخص می شود ، یعنی تحقق عملکرد مورد نظر با استفاده از فرآیندهای موجود.توسط اشخاص ثالث یا توسط خود کارگزار فرآیند ارائه شده است.
یک فرآیند ممکن است به عنوان یک سرویس ، به عنوان مثال ، یک عملکرد متمایز ارائه شده توسط یک موجودیت از طریق مجموعه ای نامگذاری شده از عملیات که رفتار آن را مشخص می کند، نمایش داده شود. در چارچوب Process Broker، یک سرویس یک مفهوم مهندسی برای پشتیبانی از توزیع سیستم است، از این رو فرآیندهای محلی (به عنوان مثال، وظایف داخلی) معمولا به عنوان خدمات در معرض نمایش قرار نمی گیرند. علاوه بر این، دامنه Process Broker محدود به خدمات نرم افزاری است که معمولاً به عنوان خدمات وب پیاده سازی می شوند .
یک BP باید به عنوان یک مدل فرآیند تجاری اجرایی منتشر شود ، قبل از اینکه بتواند توسط موتور اجرایی داخلی کارگزار فرآیند تفسیر و اجرا شود. مشابه کامپایل کد منبع، انتشار مستلزم حل همه جنبه های احتمالاً مبهم و ناقص است (مثلاً، نقاط پایانی از دست رفته به نمونه های خدمات مشخص، مسائل الزام آور، عدم تطابق نوع)، و همچنین اعتبارسنجی BP. در ادامه این مقاله ممکن است به “مدل فرآیند تجاری اجرایی” به سادگی به عنوان “فرایند تجاری اجرایی” (به طور خلاصه EBP) اشاره کنیم. یک Run نتیجه اجرای یک EBP را نشان می‌دهد، از جمله خروجی به‌دست‌آمده، و همچنین منشأ و اطلاعات جانبی اضافی (گزارش‌های خطا و غیره ).
نکته قابل توجه، راه حل توصیف شده Process Broker یک EBP را به عنوان یک نقطه پایانی WPS ، که خود یک سرویس (وب) است، پیاده سازی می کند، و از این رو می تواند بخشی از BP های دیگر شود. به عبارت دیگر، BP تازه منتشر شده فوراً برای استفاده مجدد در دسترس است و بر خلاف سایر راه حل های گردش کار، Process Broker اجازه می دهد تا خدمات را به سرعت بنویسید و به کار بگیرید.
این یک جنبه کلیدی Process Broker است، زیرا یک رابط استاندارد برای فراخوانی BP ها فراهم می کند و ترکیب بازگشتی آنها را امکان پذیر می کند.
شکل 2. مثالی از یک فرآیند تجاری انتزاعی.

4.2. کنوانسیون های کارگزار فرآیند

یکی از عملکردهای اصلی ارائه شده توسط Process Broker، تبدیل BP های انتزاعی به موارد ملموس (اجرا) است. برای رسیدن به این هدف، Process Broker اجزای مختلف فرعی یک BP را به مصنوعات نرم افزاری مناسب، چه به صورت ایستا، پس از انتشار، یا به صورت پویا، پس از اجرا، مرتبط می کند. چنین ارتباطی با مجموعه ای از قراردادها که باید در طراحی BP رعایت شود تسهیل می شود. یعنی سند BPMN حاصل باید با قراردادهای Process Broker مطابقت داشته باشد.
به عنوان مثال، کنوانسیون ها طبقه بندی اجزای پشتیبانی شده توسط Process Broker را تعریف می کنند. با توجه به عملکرد آنها، چهار دسته اصلی از اجزای BP تعریف می شوند:

  • دسترسی: اجرای عملیات دسترسی به داده ها.
  • انتشار: انتشار داده ها به خدمات دسترسی استاندارد؛
  • پردازش: اجرای نوعی پردازش، از جمله ژئوپردازش بر اساس طبقه بندی ISO 19119.
  • Utility: قابلیت‌های پردازش اولیه (به عنوان مثال، وارونگی ماتریس، FFT) که به عنوان فرآیندهای کاربر ساده استفاده می‌شوند.
هر یک از مقوله‌های فوق در زیرمجموعه‌هایی ساختار یافته‌اند که ویژگی‌های اصلی والدین را تخصصی می‌کنند. به لطف قراردادها، Process Broker می‌تواند هر جزء انتزاعی را در یک BP به یک ماژول نرم‌افزار مناسب متصل به سرویس (احتمالاً راه دور) متصل کند که در واقع فرآیند را تحقق می‌بخشد. تمام واسطه های نحوی و معنایی مورد نیاز برای گنجاندن سرویس در گردش کار در ماژول تفکیک شده است. در حال حاضر، خدمات پشتیبانی شده شامل خدمات اصلی وب OGC و پروفایل های WPS خاص برای مدل های انتخاب شده است.
قراردادهای Process Broker با استفاده از حاشیه نویسی مناسب اضافه شده به رمزگذاری BPMN یک BP اجرا می شود. از این رو، هر دو BP و EBP فقط اسناد استاندارد BPMN هستند و برای برخی از حاشیه نویسی ها متفاوت هستند (EBP ها ممکن است شامل اجزای میانجی اضافی نیز باشند که توسط Process Broker معرفی شده اند، در صورت نیاز، به زیر مراجعه کنید).
پس از مرحله اتصال، Process Broker یک بررسی سازگاری I/O از اجزای BP را اجرا می کند و ورودی ها و خروجی های آنها را مطابقت می دهد. این امکان پذیر است زیرا هر ماژول واسطه دارای مجموعه ای از پارامترهای ورودی/خروجی به خوبی تعریف شده است. هنگامی که یک عدم تطابق ورودی/خروجی تشخیص داده می‌شود، کارگزار فرآیند ممکن است آن را با درج اجزای میانجی اضافی (مثلاً یک بلوک تبدیل فرمت)، که از بین موارد موجود در کتابخانه مؤلفه‌اش انتخاب شده است، حل کند. پارامترهای ورودی که بی‌همتا باقی می‌مانند، قرار است پس از اجرا توسط کاربر ارائه شوند. این اطلاعات برای ایجاد یک سند ProcessDescription استاندارد برای رابط OGC WPS از Process Broker استفاده می شود.

5. اجرا و ارزیابی

راه حل توصیف شده در ابتدا در چارچوب پروژه FP7 UncertWeb نمونه سازی و آزمایش شده است. پیاده سازی مرجع بر اساس فناوری Java EE و بر روی کانتینر وب آپاچی تامکت [ 31 ] است. موتور اجرایی نمونه اولیه Process Broker بر اساس فناوری مدیریت فرآیندهای تجاری JBoss (jBPM) است. هسته jBPM یک موتور گردش کار سبک وزن و قابل توسعه است که با جاوا خالص نوشته شده است که اجازه می دهد BP های حاشیه نویسی را با استفاده از آخرین مشخصات BPMN 2.0 اجرا کنید. با این حال، jBPM بر اساس یک موتور فرآیند عمومی است، و بنابراین قادر به پشتیبانی از چندین زبان فرآیند به صورت بومی است [ 32 ].
Process Broker در دو سناریو استفاده ارزیابی شده است: یک سناریوی ارزیابی زیستگاه بر اساس یک مدل طاقچه اکولوژیکی، محصور شده در یک WPS، برای پیش‌بینی محدوده جغرافیایی یک گونه از سوابق وقوع. و سناریویی برای ارزیابی واکنش کاربری زمین به تغییرات اقلیمی و اقتصادی، به عنوان خروجی توسط یک مدل کاربری اراضی زنجیره‌ای به مدل‌های آماری دیگر. ثابت کرده است که می‌تواند گردش‌های کاری فوق را با موفقیت اجرا کند، که از نمودارهای BPMN بصری طراحی شده توسط کاربران غیر فنی شروع می‌شود. Process Broker به طور موثری کاربران را از بیشتر جنبه های فنی طراحی گردش کار جدا کرده است (که در واقع معادل برنامه نویسی است) و کار ساده تری را برای مدل سازی فرآیندهای مکانی از نظر نمودارهای انتزاعی و سطح بالا به آنها واگذار کرده است و از این رو به آنها اجازه می دهد تا بهتر بر روی کاربرد مورد علاقه خود تمرکز کنید.
اخیراً، Process Broker در یک سناریوی مدل‌سازی برای پیش‌بینی مناسب بودن زیستگاه‌های ساحلی برای تکثیر علف‌های دریایی، در چارچوب پروژه FP7 MEDINA و فاز 6 پیاده‌سازی معماری GEOSS (AIP-6)، که در نشست عمومی GEO-X. این نسخه نمایشی با هدف نمایش مدل توزیع Posidonia Oceanica (نگاه کنید به شکل 3 )، ابزاری برای مدیریت پایدار مراتع چمن دریایی در امتداد خط ساحلی مدیترانه، ادغام مدل های توزیع گونه ها با منابع GEOSS موجود [ 33 ] بود.
در حال حاضر، ما در حال ارزیابی Process Broker در یک سناریوی موزاییک تصویر، در چارچوب پروژه FP7 IASON هستیم. هدف اصلی این سناریو، کاشی کردن مجموعه ای از تصاویر ورودی و نمایش خروجی نهایی در فرمت KML است. این سناریو با زنجیره‌سازی سه نمونه WPS، خدمات بازیابی داده، MosaicN و Data Publisher اجرا می‌شود و عملیات زیر را انجام می‌دهد:

  • سرویس بازیابی داده : URLهای تصاویر GeoTIFF ورودی را از یک فایل XML تجزیه می کند، آنها را دانلود می کند و URL را به پوشه قابل دسترسی وب حاوی تصاویر برمی گرداند.
  • سرویس MosaicN : یک موزاییک لیستی از تصاویر GeoTIFF را در یک تصویر واحد ایجاد می کند که منطقه مورد علاقه را پوشش می دهد.
  • سرویس Data Publisher : نتیجه داده را در یک نمونه GeoServer، در سه قالب مختلف: GeoTIFF، PNG و KML آپلود می‌کند.
شکل 3. رابط وب مدل توزیع پوزیدونیا. Process Broker بر اساس لایه های ورودی ارائه شده در کنترل پنل (در سمت چپ) خروجی را تولید کرد.
شکل 4. نمودار BPMN برای سناریوی موزاییک.
شکل 4 نمودار BPMN را برای سناریو با توجه به مشخصات BPMN و قراردادهای Process Broker نشان می دهد. هر جزء BPMN (بلوک سبز در نمودار) یک مدل یا یک سرویس را نشان می دهد. ورودی ها و خروجی ها به صورت گرافیکی با عناصر BPMN Data Object (آیکون های سند سفید) نشان داده می شوند. شکل 5 و شکل 6 خروجی این گردش کار را به ترتیب در قالب Keyhole Markup Language (KML) و Portable Network Graphics (PNG) کدگذاری شده است.
شکل 5. خروجی سناریوی موزاییک سازی در قالب KML.
شکل 6. خروجی سناریوی موزاییک سازی در فرمت PNG.

6. نتیجه گیری و کار آینده

ما رویکرد واسطه‌گری را برای ترکیب سرویس اعمال کرده‌ایم، و از قابلیت‌های چارچوب خدمات GEOSS برای فعال کردن پیاده‌سازی سطح بالا و کاربرپسند جریان‌های کاری مدل‌سازی مکانی، بر اساس دیدگاه وب مدل، استفاده کرده‌ایم.
در واقع، واگذاری ترکیب به یک میان‌افزار واسطه‌ای، از جنبه‌های فنی تعاریف گردش کار (شناسایی سرویس‌های خارجی، مسائل الزام‌آور، تطبیق نوع، و غیره ) کم می‌کند و به کاربر، احتمالاً یک دانشمند یا تصمیم‌گیر، اجازه می‌دهد تا روی فرآیند تمرکز کند. مورد علاقه در سطح انتزاعی، بدون نیاز به نصب و مدیریت یک زیرساخت ترکیب محلی. در یک سناریوی پیشرفته، کاربر حتی ممکن است یک گردش کار ناقص را ارسال کند و از توصیه‌های کارگزار (که ممکن است از پایگاه دانش جمع‌آوری بازخورد کاربر ناشی می‌شود) برای تکمیل آن استفاده کند. این موضوع در زمینه‌های علمی چند رشته‌ای، جایی که جوامع مختلف ممکن است از طریق ترکیب مدل از دانش یکدیگر بهره ببرند، از اهمیت خاصی برخوردار است.
یکی دیگر از موارد جدید راه حل پیشنهادی این است که Process Broker به یک پلتفرم گردش کار منفرد، که معمولاً برای یک مدل در حال اجرا خاص تنظیم شده است، یا به یک جامعه خاص از تمرین محدود نمی شود. در واقع موتور گردش کار فقط یک جزء داخلی و قابل اتصال از Process Broker است که وظیفه تفسیر و اجرای EBP ها را بر عهده دارد.
در آینده، ما قصد داریم به پر کردن کتابخانه اجزای Process Broker و همچنین بهبود قابلیت‌های آن برای استخراج دانش از تعامل کاربران، ارائه توصیه‌ها در مرحله طراحی و اجرا و جمع‌آوری بازخورد استفاده ادامه دهیم. ما همچنین قصد داریم یک ویرایشگر وب تخصصی ایجاد کنیم که کتابخانه اجزای Process Broker را یکپارچه کند تا به کاربر در مرحله طراحی کمک کند و از موتورهای گردش کار اضافی پشتیبانی کند.

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

  1. ناتیوی، س. مازتی، پی. گلر، جی. دسترسی و قابلیت همکاری مدل محیطی: طرح وب مدل GEO. محیط زیست مدل. نرم افزار 2013 ، 39 ، 214-228. [ Google Scholar ] [ CrossRef ]
  2. علامه، ن. زنجیره خدمات وب اطلاعات جغرافیایی. محاسبات اینترنتی IEEE. 2003 . [ Google Scholar ] [ CrossRef ]
  3. GEO 2009-2011 Work Plan، Sub-Task AR-09-02d، Model Task Sheet توسعه وب. 2009. در دسترس آنلاین: http://www.earthobservations.org/documents/tasksheets/latest/AR-09-02d.pdf (در 23 ژوئن 2014 قابل دسترسی است).
  4. گرانل، سی. گولد، ام. Esbrí, M. زنجیره خدمات وب جغرافیایی. در کتابچه راهنمای تحقیقات ژئوانفورماتیک ; کریمی، ح.، ویرایش. هرشی: نیویورک، نیویورک، ایالات متحده آمریکا، 2008; ص 189-195. [ Google Scholar ]
  5. روزنبرگ، اف. لایتنر، پی. میچل مایر، ع. چلیکوویچ، پی. Dustdar، S. به سوی ترکیب به عنوان یک سرویس – رویکرد مبتنی بر کیفیت خدمات. در مجموعه مقالات بیست و پنجمین کنفرانس بین المللی مهندسی داده (ICDE)، شانگهای، چین، 29 مارس تا 2 آوریل 2009. IEEE CS Press: Los Alamitos، CA، USA، 2009; صفحات 1733-1740. [ Google Scholar ]
  6. ناتیوی، س. کراگلیا، ام. پرلمن، جی. رویکرد کارگزاری برای قابلیت همکاری چند رشته ای: مقاله موضع. بین المللی جی. اسپات. زیرساخت داده Res. 2012 ، 7 ، 1-15. [ Google Scholar ]
  7. ناتیوی، س. کراگلیا، ام. پرلمن، جی. قابلیت همکاری زیرساخت های علم زمین: رویکرد واسطه گری. جی سل. موضوعات کاربردی زمین Obs. Remote Sens. 2013 , 6 , 1118–1129. [ Google Scholar ] [ CrossRef ]
  8. ناتیوی، س. Bigagli، L. کشف، میانجیگری، و دسترسی به خدمات برای داده های رصد زمین. IEEE J. Sel. موضوعات کاربردی زمین Obs. Remote Sens. 2009 , 2 , 233-240. [ Google Scholar ] [ CrossRef ]
  9. بیگاگلی، ال. ناتیوی، س. مازتی، پ. Villoresi, G. GI-Cat: یک سرویس وب برای فهرست نویسی مجموعه داده ها بر اساس ISO 19115. در مجموعه مقالات پانزدهمین کارگاه بین المللی در مورد پایگاه داده و برنامه های کاربردی سیستم های خبره، ساراگوسا، اسپانیا، 30 اوت تا 3 سپتامبر 2004.
  10. ناتیوی، س. بیگاگلی، ال. مازتی، پ. بولدرینی، ای. Papeschi, F. GI-cat: یک راه حل میانجی برای ایجاد یک سرویس کاتالوگ خانه تهاتر. در مجموعه مقالات کنفرانس بین المللی سیستم های اطلاعات جغرافیایی پیشرفته و خدمات وب، GEOWS ’09، کانکون، مکزیک، 1-7 فوریه 2009.
  11. سانتورو، ام. مازتی، پی. ناتیوی، س. فوگازا، سی. گرانل، سی. دیاز، ال. روش‌شناسی برای کشف افزوده شده منابع جغرافیایی. در کشف منابع جغرافیایی: روش‌ها، فناوری‌ها و کاربردهای اضطراری ؛ Diaz, L., Granell, C., Huerta, J., Eds. IGI Global: Hershey, PA, USA, 2012; صص 172-203. [ Google Scholar ]
  12. بولدرینی، ای. سانتورو، ام. پاپسچی، ف. Nativi، S. قابلیت همکاری خدمات دسترسی به داده در علوم زمین با استفاده از چارچوب کارگزاری GI-Axe. در مجموعه مقالات مجمع عمومی EGU، خلاصه کنفرانس مجمع عمومی EGU، وین، اتریش، 7-12 آوریل 2013.
  13. ناتیوی، س. کارون، جی. دومنیکو، بی. بیگاگلی، نگاشت مدل داده رایج L. Unidata به مدل داده ای ISO 19123. علوم زمین Inf. 2008 ، 1 ، 59-78. [ Google Scholar ] [ CrossRef ]
  14. واکاری، ال. کراگلیا، ام. فوگازا، سی. ناتیوی، س. سانتورو، ام. تحقیق یکپارچه: تجربه EuroGEOSS. IEEE J. Sel. موضوعات کاربردی زمین Obs. Remote Sens. 2012 ، 5 ، 1603-1611. [ Google Scholar ] [ CrossRef ]
  15. ناتیوی، س. کراگلیا، ام. واکاری، ال. سانتورو، ام. جستجوی جام جدید: قابلیت همکاری بین رشته ای. در مجموعه مقالات چهاردهمین کنفرانس بین المللی AGILE در علم اطلاعات جغرافیایی، اوترخت، هلند، 18-21 آوریل 2011.
  16. مونوز، MES؛ جیووانی، آر. Siqueira، MF; ساتن، تی. برویر، پی. پریرا، آر اس؛ Canhos، DAL; Canhos، معاون OpenModeller: یک رویکرد عمومی برای مدل‌سازی توزیع بالقوه گونه‌ها. GeoInformatica 2011 ، 15 ، 111-135. [ Google Scholar ] [ CrossRef ]
  17. پروژه کپلر در دسترس آنلاین: https://kepler-project.org/ (دسترسی در 15 دسامبر 2014).
  18. Taverna—منبع باز و سیستم مدیریت گردش کار مستقل از دامنه. در دسترس آنلاین: http://www.taverna.org.uk/ (دسترسی در 15 دسامبر 2014).
  19. دوبوا، جی. اسکوین، جی. مندس دی ژسوس، جی. پیدل، اس. هارتلی، ا. ناتیوی، س. سانتورو، ام. Geller, G. eHabitat: مشارکتی در وب مدل برای ارزیابی زیستگاه و پیش‌بینی اکولوژیکی. در مجموعه مقالات سی و چهارمین سمپوزیوم بین المللی سنجش از دور محیط زیست، سیدنی، استرالیا، 10-15 آوریل 2011.
  20. دوستدار، س. Schreiner, W. نظرسنجی در مورد ترکیب خدمات وب. بین المللی J. Web Grid Serv. 2005 ، 1 ، 1-30. [ Google Scholar ] [ CrossRef ]
  21. سریواستاوا، بی. Koehler, J. ترکیب سرویس وب – راه حل های فعلی و مشکلات باز. در مجموعه مقالات کارگاه ICAPS در مورد برنامه ریزی برای خدمات وب، ترنتو، ایتالیا، 10 ژوئن 2003; AAAI Press: Palo Alto، CA، USA، 2003; ص 28-35. [ Google Scholar ]
  22. Schut, P. (Ed.) OpenGIS® Web Processing Service ; OGC 05-007r7; Open Geospatial Consortium Inc.: Wayland، MA، ایالات متحده آمریکا، 2007.
  23. اکرم، ع. مردیث، دی. آلن، R. ارزیابی BPEL به گردش کار علمی. در مجموعه مقالات CCGRID’06، سنگاپور، سنگاپور، 16-19 مه 2006.
  24. White, S. استفاده از BPMN برای مدلسازی فرآیند BPEL. BPTrends 2005 ، 3 ، 1-18. [ Google Scholar ]
  25. برایان بلیک، ام. تان، دبلیو. روزنبرگ، اف. ترکیب به عنوان یک سرویس. محاسبات اینترنتی IEEE. 2010 ، 14 ، 78-82. [ Google Scholar ] [ CrossRef ]
  26. مل، پی. گرنس، تی. تعریف NIST از رایانش ابری. توصیه های موسسه ملی استاندارد و فناوری. نشر ویژه 800-145; سپتامبر 2011. در دسترس آنلاین: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf (در 15 دسامبر 2014 قابل دسترسی است). [ Google Scholar ]
  27. بیگاگلی، ال. آنجلینی، وی. سانتورو، ام. مازتی، پی. Nativi، S. چارچوب های خدماتی برای مدل سازی منابع. تحویلی 2.2، FP7 UncertWeb. 2011. در دسترس آنلاین: http://www.uncertweb.org/documents/deliverables/service-frameworks-for-modelling-resources/download (در 16 آوریل 2015 قابل دسترسی است).
  28. ISO ISO/IS 19115:2003(E)—اطلاعات جغرافیایی—متادیتا . ISO/TC 211: ژنو، سوئیس، 2003. [ Google Scholar ]
  29. ISO ISO/IS 19119:2003 — اطلاعات جغرافیایی — خدمات ; ISO/TC 211: ژنو، سوئیس، 2003. [ Google Scholar ]
  30. سانتورو، ام. بولدرینی، ای. پاپسچی، ف. بالدینی، ع. Nativi, S. مشخصات ظرفیت عملیاتی اولیه EUROGEOSS. قابل تحویل 2.2.2، FP7 EuroGEOSS. 2010. در دسترس آنلاین: http://www.eurogeoss.eu/Documents/EuroGEOSS_D_2_2_2.pdf (در تاریخ 16 آوریل 2015 قابل دسترسی است).
  31. بیگاگلی، ال. رونسلا، آر. بولدرینی، ای. سانتورو، ام. پاپسچی، ف. ویلیامز، ام. جونز، آر. باستین، ال. کورنفورد، دی. استاش، سی. و همکاران پیاده سازی مرجع چارچوب UncertWeb. تحویلی 2.3، FP7 UncertWeb. 2012. در دسترس آنلاین: http://www.uncertweb.org/documents/deliverables/reference-implementation-of-uncertweb-framework/download (در 16 آوریل 2015 قابل دسترسی است).
  32. سانتورو، ام. ترکیب مدل محیطی در وب مدل GEO. پایان نامه دکتری، Dipartimento di Ingegneria e Fisica dell’Ambiente، Facoltà di Ingegneria، Università della Basilicata، Potenza، ایتالیا، مارس 2013. [ Google Scholar ]
  33. سانتورو، ام. پاستر، ر. زوکتا، م. ونیر، سی. رونسلا، آر. بیگاگلی، ال. منگین، ع. امین تاجی، م. مالوارز، جی. Nativi، S. مدیریت پایدار مراتع علف دریایی: GEOSS AIP-6 Pilot. در مجموعه مقالات مجمع عمومی EGU، خلاصه کنفرانس مجمع عمومی EGU، وین، اتریش، 27 آوریل تا 2 مه 2014.

بدون نظر

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

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