خوشحال می شویم نظرات و پیشنهادات خود را در جهت بهبود کیفیت این مقاله با ما به اشتراک بگذارید.
در قسمت اول کاربرد و معرفی کامل مفاهیم و ساختار EJB به مباحث فراخوانی Enterprise JavaBeans ، پیاده سازی یک EJB و انواع EJB پرداختیم. در ادامه مبحث معرفی کامل مفاهیم و ساختار EJB در قسمت دوم این مقاله به توضیح نوع دیگر EJB یعنی Stateful Session Beans میپردازیم. قابلیت بازیابی دادهها با کلید اصلی توضیح داده میشود. EJB ها هنوز در حال رشد و گسترش هستند. ویژگیهای جدیدی در نمونه های توسعه داده شده اضافه شده از اینرو آشنایی و معرفی کامل مفاهیم و ساختار EJB اهمیت بسیاری برای فهم موضوع دارد. معماری EJB برای ساخت برنامه های بسیار مقیاس پذیر و قدرتمند در تجارت است.
در قسمت دوم معرفی کامل مفاهیم و ساختار EJB مباحث زیر را شرح خواهیم داد:
یک Stateful Session Beans وضعیت خود را بین متد فراخوانیها حفظ میکند. بنابراین، یک نمونه از Stateful Session Beans برای هر مشتری ایجاد میکند. هر Stateful Session Beansحاوی یک هویت و نگاشت یک به یک با یک مشتری خاص است. وضعیت این نوع bean در طی چندین فراخوانی از طریق سریالسازی وضعیت، حفظ میشود که به آن passivation (غیرفعال) گفته میشود. به همین دلیل وضعیتی که شما غیر فعال میکنید؛ باید قابل سریال سازی باشد. با این حال، این اطلاعات در هنگام خرابی سیستم باقی نمی مانند.
در معرفی کامل مفاهیم و ساختار EJB به منظور حفظ وضعیت چندینstateful beans حاوی مخزن، وضعیت conversational را به کمترین stateful beans را که اخیراً در یک ذخیرهسازی ثانویه استفاده شده، سریال میکند. هنگامی که توسط مشتری دوباره درخواست نمونه bean داده میشود، وضعیت برای یک bean با مخزن فعال شده است. از اینرو، همهی منابع به طور عملی استفاده می شوند و وضعیت از دست نمی رود.
این نوع از وضعیت ذخیره شده که شامل منابع نمی شود. کانتینر متد ejbPassivate را در داخل bean فراخوانی می کند تا bean فرصتی برای تمیز کردن منابع خود مانند سوکتهای نگهدارنده، اتصالات پایگاه داده و جداول هش با اطلاعات ثابت فراهم کند. همه این منابع می توانند در طول متد ejbActivate مجدداً تخصیص داده و دوباره ایجاد شوند.
اگر نمونه bean خراب شود، وضعیت را می توان از دست داد؛ مگر اینکه شما فعالیتی در bean انجام دهید تا وضعیت به طور مداوم ذخیره شود. با این حال، اگر باید اطمینان حاصل کنید که در صورت خرابیها، وضعیت به طور مداوم ذخیره می شود، ممکن است بخواهید از یک entity bean برای پیادهسازی خود استفاده کنید. متناوباً، شما همچنین می توانید از رابط SessionSynchronization برای تداوم وضعیت معاملات استفاده کنید.
به طور مثال، یک stateful session bean می تواند server side سبد خرید در یک برنامه خرید آنلاین را پیاده سازی کند، که می تواند متد هایی برای بازگرداندن لیستی از اشیایی که برای خرید موجود هستند، قرار دادن موارد در سبد خرید مشتری، ثبت سفارش، تغییر یک مشخصات مشتری و غیره را انجام دهد.
جدول stateful session bean :
| متد | پیاده سازی |
| رابط خانگی | javax.ejb.EJBHome را گسترش میدهد و به یک یا چند متد factory create() و یک متد remove() نیاز دارد. |
| رابط از راه دور | javax.ejb.EJBObject را گسترش میدهد و متدهای منطق تجاری را تعریف میکند، که در پیاده سازی bean اجرا می شود. |
| پیاده سازی bean | در این کلاس SessionBean را اجرا میکند. این بخش باید به صورت عمومی معرفی شود که شامل یکی از حالات public, empty, default constructor، بدون متد ()finalize است و متد های تعریف شده در رابط از راه دور را اجرا میکند. باید شامل متدهای ejbCreate معادل متد هایcreate() معرفی شده در رابط خانگی است. یعنی هر متد ejbCreate، با علامت پارامتر خود، با یک متد create() تعریف شده در رابط خانگی مطابقت دارد. متدهای کانتینر سرویس مانند ejbRemove و غیره را پیاده سازی میکند. همچنین، رابط SessionSynchronization را برای تراکنشهای مدیریت شده با کانتینر پیاده سازی میکند که شامل afterBegin ، beforeCompletion و afterCompletion است. |
در معرفی کامل مفاهیم و ساختار EJB کلید اصلی از مباحث مهم در ساختار EJB است. هرentity bean دارای هویت ماندگار وابسته با آن است. به این معنی که entity bean دارای یک هویت منحصر به فرد است که در صورت داشتن کلید اصلی قابل بازیابی است. با کلید اصلی مذکور، مشتری میتواند entity bean را بازیابی کند. اگر bean در دسترس نباشد، کانتینر نمونه سازیهای bean و دادههای ماندگار را برای شما دوباره جمعآوری میکند.
نوع کلید منحصر به فرد توسط ارائه دهنده bean تعریف می شود.
ماندگاری برای دادههای entity bean برای هر دو مورد ذخیرهسازی وضعیت وقتی bean غیر فعال شده و برای بازیابی وضعیت bean هنگامی که خرابی اتفاق افتاده را فراهم میکند. entity bean توانایی به باقی ماندن را داراست زیرا داده ها به طور مداوم توسط کانتینر در نوعی از فرمهای سیستم ذخیره سازی داده مانند پایگاه داده ذخیره میشوند. entity bean با استفاده از یکی از دو متد زیر داده های تجاری خود را ثابت نگه میدارد:
• به صورت خودکار توسط کانتینر با استفاده از یک container-managed persistent (CMP) (مدیریت پایدار کانتینر) در entity bean.
• به صورت برنامهریزی شده از طریق متد های پیاده سازی شده در یک bean-managed persistent (BMP) در entity bean. این متد ها از JDBC یا SQLJ برای مدیریت ماندگاری استفاده میکنند.
یکentity bean manages دادههای ماندگار خود را از طریق متد های فراخوانی برگشتی، که در رابط javax.ejb.EntityBean تعریف شده است ، مدیریت می کند. هنگامی که رابط EntityBean را در کلاس bean خود پیاده سازی میکنید، هر یک از تابعهای فراخوانی برگشتی را با توجه به نوع پایداری که انتخاب می کنید، توسعه می دهید: bean-managed persistence یا container-managed persistence. (مدیریت پایداری bean یا مدیریت پایداری کانتینر). کانتینر در زمانهای تعیین شده توابع فراخوانی برگشتی را فراخوانی می کند. در مبحث معرفی کامل مفاهیم و ساختار EJB کانتینر انتظار دارد که این متد ها دارای توابع زیر باشند:
شما باید یک متد ejbCreate متناظر با هر متد create معرفی شده در رابط خانگی را پیاده سازی کنید. وقتی مشتری متد create را فراخوانی می کند، کانتینر ابتدا سازنده را فراخوانی می کند تا شی را نمونه سازی کند، سپس متد ejbCreate متناظر را فراخوانی میکند. متد ejbCreate موارد زیر را انجام میدهد:
کانتینر پس از تنظیم محیط این متد را فراخوانی میکند. برای هر متد ejbCreate، یک متد ejbPostCreate باید با همان آرگومانها وجود داشته باشد. از این متد می توان برای مقداردهی اولیه پارامترها در entity context یا از آن استفاده کرد.
کانتینر این متد را قبل از اینکه عمر شی session به پایان برسد آن را فراخوانی میکند. این متد می تواند هرگونه clean-up مورد نیاز را انجام دهد، به عنوان مثال منابع خارجی مانند دسته فایلها را ببندد.
کانتینر درست قبل از انجام معامله های تصدیق شده این متد را فراخوانی می کند. با این کار دادههای پایدار را در یک منبع خارجی مانند پایگاه داده ذخیره میکند.
کانتینر هنگامی که داده ها باید دوباره از پایگاه داده شروع به مقداردهی کنند، این متد فراخوانی میکند. که معمولا پس از فعال شدن یک entity bean رخ می دهد.
نمونه bean را با اطلاعات متن مرتبط میکند. کانتینر این متد را پس از ایجاد bean فراخوانی میکند. enterprise bean (bean سازمانی) می تواند ارجاع به شی زمینه را در یک متغیر نمونه برای استفاده در مدیریت معاملات ذخیره کند. beans که معاملات خود را مدیریت میکند می تواند از session context برای بدست آوردن transaction context استفاده کند.
شما همچنین می توانید منابعی را که برای طول دوره beans وجود دارد در این متد اختصاص دهید. شما باید این منابع را در unsetEntityContext نشر دهید.
entity context مربوطه را بازنشاند (صفر کردن) و منابع اختصاص داده شده در setEntityContext را نشر میدهد.
کانتینر این متد را مستقیماً فراخوانی میکند قبل از اینکه شی که قبلا غیرفعال بوده را فعال کند. هرگونه درخواست مجدد لازم از منابع را در این متد اجرا میکند.
کانتینر این متد را قبل از اینکه شی را غیرفعال کند؛ فراخوانی میکند. هر منبعی را که می توانند به راحتی در ejbActivate دوباره ایجاد شوند نشر دهید و فضای ذخیره سازی را ذخیره کنید. به طور معمول، شما منابع آزادی مانند سوکت ها یا اتصالات پایگاه داده را میخواهید که نمی توانند غیرفعال باشند. این منابع را می توانید در متد ejbActivate بازیابی کنید.
یک entity bean مانند یک session bean است زیرا متد های معین فراخوانی برگشتی مانند ejbCreate در زمانهای مشخصی فراخوانی میشوند. Entity beans برای مدیریت داده های پایدار، کلید اصلی و اطلاعات متن از توابع فراخوانی برگشتی استفاده میکنند. نمودار زیر نشان میدهد که وقتی یک entity bean ایجاد میشود چه متدهایی را فراخوانی میکند.
نمودار(۱): ایجاد یک entity bean
معرفی کامل مفاهیم و ساختار EJB نیازمند تشریح نحوه استفاده setEntityContext است که یک نمونه entity bean از این متد برای حفظ ارجاع به متن استفاده میکند. entity bean دارای متنهایی هستند که کانتینر آنها را حفظ و در دسترس beans قرار می دهد. bean ممکن است از متدهای entity context برای بازیابی اطلاعات مربوط به bean مانند امنیت و نقش معاملاتی استفاده کند. برای اطلاعات گستردهای که میتوانید در bean از متن بازیابی کنید، به مشخصات Enterprise JavaBeans از Sun Microsystems مراجعه کنید.
این کانتینر بعد از اینکه از bean نمونهسازی کرد، متد setEntityContext را فراخوانی می کند تا bean بتواند متن را بازیابی کند. کانتینر هرگز این متد را از درون متن معاملاتی فراخوانی نخواهد کرد. اگر bean در این مرحله متن را ذخیره نکند، bean هرگز به متن دسترسی نخواهد یافت.
نکته: در همچنین می توانید از متد setEntityContext و unsetEntityContext برای تخصیص و تخریب منابعی که در طول دوره نمونه وجود دارد، استفاده کنید.
وقتی کانتینر این متد را فراخوانی میکند، مرجع شی EntityContext را به bean منتقل می کند. bean می تواند مرجع را برای استفاده بعدی ذخیره کند.
وقتی مشتری متد حذف را فراخوانی می کند، کانتینر متدهای نشان داده شده در شکل زیر را فراخوانی می کند.
حذف کردن Entity Bean
علاوه بر این، متد های ejbStore و ejbLoad برای مدیریت داده های پایدار شما فراخوانی می شوند. اینها مهمترین متدهای فراخوانی برگشتی برای bean-managed persistent beans هستند. Container-managed persistent beans می توانند این متدها را خالی بگذارند، زیرا ماندگاری توسط کانتینر کنترل میشود.
شما می توانید انتخاب کنید که persistence Container-Managed دادههای ماندگار را برای bean داشته باشید. برای مدیریت ماندگاری دادههای bean شما نیازی به اجرای برخی از متد های فراخوانی برگشتی ندارید، زیرا کانتینر دادههای پایدار شما را در پایگاه داده ذخیره و بارگیری میکند. هنگامی که از container-managed persistence (مدیریت کانتینر پایداری) استفاده می کنید، کانتینر یک کلاس مدیریتی پایدار را فراخوانی میکند که مدیریت پایدار منطق تجاری را فراهم میکند. علاوه بر این، نیازی به مدیریت کلید اصلی ندارید: کانتینر این کلید را برای bean فراهم میکند.
• متد های فراخوانی برگشتی – کانتینر همچنان متد های فراخوانی برگشتی را فراخوانی میکند، بنابراین شما میتوانید منطق را برای اهداف دیگر اضافه کنید. در بدترین حال نیز شما باید یک پیاده سازی خالی برای همه متد های فراخوانی برگشتی ارائه دهید.
• کلید اصلی – فیلدهای کلید اصلی در یک bean CMP باید به عنوان فیلدهای container-managed persistence در توصیفگر موقعیت معرفی شوند. همهی فیلدهای موجود در کلید اصلی تحت کنترل هستند که میتوانند عنصر اولیه، قابلیتی سریال سازی و انواعی که می تواند به انواع SQL نگاشت شوند، را در برمیگیرد. جدول زیر جزئیات مورد نیاز پیادهسازی توابع فراخوانی برگشتی کلاس bean را شرح میدهد:
پیاده سازی توابع فراخوانی برگشتی:
| متد فراخوانی برگشتی | نیازهای عملیاتی |
| ejbCreate | شما باید تمام فیلدهای container-managed persistence را از جمله کلید اصلی مقداردهی اولیه کنید. |
| ejbPostCreate | شما می توانید هر مقدار اولیه را که می تواند entity context را درگیر کند، ارائه دهید. |
| ejbRemove | هیچ عملیاتی برای حذف دادههای پایدار از منبع خارجی مورد نیاز نیست. شما حداقل باید یک پیاده سازی خالی برای فراخوانی برگشتی را ارائه دهید، به این معنی که شما می توانید برای آماده سازی هرگونه عملیاتی که در cleanup نیاز دارید؛ منطق را اضافه کنید. |
| ejbFindByPrimaryKey | برای بازگشت کلید اصلی به کانتینر، هیچ عملیاتی لازم نیست. کانتینر کلید اصلی را مدیریت می کند؛ پس از آنکه با متد ejbCreate مقداردهی اولیه شد. شما هنوز هم باید یک پیاده سازی خالی برای این متد فراهم کنید. |
| ejbStore | برای ذخیره داده های پایدار در این متد، هیچ عملیاتی لازم نیست. persistent manager تمام دادههای پایدار را برای شما در پایگاه داده ذخیره می کند. به هر حال، شما باید حداقل یک پیاده سازی خالی فراهم کنید. |
| ejbLoad | برای بازیابی دادههای پایدار در این متد، هیچ عملیاتی لازم نیست. persistence manager تمام دادههای پایدار را برای شما بازیابی میکند. به هر حال، شما باید حداقل یک پیاده سازی خالی فراهم کنید. |
| setEntityContext | نمونه Bean را با اطلاعات متن مرتبط میکند. کانتینر این متد را پس از ایجاد bean فراخوانی میکند. bean سازمانی می تواند ارجاع به شی متن را در یک متغیر نمونه برای استفاده در transaction management (مدیریت معاملات) ذخیره کند. beans که معاملات خود را مدیریت میکند می تواند از session context برای بدست آوردن transaction context (متن معامله) استفاده کند. شما همچنین می توانید منابعی را که برای طول دوره beans وجود دارد در این متد اختصاص دهید. شما باید این منابع را در unsetEntityContext نشر دهید. |
| unsetEntityContext | entity context مرتبط را باز کرده و منابع اختصاص داده شده در setEntityContext را نشر دهید. |
container-managed persistence
برای مدیریت دادههای پایدار در یک entity bean، دو متد وجود دارد: bean-managed (BMP) و container-managed persistence (CMP). تفاوت اصلی بین beanهای BMP و CMP با توجه به اینکه کدام یک پایداری دادههای entity bean را مدیریت میکند، تعریف می شود. با bean CMP، کانتینر پایداری را مدیریت میکند. توصیفگر موقعیت bean نحوهی نگاشت داده ها و محل ذخیره داده ها را مشخص می کند. با استفاده از bean BMP ، منطق ذخیره سازی داده ها و محل ذخیره آنها با متد های تعیین شده برنامه ریزی میشود. این متدها در لحظههای مناسب توسط این کانتینر فراخوانی می شود.
در عبارتهای کاربردی، جدول زیر هر دو نوع را معرفی میکند و خلاصه ای برنامهها و تفاوت بین این دو را شرح میدهد:
تفاوت Bean و container-managed persistence در معرفی کامل مفاهیم و ساختار EJB
| Bean-Managed Persistence | Container-Managed Persistence | |
| Persistence management | شما باید مدیریت پایداری را در متدهای ejbStore ، ejbLoad ، ejbCreate و ejbRemove EntityBean پیاده سازی کنید. این متد ها باید حاوی منطقی برای ذخیره و بازیابی دادههای پایدار باشند. به طور مثال، متد ejbStore باید منطقی در خود داشته باشد تا داده های entity bean را در پایگاه داده مناسب ذخیره کند. اگر چنین نباشد، داده ها می توانند از بین بروند. | مدیریت داده های پایدار برای شما انجام شده است. به این معنا که کانتینر از طرف bean شما مدیر پایداری را فراخوانی میکند. شما از ejbStore و ejbLoad برای تهیه دادهها قبل از تصدیق شدن و یا برای دستکاری داده ها پس از بازسازی از پایگاه داده، استفاده میکنید. کانتینر همیشه قبل از تصدیق، متد ejbStore را فراخوانی میکند. به علاوه، همیشه درست پس از بازگرداندن اطلاعات CMP از پایگاه داده، متد ejbLoad را فراخوانی میکند. |
| Finder methods allowed | متد findByPrimaryKey و دیگر متدهای جستجو مجاز هستند. | متد findByPrimaryKey و دیگر شروط متدهای جستجو مجاز هستند. |
| Defining CMP fields | N / A | به توصیفگر موقعیت EJB نیاز است. کلید اصلی نیز باید به عنوان یک فیلد CMP معرفی شود. |
| Mapping CMP fields to resource destination | N / A | ضروری است و به persistence manager وابسته است. |
| Definition of persistence manager | N / A | در توصیفگر موقعیت مخصوص اوراکل مورد نیاز است. برای یک توصیفگرpersistence manager به بخش بعدی مراجعه کنید. |
Message-Driven Beans (MDB) متدی سادهتر برای پیاده سازی ارتباط آسنکرون نسبت به استفاده مستقیم JMS را فراهم می کند. MDB ها برای دریافت پیام های JMS آسنکرون ایجاد شده اند. این کانتینر قسمت عمده تنظیمات مورد نیاز برای صفها و موضوعات JMS را برطرف میکند. همه پیام ها را برای MDB مورد نظر ارسال میکند.
پیش از این، EJB ها نمی توانستند پیام های JMS را ارسال یا دریافت کنند. ایجاد MDB برای یک شی از نوع EJB برای دریافت پیام های JMS به طول انجامید. این قابلیت آسنکرون و انتشار/ اشتراک در یک شی سازمانی را فراهم می کند که می تواند با سایر اشیا Java (جاوا) سنکرون باشد.
هدف از وجود MDB در یک مخزن دریافت و پردازش پیام های دریافتی از صف JMS است. کانتینر یک bean را از صف فراخوانی میکند تا هر پیام دریافتی از صف را کنترل کند. هیچ شی مستقیماً از MDB را فراخوانی نمیکند: تمام فراخوانی MDB از کانتینر حاصل میشود. پس از فراخوانی کانتینر به MDB، می تواند سایر EJB ها یا اشیا Java (جاوا) را برای ادامه درخواست فراخوانی کند.
یک MDB مشابه stateless session bean است زیرا وضعیت conversational را ذخیره نمیکند و برای رسیدگی به چندین درخواست ورودی استفاده میشود. MDBها به جای رسیدگی به درخواستهای مستقیم مشتری، درخواستهایی را که در یک صف قرار گرفتهاند، رسیدگی می کنند. در معرفی کامل مفاهیم و ساختار EJB می توان در تصویر(۲) نحوه قرار دادن درخواستهای مشتریان با یک صف را نشان می دهد. کانتینر درخواست ها را از صف خارج میکند و درخواست را به MDB موجود در مخزن خود میدهد.
تصویر(۲): Message-Driven Beans
MDBها رابط javax.ejb.MessageDrivenBean را پیاده سازی میکنند که همچنین متدهای javax.jms.MessageListener را به ارث می برد. در این رابطها، متد های زیر باید پیاده سازی شوند:
پیاده سازی متدهای لازم برای Message-Driven Beans در معرفی کامل مفاهیم و ساختار EJB
| متد | توضیح |
| onMessage(msg) | کانتینر پیامی از صف JMS مرتبط با MDB را برمیدارد و با فراخوانی این متد آن را به این نمونه می دهد. این متد باید یک پیاده سازی برای مدیریت مناسب پیام داشته باشد. |
| setMessageDrivenContext(ctx) | پس از ایجاد bean ، متد setMessageDrivenContext فراخوانی میشود. این متد مشابه متد EJB setSessionContext و setEntityContext است. |
| ejbCreate() | این متد دقیقاً مانند متد ejbCreate در stateless session bean استفاده میشود. در این متد هیچگونه مقداردهی اولیه نباید انجام شود. با این حال، منابعی که در این متد اختصاص می دهید برای این شی وجود دارد. |
| ejbRemove() | منابعی را که در متد ejbCreate اختصاص داده شده را حذف کنید. |
این کانتینر بازیابی و تأیید پیام JMS را کنترل می کند. شما نیازی ندارید در MDB تان نگران مشخصات JMS باشید. MDB با صف موجود JMS مرتبط است. پس از اتصال، کانتینر با حذف پیام ها و ارسال تأییدیه ها کار میکند. کانتینر پیام JMS را از طریق متد onMessage برقرار میکند.
تفاوت عمده بین Session و Entity Beans در این است که Entity Beans شامل چارچوبی برای مدیریت پایدار دادهها، شناسایی پایدار و منطق تجاری پیچیده است. جدول زیر رابط های مختلف برای Entity Beans و Session را نشان می دهد. دقت کنید که تفاوت بین دو نوع EJB در کلاس bean و کلید اصلی وجود دارد. همه مدیریت دادههای پایدار در متدهای کلاس bean انجام میشود.
جدول تفاوت بین Session و Entity Beans در معرفی کامل مفاهیم و ساختار EJB
| Entity Bean | Session Bean | |
| Remote interface | javax.ejb.EJBObject را گسترش میدهد. | javax.ejb.EJBObject را گسترش میدهد. |
| Home interface | javax.ejb.EJB صفحه اصلی را گسترش می دهد. | javax.ejb.EJB صفحه اصلی را گسترش می دهد. |
| Bean class | javax.ejb.EntityBean را گسترش می دهد | javax.ejb.SessionBean را گسترش می دهد. |
| Primary key | برای شناسایی و بازیابی موارد خاص از bean استفاده می شود. | برای session beans استفاده نمیشود. Stateful session beans دارای یک هویت هستند، اما از خارجی خارج نمی شوند. |
در این مقاله به معرفی کامل مفاهیم و ساختار EJB پرداختیم. EJB نیز مانند همهی برنامهها توسعه مییابد و آشنایی با اصول اولیه برای پیشبرد اهداف و درک آن کمک شایانی به شما میکند.
خوشحال می شویم نظرات و پیشنهادات خود را در جهت بهبود کیفیت این مقاله با ما به اشتراک بگذارید.
در دنیای بی‌پایان نرم‌افزارها و فایل‌های دیجیتال، امنیت در دانلود و استفاده از آنها یک…
شرکت ایسوس یکی از پیشتازان در صنعت فناوری اطلاعات و الکترونیک است که در زمینه…
آیا شما هم به دنبال کار با کد های پاورشل برای هک هستید؟ در این…
این روزها که همه افراد به دنبال یک شغل پردرآمد می گردند، مشغول به کار…
خطای page isn’t available right now یکی از آزار دهنده ترین مشکلاتی است که کاربران…
ویندوز پاورشل چیست؟ پاورشل ابزاری قدرتمند به حساب می آید که همه افراد علاقه مند…