یکپارچه سازی فن آوریهای سرویس دهنده کاربرد شبکه و سرویس دهنده پایگاه داده چندگانه افزایش محبوبیت تجارت الکترونیکی بسیاری از شرکت ها را به رجعت به سرویس دهنده های کاربردی برای بکارگیری و مدیریت برنامه های کاربردی شبکه شان بطور مؤثر، متوجه نموده است.
این سرویس دهنده های کاربردی برای ارتباط با یک سیستم مدیریت پایگاه داده (DBMS) برای ذخیره و بازیابی اطلاعات ترکیب بندی می کنند.
این امر اغلب به این معنی است که برنامه های کاربردی شبکه باید با محیط های «قانونی» کار نماید.
در نتیجه، توسعه دهندگان برنامه های کاربردی شبکه متوجه شده اند که کنترلی بر محصول DBMS مورد استفاده برای پشتیبانی برنامه های کاربردی شان ندارند یا نمی توانند پایگاه مورد طراحی را کنترل نمایند.
در بعضی موارد، توسعه دهندگان ممکن است متوجه شوند که اطلاعات بحرانی برای برنامه کاربردی آنها در DBMS های چندگانه توسعه یافته توسط فروشندگان نرم افزار متفاوت منتشر می شود.
مشکلاتی که توسعه دهندگان برنامه کاربردی تجارت الکترونیکی با آن مواجه هستند:
چنین وضعیتی می تواند کشمکش های متعددی تولید کند، یک معماری نرم افزار را در نظر بگیرید که استفاده از (EJBS) جاوا را احضار می کند، که یک مؤلفه فن آوری است که علاقه بسیاری را از طرف جامعه تجارت الکترونیکی بدست آورده است.
یعنی وقتی اطلاعات همراه با موضوعات جاوا باید در ماورای مرزهای یک جلسه کاربردی موجود باشند.
EJB های موجودیت در اکثر مواقع از یک DBMS منطقی برای چنین مقاصد ذخیره سازی استفاده می کنند.
توسعه دهندگان EJB می توانند یکی از دو نوع EJB موجودیت را تولید نمایند: آنهایی که دارای توجه مدیریت شده هستند یا آنهایی که دارای تاکید بر مدیریت می باشند.
مدیریت اغلب توسعه دهنده را از نوشته کد (رمز) دسترسی اطلاعات خام (داده) رها می نماید، در عوض سیستم ای که ظرف EJB را راه اندازی می کند بطور خودکار SQL مناسب رادر صورت نیاز تولید واجرا
می نماید.
برعکس، مواد و دانه های موجودیت مستلزم بر آن است که توسعه دهنده که روال های دسترسی اطلاعات خام خودش را کدبندی و حفظ نماید.
این امر اجازه انعطاف پذیری بیشتری را می دهد، اما مستلزم مهارت های برنامه ریزی اضافی است (مثل دانش درباره فن آوری DBMS) و نیازهای کار برای توسعه دانه و آزمایش راافزایش می دهد و از قابلیت حمل خود bear دانه جلوگیری می نماید.
متاسفانه، شرکت هایی که قصد دارند از EJB های با موجودیت مدیریت شده ظرف (از این پس موسوم به دانه های موجودیت CMP) برای برنامه های کاربردی تجارت الکترونیکی خودشان استفاده کنند ممکن است با بعضی از موانع مواجه شوند.
سرویس دهنده برنامه کاربردی شبکه شرکت انتخاب شده ممکن است DBMS های شرکت مورد انتخاب را نتواند بکار ببرد.
بعلاوه، اگر مقررات طراحی یک دانه موجودیت CMP را فرا بخواند که ویژگی های آن باید DBMS های «قانونی» چندگانه را در بر بگیرد، این امر یقیناً پشتیبانی نخواهد شد.
درحالیکه کار بر روی هر کدام از این مشکلات امکان پذیر است، آنها می توانند دردسرهای اضافی را موجب شوند و از سرویس دهنده برنامه کاربردی شبکه تا تلاش برای انتقال اطلاعات (پرهزینه) یا بکارگیری یک فرآیند رونویسی اطلاعات را شامل گردند که تاخیر اطلاعات فیلمی کم را پشتیبانی می کند.
بازنگری یک راه حل بالقوه:
با این حال، راه دیگری موجود است که می تواند چنین کارهای غیرضروری را در بسیاری موارد ارائه کند.
این راه شامل بکارگیری فن آوری سرویس دهنده برنامه کاربردی شبکه با فن آوری سرویس دهنده پایگاه داده چندگانه است.
این گزارش یک پروژه را شرح می دهد که در آزمایشگاه مانتاترنرا IBM امکان چنین معماری ای را بررسی کرد ونتایج خوبی داشت.
پروژه یک سرویس دهنده برنامه کاربردی شبکه را با یک سرویس دهنده پایگاه داده چندگانه (در این حالت تألیف پیشرفته websphere 31º) از (IBM برای پشتیبانی صف آرایی دانه های موجودیت CMP یکپارچه می کند که به منابع داده چندگانه دسترسی دارد.
Deployment این منابع اطلاعات شامل اطلاعات مدیریت شده موضعی و همچنین اطلاعات ذخیره شده از راه دور در Sybase, oracle, Informi بود.
برای ساده سازی موضوعات توسعه و آزمایش یک محیط توسعه یکپارچه شده جاوا در این حالت، Visual Age برای تالیف اداری (Java 3.0) بکار رفت که همراه با سرویس دهنده پایگاه داده چندگانه است.
ترکیب این فن آوری ها احتمالات زیر را موجود می آورد: توسعه و صف آرایی دانه های موجودیت CMP که هر کدام از آنها به یکی از منابع اطلاعات زیردسترسی داشتند: اوراکل، یابسیس و اینفورمیکس.
چنین دانه هایی بدون نصب نرم افزار مشتری DBM از اوراکل سیابیس یا اینفورمیکس بر روی ایستگاه کاری در حال اجرای Visual Age برای جاوا و Websphere توسعه یافتند.
توسعه و صف آرایی خودکار یک دانه موجودیت CMP که ویژگی های آن برای یک دیدگاه واحد نگاشته شده است جداول اینفورمیکس، سای بیس و اوراکل را شامل می شود.
بدلیل مشکل «نگاه روزآمد» که برای هر DBM معقولی متداول است، چنین دانه های موجودیت CMP ای فقط برای خواندن readonly توسعه یافتند.
پخش توسعه و صف آرایی یک دانه موجودیت CMP واحد که ویژگی های آن مستقیماً برای دو جدول نگاشته شده است ، که یکی بطور موضعی توسط یک سیستم DB2 DataJoiner و دیگری از راه دور توسط یک سیستم ایتفورمیکس مدیریت می گردد.
این دانه کاملاً فعالیت های خواندن نوشته را پشتیبانی کرد و Data Joiner بطور خودکار فرایند انجام دو مرحله ای را مدیریت می نماید تا یکپارچگی تراکنش اساسی را تضمین نماید هنگامی که یک روش دانه باعث گردید که فعالیت های نوشته پایگاه داده رخ دهد.
توسعه و صف آرایی خودکار یک سلسله مراتب از دانه های موجودیت CMP که ویژگیهای آن برای یک جدول واحد نگاشته شد توسط هر کدام از منابع اطلاعات زیر مدیریت گردید: Sybase, Oracle, DB2 Data Joiner یا Informix.
توجه نمایید که تعداد این توانایی ها امروزه بدون کارها ومقررات ارجاع شده در بخش قبلی، موجود نمی باشند.
(مشکلات جاری که توسعه دهندگان برنامه کاربردی تجارت الکترونیکی با آن مواجه هستند را ملاحظه کنید).
بویژه با ترکیب کردن websphere , DB2 Data Joiner توسعه دهندگان EJB به یک سری از منابع اطلاعات دسترسی می یابند.بعلاوه، منافع تصور شده توسط ترکیب یک سرویس دهنده برنامه کاربردی شبکه با یک سرویس دهنده پایگاه داده چندگانه میتواند برای سایر گزینه های طراحی برنامه کاربردی Java انتظار برود که شامل سایر شکل های EJB، صفحات سرویس دهنده جاوا (JSP) اوسرولت های جاوا می باشد.
برنامه نویسانی که این فن آوری ها را بکار می برند فراخوانی های ارتباط پایگاه داده جاوا (JDBC) را می نویسند تا تراکنش های پایگاه داده را کنترل نمایند.
یک سرویس دهنده پایگاه داده چندگانه می تواند کار توسعه را زمانی ساده نماید که برنامه نویسی ها به دسترسی به اطلاعات ذخیره شده در DBMS های چندگانه نیاز دارند.
این کار توسط ارائه یک SQL APT، شفافیت موضعی ودر بعضی موارد جبران عملیاتی انجام می گیرد.
بعلاوه، پیوندهای پایگاه داده چندگانه و اتحادیه ها می تواند بدون ارتباط دستی با هر منبع اطلاعات اجرا شود و اطلاعات ضروری بطور انفرادی از هر منبع بازیابی گردد و این اطلاعات در بعضی ساختارهای اطلاعات مدیریت شده کاربردی موقتاً ذخیره گردد و منطق ضروری برای ادراه یکپارچگی اطلاعات همراه با یک پیوند یا عملیات واحد کدگذاری گردد.
چنین کاری بطور خودکار توسط سرویس دهنده پایگاه داده چندگانه اداره می شود که یک تصور تک مکانیSingle site از DBMS های توزیع شده فیزیکی و غیرقابل مقایسه را ارائه می نماید.
البته، مانند هر معماری نرم افزار دیگری، معماری شرح داده شده دراین گزارش دارای مزایا ومعایب خودش است.
مزایای اصلی قبلاً در صفحات قبلی خلاصه شده اند.
شاید عیب اصلی این معماری پیچیدگی اجرایی DBMS اضافی باشد.
بویژه استفاده از یک سرویس دهنده پایگاه داده چندگانه نیاز برای یک محیط پایگاه داده توزیع شده را ایجاب می کند تا ترکیب بندی و نگهداری شود یعنی یک تلاش ای که به بهترین وجه با پرسنل ماهر در طراحی پایگاه داده، مدیریت پایگاه داده و مدیریت شبکه انجام می گیرد.
بااین حال برای سازمان هایی که بطور معمول از DBMS های چندگانه برای ذخیره کردن اطلاعات بحرانی استفاده می کنند، چنین مهارت هایی احتمال دارند که به هر حال موجود باشند.
باقیمانده این گزارش پروژه را به تفصیل فنی بیشتر شرح می دهد و محیط نرم افزار را ذکر نموده و مراحل لازم برای توسعه و صف آرایی موجودیت CMP بحث شده قبلی را شرح می دهد.
با این حال، قبل از ورود به این جزئیات ، این گزارش یک بازنگری از فن آوری های اصلی را برای خوانندگان ناآشنا با سرویس دهنده های پایگاه داده چندگانه، سرویس دهنده های برنامه کاربردی شبکه و EJB ارائه می کند.
مقدمه ای بر فن آوری های کلیدی (اصلی): درک سرویس دهنده های پایگاه واحده چندگانه به سرویس دهنده های برنامه کاربردی شبکه، و EJB ها برای درک بخش های بعدی در این گزارش بحرانی است.
بخش های زیر یک بازنگری جزئی از چنین موضوعاتی را فراهم می کند به اطلاعات دقیق تر می توانند با مراجعه به مراجع فهرست شده در کتاب شناسی بدست می آید.
خوانندگان قبلاً آشنا با این فن آوریها تشویق می شوند تا این بخش را نادیده گرفته و خواندن درباره «معماری نرم افزار» بکاررفته توسط این پروژه را آغاز کنند.
سرویس دهندگان پایگاه داده چندگانه یک سرویس دهنده پایگاه داده چندگانه مثل Data Joiner DB2 از IBM یک رابط برنامه ریزی برنامه کاربردی واحد (API) برای منابع اطلاعات چندگانه را فراهم می کند.
این منابع اطلاعات ممکن است بر روی سکوهای سیستم عملیاتی و سخت افزار متفاوت اجرا گردد و ممکن است توسط فروشندگان متفاوت توسعه یابند و ممکن اس از API های متفاوت «بومی» استفاده کنند (شامل دیالکیت های SQL متفاوت).
برنامه نوبس ها از سرویس د هنده پایگاه داده چندگانه برای کار در سطح بالاتر انتزاع نسبت به سایر موارد احتمالی استفاده می کنند هنگامی که سرویس دهنده یک تصویر تک مکانی از اطلاعات غیراقبل قیاس فیزیکی را ارائه می کند استفاده از نام مستعار برای جداول به برنامه نویس ها شفافیت موضعی را پیشنهاد می کنند، و نیاز برای دانستن عمل اطلاعات مطلوب را بطور دقیق حذف می کند.
جبران عملیاتی می تواند تفاوت های بین فروشندگان مختلف DBMS را بپوشاند و توانایی هایی را شبیه سازی می کنند که توسط یک DBMS مفروض به طور بومی پشتیبانی نمی شوند.
پیوندهای چندمکانی unions و یکپارچگی اطلاعات از منابع چندگانه را موجب می شوند و پردازش دو مرحله ای میتواند یکپارچگی تراکنش را تضمین کند هنگامی که عملیات DBMS های چندگانه را شامل می شود.
یک معماری سرویس دهنده‌پایگاه داده چندگانه نمونه در شکل زیر نشان داده می شود.
دراین سناریو، برنامه نویس های جاوا می توانند برنامه های کاربردی بر پایه جاوا را بنویسند که با سرویس دهنده ارتباط یابند.
این سرویس دهنده ، به نوبه خود، با منابع اطلاعات پشتیبانی شده توسط فروشندگان مختلف بر روی سکوهای مختلف پشتیبانی می گردد.
در نتیجه، برنامه های کاربردی JDBC میتواند به هر کدام یا تمام این منابع اطلاعات بدون نیاز به یادگیری API بومی از هر منبع اطلاعات توسط برنامه نویس کاربردی بدست آید.
بعلاوه، نمایش ها می توانند برای دربرگرفتن اطلاعات از منابع چندگانه برای ساده کردن موضوعات یکپارچه سازی اطلاعات برای برنامه های کاربردی فقطظ خواندنی ایجاد گردد.
پشتیبانی منبع اطلاعات و عمل تولید میتواند از پیشنهادی به پیشنهادی دیگر فرق کند.
DB2 Data Joinert V2.1 ، برای مثال، تمام اعضای خانواده IBM DB2 ، سرویس دهنده SQL میکروسافت، اوراکل، RDB اوراکل، سای بیس، سای بیس انی ور، اینفورمیکس آن لاین، و سایر موارد را پشتیبانی می کند.
بعلاوه، بدلیل اینکه DB2 Data Joiner یک نسخه گسترده از محصول DB2 پایه است، قادر به ذخیره کردن و مدیریت نمودن اهداف اطلاعات موضعی اش از قبیل جداول، نمایش ها ، و نمایه ها یا شاخص ها indexes می باشد.
بهینه سازی آن برای در نظر گرفتن طبیعت توزیع یافته فیزیکی و غیر قابل قیاس محیط آن طراحی می شود طوری که یک استراتژی دسترسی اطلاعات موثر بتواند برای هر پرس و جو quaryانتخاب گردد.
سرویس دهنده های کاربرد شبکه: سرویس دهنده های کاربرد شبکه به شرکت ها کمک می کنند که منطق تجارت طرف سرویس دهنده را مدیریت وصف آرایی کنند.
این منطق ، نوعاً به زبان جاوا نوشته می شود و اغلب برای پشتیبانی برنامه های کاربردی تجارت الکترونیکی چند –ردیفی امری حیاتی است.
منطق می تواند از طریق یک سری از فن آوری های طرف سرویس دهنده بیان شود، شامل صفحات سرویس دهنده جاوا (JSP)، سرویس های جاوا، و EJB ها.
با طرح ریزی برای اجرای منطق تجارت مناسب بر روی سرویس دهنده، شرکت ها می توانند به کار برد مجدد کد کمک کنند وایمنی بیشتری بر روی منابع تجاری بحرانی بدست آورند، و سرویس دهنده های قدرتمندی را برای کار محاسباتی شدید استفاده کنند و ابزارها را برای کمک به متعادل کردن بار کاری، تنظیم عملکرد و تشخیص مشکل بکار گیرند.
شکل زیر یک نمونه معماری سرویس دهنده برنامه کاربردی شبکه را نشان می دهد.
دراین سناریو، مشتریانی که یک سری از سکوها را اجرا می کنند ممکن است به یک سیستم سرویس دهنده برنامه کاربردی به اشتراک گذارده شده دسترسی می یابند بر روی این سکو یک سرویس دهنده شبکه HTTP (مثل Apache یا HTTP) و یک سرویس دهنده برنامه کاربردی شبکه (مثل Web sphere) نصب شده است.
سرویس دهنده برنامه کاربردی شبکه انواع فن آوری بر پایه جاوا را پشتیبانی می کند، از قبیل EJB ، که اعمال مناسب را در پشتیبانی برنامه های کاربردی مشتری انجام می دهد.
در بین این اعمال ممکن است دسترسی به منابع اطلاعات از راه دور یا محلی از یک سری از فروشندگان را نام برد.
ترکیب بندی دسترسی منبع اطلاعات محلی به یک DBMS را نشان می دهد.
همانطور که خواننده ممکن است انتظار داشته باشد توانایی های سرویس دهنده های برنامه کاربردی شبکه از محصولی به محصول دیگر تغییر می کند.
تألیف پیشرفته سرویس دهنده برنامه کاربردی Web Sphere در این پروژه استفاده گردید.
و سرویس ها، XML, EJB, JSP دسترسی به DB2 یا Oracle DBMS ،امکانات مثبت گردش کار logging و جستجو کردن نکاربرد سایت محل، و یک سری از کارهای دیگر را پشتیبانی می کند.
EJB ها: EJB ها مؤلفه های نرم افزار طرف سرویس دهنده هستند که بامشخصات توسعه یافته توسط میکروسیستم های سان مطابقت دارد.
این مشخصات یک مجموعه حداقل از رفتارها را برای EJB ذکر می کنند و منطق تجارت را در یک شیوه ای محصور می نماید که توسعه برنامه کاربردی را ساده می کند و به افزایش احتمالات کمک می نماید.
EJB ها ممکن است مستقیماً از برنامه های کاربردی Java طرف مشتری با استفاده از پروتکل ها Rmi/Hop بطور مستقیم یا بطور غیرمستقیم از مشتریان Web دسترسی یابد که با یک سرویس دهنده وب از طریق HTTP ارتباط برقرار می کنند و یک سرولت یا JSP را فرا می خوانند که به نوبه خودش به EJB دسترسی می یابند.
شکل زیر هر دو روش را نشان می دهد.
در صف آرایی، EJB در ظرف هایی باقی می مانند که یک سری از سرویس ها را فراهم می کنند، که اکثر آنها در این گزارش بحث خواهدد شد.
با این حال ، ما قبلاً به یک عمل بحرانی اشاره کرده ایم که ممکن است توسط ظروف مدیریت گردد: پشتیبانی برای مخالفت.
انواع معین EJB بویژه دانه های موجودیت مدیریت شده توسط ظرف، یا دانه های CMP متکی بر ظرف EJB برای اجرا و مدیریت دسترسی به منبع اطلاعات هدف می باشد .
این امر توسعه دهندگان EJB را از نوشتن روال های دسترسی اطلاعات رها می کند و می تواند احتمال DBMS دانه های آنها را کمک نماید.
Websphere مجریان را قادر می سازد تا ظرف های چندگانه را ایجاد کنند، که هر کدام از آنها ممکن است میزبان یک یا چند EJB باشد.
هر ظرف ممکن است با یک سرویس دهنده EJB ارتباط یابد و Websphere مجریان را قادر می سازد تا چنین سرویس دهندگانی چندگانه ای را ایجاد کند.
با یکدیگر، یک ترکیب سرویس دهنده EJB / ظرف چنین خدمات مفیدی را ایجاد می کنند از قبیل ایمنی، مدیریت بارکاری، تولید کد، و مقاومت.
همانطور که قبلاً ذکر گردید، مشخصات EJB انواع EJB را شرح می دهد.
EJB های جلسه کاری دارای طبیعت زودگذر می باشند، در حالیکه EJB های موجودیت پایا ومقاوم هستند.
دانه های جلسه کاری خودشان می تواند بی هویت یا با هویت باشند و توسعه دهندگان چنین دانه هایی می توانند JDBS را برای دسترسی خواندن/ نوشتن برای DBMS های پشتیبانی شده بکار گیرند.
در واقع، بسیاری از دانه های جلسه کاری برای اجرای بعضی عملیات پایگاه داده یا کار تراکنشی نوشته می شوند.
با این حال، اگر هر اطلاعات ای همراه با یک دانه جلسه کاری باشد فرض می شود که زودگذر باشد به ظرف هیچ پشتیبانی خودکاری را برای مقاومت persistenve فراهم نمی کند.
EJB های موجودیت، برعکس، فرض می شوند که دارای اطلاعاتی باشند که بادوام و پایدار هستند.
توسعه دهندگان می توانند این پایداری را خودشان مدیریت نمایند از طریق پایداری مدیریت شده با دانه bean ) یا‌آنها این مسئولیت را به ظرف واگذار می نمایند (از طریق پایداری مدیریت شده توسط ظرف).
انواع متفاوت EJB نیازهای کدبندی متفاوت را برای توسعه دهندگان EJB مطرح می نماید وایجاب می کند که خدمات حداقل برای مشتریان ای موجودباشند که تا حدی تفاوت دارند .
دانه های موجودیت CMP کانون این گزارش خواهد بود.
هر دانه از این نوع حاوی مؤلفه های گوناگون است که شامل این موارد است: رابط خانگی که روش های مشتری برای ایجاد، یافته و برطرف کردن نمونه های دانه instanced of the bean را تعریف می کند.
رابط از راه دور که روش های تجارت همراه با دانه را تعریف می کند گیرنده ها Getter ها و تنظیم کننده ها Setter معمولاً برای گرفتن / تنظیم ویژگی های دانه استفاده می شوند کلاس دانه، که حاوی روشه ای منطقی تجارت کد بندی شده توسط توسعه دهنده EJB و همچنین روشهای چرخه زندگی EJB بکار رفته توسط ظرف است.
مشتریان EJB مستقمیاً به موضوعات object این طبقه class دسترسی دارند، اما درعوض با کلاس هایی تولید شده توسط ظرف کار می کنند که رابط های خانگی (داخلی، و از راه دور را برای استفاده غیرمستقیم از این کلاس بکار می برند) .
کلاس کلید اصلی، که ویژگی ای (یا مجموعه ای از ویژگی هایی) را تعیین می کند که منحصراً هر نمونه (مثال) از این دانه را تعیین هویت می نماید (یا می نماید) و همچنین روشهای ایجاد و استفاده از کلید را فراهم می کند.
با یک محیط توسعه یکپارچه مانند Visual Age برای Java ، بسیاری از کدگذاری های همراه با دانه های موجودیت CMP می توانند حداقل سازی شوند.
پس از توسعه و آزمایش دانه bear، توسعه دهندگان باید توصیف کنندگان صف آرایی deployment descriptors را تنظیم نمایند که خصوصیاتی از قبیل پشتیبانی تراکنش، سطوح جداسازی، و سایر موارد را کنترل می کنند.
بالاخره، دانه باید برای صف آرایی depleyment در یک فایل EJBJAR ) بسته بندی شود و در یک سرویس دهنده EJB صف آرایی گردد.
فرایند صف آرایی باعث می شود که کلاس های اضافی تولید شوند، که شامل موارد مرتبط با رابط های خانگی داخلی، و از راه دور می باشد که قبلاً شرح داده شوند.
مجدداً.
محیط صف آرایی جاوای مناسب (Visual Age) می تواند کمک قابل توجهی برای مراحل آزمایش و صف آرایی باشد.
معماری نرم افزار شامل Data Joiner , Websphere: محیط نرم افزار بکار رفته برای این پروژه شامل محصولات گوناگونی است، که همه آنها عمدتاً موجود می باشند.
فهرست کامل به شرح زیر است: بدلیل منابع ماشین محدود ، تمام نرم افزار فهرست شده قبل از Data Goiner بر روی ایستگاه کاری NT 4.0 نویسنده نصب گردید.
(که دارای 6GB , RAM 256MB دیسک سخت می باشد)، محصولات باقیمانده بر روی سایر ماشین ها نصب شدند، که نوعاً A,X را اجرا می کنند.
جاوا JDK1.17b Visual Age.
برای EnterpriseEdition 3.0 سرویس دهنده برنامه کاربردی Websphere چاپ 3.0 سرویس دهنده IBM HTTP 1.3.6 (بر پایه سرویس دهنده Apache).
DB2 V6.1 با بسته های ثابت جاری DB2 Data Joiner U2.1 .
اوراکل DBMS System DBMS اینفورمیکس DBMS شکل زیر مؤلفه های اصلی این محیط و نحوه تراکنش آنها را نشان می دهد.
توجه کنید که DB2 V6.1 برای مدیریت اطلاعات اجرایی Websphere ترکیب بندی شد و همانطور که بحث خواهیم کرد و برای کار با Data joiner زیر ترکیب بندی گردید که توسعه دهندگان Websphere و Visual Age را قادر می سازد تا به توابع و منابع اطلاعات پشتیبانی شده توسط Data joiner دسترسی بیابند.
ترکیب بندی Data soiner : Data Joiner باید بر اساس دستورالعمل های تعیین شده درکتابچه های راهنمای محصول اش، نصب و ترکی بندی شود.
مراحل اضافی مورد نیاز برای کاربران وجود دارد که بتوانند از فن آوری Data Joiner استفاده کنند ما همه آنها را ذکر می نماییم.
ولی ابتدا، بطور خلاصه، مراحل اصلی ضروری برای ترکیب بندی Data Joiner را بازدید می نماییم، در حالتی که خواننده با این محصول ناآشنا باشد.
نصب صحیح و ترکیب بندی Data Joiner شامل اتصال محصول به هر منبع اطلاعات ضروری می باشد از قبیل اوراکل، لینفورمیکس، سای بیس، سرویس دهنده میکروسافت SQL و غیره.
پیش نیازهای نرم افزار و فرایند ترکیب بندی بستگی به منابع اطلاعات موجود تغییر می نماید، لذا این گزارش مراحل را به تفصیل شرح نخواهد داد.
بطور کلی، فرایند ترکیب بندی Data Joiner استاندارد به شرح زیر است: ایجاد یک پایگاه داده محلی که کاتالوگ آن برای حفظ اطلاعات درباره منابع اطلاعات از راه دوراستفاده می شود .
نصب هر نرم افزار مشتری بر روی سرویس دهنده Data Joiner .
راه اندازی ارتباطات شبکه .
تعیین هویت Data Joiner .
راه اندازی ارتباطات شبکه.
تعیین هویت Data Joiner که بر روی گره آن منبع اطلاعات (داده) هدف قرار می گیرد.
نمایش های کاتالوگ Data Joiner روز آمد برای انعکاس اطلاعات درباره منبع داده data در صورت نیاز.
تایید میکند که ارتباط منبع داده کار می کند.
اگر پشتیبانی دو مرحله ای لازم باشد، مراحل ترکیب بندی اضافی بکار می رود.
مجدداً، این امر از منبع اطلاعات به منبع اطلاعات دیگر فرق می کند، بنابراین به کتابچه های راهنمای محصول برای جزئیات بیشتر مراجعه کنید.
(پردازش دو مرحله ای برای حفظ یکپارچگی یک تراکنش هنگامی ضروری ا ست که تغییرات برای منابع اطلاعات چندگانه در یک واحد کاری مجزا لازم باشد.
در یک مثال بعدی، این گزارش نحوه استفاده از این ویژگی Data Joiner برای پشتیبانی یک دانه موجودیت CMP که ویژگی های آن برای دو جدول ذخیره شده در DBMS های متفاوت نگاشته می شود، شرح داده خواهد شد.
با این حال، هیچکدام از این مراحل اضافی برای کارکردن توسط Visual Age یا Websphere بکار برده نمی شوند.
سیستم Data Joiner بکار رفته برای این پروژه برای دسترسی به اوراکل ، سای بیس و DBMS اینفورمیکس ترکیب بندی شد.
DBMS اینفورمیکس بعداً برای پشتیبانی انجام دو مرحله ای ، ترکیب بندی گردید.
دو جدول ذخیره شده در DBMS های متفاوت نگاشته می شود، شرح داده خواهد شد).
سیستم Data Joiner بکار رفته برای این پروژه برای دسترسی به اوراکل، سای بیس و DBMS اینفورمیکس ترکیب بندی شد.
بعنوان مرحله نهایی برای دسترسی به اطلاعات شفاف، اسامی مستعار را برای جداول از راه دور مورد ارزیابی ایجاد کنید.
مجدداً، این یک فعالیت اجرایی Data Joiner استاندارد می باشد.
فرمان CREATE WickNAME یک object از راه دور را از قبیل یک جدول ذخیره شده در یک پایگاه داده اوراکل به یک نام مستعار درک شده (قابل فهم) برای DataJoiner می نگارد.
سپس، برنامه های کاربردی DataJoiner می توانند نام مستعار را برای دسترسی به اطلاعات در جدول اوراکل مناسب، مرجع قرار دهند و از ارتباط دستی با سیستم اوراکل از طریق دستور SET PASSTHRU) پرممیز نموده و مستقیماً به جدول آن دسترسی یابند.
وقتی که فرایندترکیب بندی ونصب استاندارد کامل می شود که هدر بالا شرح داده شد)، مراحل اضافی برای دسترسی به DataJoiner بعنوان یک سرویس دهنده از نمونه DB2 دیگر، ضروری می باشند.
همانطور که خوانند بخاطر می آورد، این ترکیب بندی پایگاه داده توزیع شده لازم بود تا کاربران Visnal Age, WebSphere از تابع DataJoiner استفاده نمایند، که شامل توانایی برای دسترسی به یک سری از منابع اطلاعات خام (داده) می باشد.
فرایند ترکیب بندی پایگاه داده توزیع شده می تواند تغییر کند که بستگی به نرم افزار ارتباطات موجود دارد، اما روش کلی شامل اصلاح ورودی ها در فایل ترکیب بندی مدیر پایگاه داده از طریق فرمان ترکیب بندی پایگاه داده روز آمد است، چون TCP/IP در محیط نویسنده استفاده گردید، یک نام سرویس مناسب و شماره درگاه مرتبط تعیین شد.
این نام سرویس مرجع قرار می گیرد هنگامی که نمونه DB2 برای پشتیبانی دسترسی پایگاه داده توزیع شده به DataJoiner ترکیب بندی گردد برای جزئیات درباره تغییر ترکیب بندی مدیر پایگاه داده برای پشتیبانی این امر، با کتابخانه DB2 مشورت کنید ترکیب بندی DB2 : DB2 V6-1 باید با بسته های مناسب نصب شود مطابق با فرآیند نصب استاندارد .
با فرض اینکه یک سیستم Data Joiner درست نصب شده و بصورت مشروح در بخش قبل ترکیب بندی شده باشد، یک مجری باید یک محیط پایگاه داده توزیع شده را برپاکند.
مجدداً، این کار برای کاربران Websphere و Visual Age لازم است که توابع DataJoiner را بکار برند که شامل دسترسی شفاف به یک سری منابع اطلاعات است.
فرایند ترکیب بندی توزیع شده می تواند تغییر کند که بستگی به نوع ارتباطات شبکه نصب شده دارد.
برای جزئیات، کتابچه راهنمای محصول DB2 را ملاحظه کنید یا از ترکیب بندی مشتری مجهز به دستیار با DB2 بعنوان راهنما استفاده نمایید.
چون یک ارتباط TCP/IP در این پروژه بین DB2 و DataJoiner استفاده شد، مراحل زیر لازم بود: یک ورودی گره TCP/IP به دایرکتوری گروه از طریق فرمان CATALOG TCPIP NODE اضافه کنید: این ورودی گره باید به نام معینی شده رجوع کند وقتی که ترکیب بندی پایگاه داده Data Joiner برای پشتیبانی دسترسی پایگاه داده توزیع شده از این نمونه DB2 تغییر داده شد.
اطلاعات درباره پایگاه داده Data Joiner را به پایگاه داده سیستم محلی از طریق فرمان CATALOGE وارد کنید.
اینکار باعث می شود برنامه های کاربردی DB2 با دسترسی شفاف به پایگاه داده DataJoiner مجهز گردد و منابع اطلاعات از راه دور DataJoiner برای پشتیبانی ترکیب بندی گردد.
در این پروژه پایگاه داده (sample) نمونه برای سیستم DB2 بصورت Vrechin معلوم گردید.
لذا یک برنامه کاربردی مکتوب JDBC برای این سیستم DB2 می توانست یک URL از Jdbc:de:Urchin را برای دسترسی سیستم DataJoiner و اوراکل های بیس و اینفورمیکس مورد رجوع قرار گیرد.
قبل از حرکت برای توسعه EJB، بهتر است ارتباط DB2-Data Joiner را آزمایش کنیم.
یک راه ساده برای انجام این کار چنین است: پردازشگر خط فرمان DB2 را فرا بخوانید.
سعی کنید که به پایگاه داده محلی وصل شوید که برای سیستم DataJoiner نگاشته می شود.
این امرمی تواند با صدور یک فرمان مثل CONECT TO URCHIN USER CINDY PASSWORD ITSME.
انجام شود.
جداول از راه دور پرس و جو کرده رجوع به اسامی مستعار مناسب دردستورات SQL را انجام دهید.
اگر لازم باشد، بطور دستی با منابع اطلاعات هدف ارتباط برقرار کنید، (از طریق SET PASSTHRU ) و این جداول یکسان را مستقیماً برای مقایسه نتایج پرس و جو کنید..
اگر لازم باشد هر جدول اضافی را ا یجاد کنید یا برای برنامه کاربردی خودتان در منبع اطلاعات مناسب بکار برید.
اگراین اشیاء (اهداف) باید بر روی یک سیستم غیر از DB2 یا DataJoiner قرار گیرد، بطور دستی به منبع اطلاعات هدف وصل شوید و دستورات SQL مناسب را صادر کنید.
بالاخره اسامی مستعار DataJoiner را برای این جداول و نمایش ها Views ایجاد کنید.
ترکیب بندی سرویس دهنده IBM HTTP: فعالیت های نصب و ترکیب بندی محصول استاندارد همگی برای عملکرد صحیح سرویس دهنده IBM HTTP در این محیط ضروری هستند.
از مستندات محصول برای جزئیات کمک بگیرید.
ترکیب بندی تألیف پیشرفته سرویس دهنده برنامه کاربردی WebSphere: Websphere برای دستورات محصول استاندارد نصب گردید، و یک سیستم DB2 V6.1 محلی برای ذخیره کردن اطلاعات اجرایی تعیین شد.
این سیستم DB2 برای دسترسی پایگاه داده توزیع شده به DataJoiner (قبلاً ذکر شده) ترکیب بندی شد.
(پارامتر ترکیب بندی DB2 اصلاح گردید و یک پایگاه داده‌اجرایی تولید گردید، برای دسترسی به DataJoiner و منابع اطلاعات آن در یک مجری Webspher باید: تایید کند که سرویس دهنده HTTP کار می کند سرویس Webspher Adminserver را استارت کنید و کنسول مجری را باز کنید.
یک JDBC درایور را بدنبال فرایند Websphere استاندارد ایجاد کنید.
یک نام مقبول تعیین کنید (مثلاً Sample JDBC) Com.
Ibn را بصورت کلاس اجرایی انتخاب کنید و JTA را False قرار دهید.
درایو JDBC را بدنبال فرایند webspher نصب کنید.
یک منبع اطلاعات مناسب را بدنبال فرایند webspher استاندارد ایجاد کنید (Types را انتخاب کنید) یک نام منطقی را تعیین کنید.
(مثلاً Dy Data Source).
برای نام پایگاه داده نام پایگاه داده مدیریت شده توسط Data Joiner را مشخص کنید همانگونه که برای سیستم DB2 موضعی تعیین هویت گردید.
برای محیط نویسنده ، این نام Yrchin بود.
بالاخره، درایو JDBC مناسب را که با این منبع اطلاعات مرتبط می باشد تعیین هویت کنید (Sample JDBC در این مورد) توجه کنید که Data Joiner هیچ مقررات خاصی را بر فرایند ترکیب بندی Webspher مقرر نمی کند مراحل قبلاً ذکر شده همگی برای آغاز Webspher لازم هستند و آن را قادر می سازند تا به یک DBMS پشتیبانی شده دسترسی یابند.
تنها فقره بی نظیر برای DataJoiner در آخرین bullet مشخص می شود جایی که مجری باید حداقل یک منبع اطلاعات تولید کند که یک پایگاه داده مدیریت شده توسط Data Joiner می شود را بجای یک پایگاه داده DB2 مدیریت شده موضعی باید تولید کند.
Visual Age برای ترکیب بندی Java: پس از نصب Visual Age برای Java به ازای هر دستورالعمل محصول، مار اضافی کمی لازم بود تا توسعه EJB و آزمایش را با استفاده از محیط پایگاه داده پشتیبانی شده توسط DB2 و Data Joiner قادر سازد.
مراحل اصلی شامل: اصلاح مسیر کلاس فضای کار برای لحاظ نمودن محل فایل DB2 V6.1 db2 Java.zip است.
این امر می تواند از طریق window – Apply انجام شود.
ویژگی های مناسب برای فضای کار را اضافه کنید.
فضای کار نوسنده شامل ویژگی ها برای توسعه EJB ، آزمایش webspher و دسترسی Persistence, Buifer بود.
ویژگی ها می تواند از طریق Add Featare اضافه شود.
توجه کنید که هر دوی این مراحل لازم هستند تا توسعه EJB را برای DB2 قادر سازند.
هیچ مقررات اضافی را بر فرایند ترکیب بندی Visual Age اعمال نمی کند.
اگر محیط های DataJoiner بطور صحیح ترکیب بندی شده باشند ، کارهای توسعه Visual Age می تواند طبق معمول پیش رود، و EJB ها می توانند برای دسترسی به منبع اطلاعات پشتیبانی شده توسط سیستم DataJoiner توسعه یابند.
ابزارهای Persitence Builder و Wizard های توسعه Cisual Age, EJB در اینجا می توانند کمک چشمگیری باشند، و برنامه نویسان را از طریق فرآیند هدایت کنند وکد ضروری را تولید نمایند.
در اکثر موارد، کد تولید شده برای این Bean های موجودیت CMP بطور موفق بدون تلاش بعدی اجرا نمی‌شوند،استثناها برای این قانون بعداً در این گزارش بحث می شوند.