PDA

View Full Version : Spring Framework و JavaEE



mazdadoost
شنبه 11 مهر 1388, 12:01 عصر
با سلام
در این تا پیک سعی داریم در باره امکانات Spring Framework و javaEE صحبت کنیم. از همه دوستانی که علاقمند به این مبحث هستن دعوت می کنم تا در این تاپیک شرکت کنند.
Spring Framework و JavaEE

cups_of_java
شنبه 11 مهر 1388, 14:24 عصر
در باره امکانات Spring Framework و javaEE!؟

این ها دو مورد مجزا هستند! می خواین مقایسشون کنید؟ می خواین تفاوت ها و شباهت هاشونو بگید؟...؟

shahryary
شنبه 11 مهر 1388, 15:44 عصر
فکر کنم منظور دوستمون اینکه کلا فریم وورک Spring رو کالبد شکافی کنیم .....
امکانات ...
ویژگی ها ...
مقایسه بین struts و....

javaphantom
شنبه 11 مهر 1388, 21:43 عصر
javaee یک پلت فرم استاندارد هست که مربوط به سان هست که شامل یک سری api ها یایی هست که همانطور که گفته شد استاندارد می باشند و می تونی با این api ها در قسمت enterprise تولید محصول داشته باشی.
اما در کنار این محصول استاندارد شرکتهای مختلف با استفاده از همین platform یا با رعایت کردن JSR محصولهایی که سان بصورت استاندارد تعریف کرده رو پیاده سازی می کنند و یا همانطور که گفتم با استفاده از همان api های استاندارد یعنی خود platform جاوا در لایه های بالاتر api های جدیدتری ارائه می کنند. سایت apache پره از این api ها که همگی در لایهای پایین تر از api های javaee استفاده شده و همینطور محصولاتی که بنا به تعریف JSR یا استانداردی که از طرف سان بوده محصول رو تولید یا implement کردن. اما framework چی هست؟ من توی این سایت خیلی وقت ها در مورد فریم ورک به اشتباه متن خوندم. نه فقط تعریف بلکه مفهوم و استفاده از آن.

ُSpring یک فریم ورک هست که بسیار popular هست و طرفدارهای زیادی داره از جمله خوده من. هر چند من از اون دسته آدمها هستم که می گم استاندارد بودن خیلی ارزش و مفهوم بالاتری داره تا تولید که محصول و هرچند اون محصول هم بخواد popular باشه.
اما طرح این سوال از نظر من کمی مشکل داره. چون تعریفی که از اول شروع کردم مسئله کاملا مشخص شده که J2EE یک platform هست و خیلی داستانش فرق می کنه با spring که یک فریم ورک هست. شاید منظور این بوده که تکنولوژی های موجود در j2ee در فریم ورک spring چگونه در نظر گرفته شده یا یک چیزی شبیه این.

shahryary
شنبه 11 مهر 1388, 22:42 عصر
به نظر من بیاییم درباره spring بحث رو گسترش بدیم ،
یکی از ویژگی هایی که در فریم وورک Spring موجوده و قابل تامل هستش اینکه struts رو هم پشتیبانی داره (include struts ) - پشتیبانی که صحبت میشه اینه که struts بر اساس MVC framework هستش در جالیکه که Spring علاوه بر مزایای دیگه ای که داره همین MVC رو هم ارایه میده .
اما بیاین بحث رو گسترش بدیم ، بیاین همانطور که دوستمون java phantom گفت در مورد استاندارد فریم وورک ها صحبت کنیم و ببینیم واقعا چه فریم وورکی و در چه جایی باید استفاده شود ، مزایای این spring چی هست که واقعا بهش میگم استاندارده ....
در کنار اینا باید ejb رو هم در نظر بگیریم ........
به نظر من ما که همش داریم همه چیزو مقایسه میکنیم ، ولی نتیجه چی ؟
بیاین بشینیم در مورد تک تک فریم وورک ها صحبت کنیم ، درسته منابع انگلیسی بیشتره و هر کی بگرده پیدا میکنه ، ولی اینو در نظر بگیریم که فعلا کاربرا دارن این سایت رو میبینن
پیشنهاد میکنم هر اطلاعاتی داریم share کنیم ، کاربر بخونه تصمیم بگیره
بیاین از همین spring شروع کنیم هر چی بلدین یا علی ...

javaphantom
یک شنبه 12 مهر 1388, 09:54 صبح
به نظر من بیاییم درباره spring بحث رو گسترش بدیم ،
یکی از ویژگی هایی که در فریم وورک Spring موجوده و قابل تامل هستش اینکه struts رو هم پشتیبانی داره (include struts ) - پشتیبانی که صحبت میشه اینه که struts بر اساس MVC framework هستش در جالیکه که Spring علاوه بر مزایای دیگه ای که داره همین MVC رو هم ارایه میده .
اما بیاین بحث رو گسترش بدیم ، بیاین همانطور که دوستمون java phantom گفت در مورد استاندارد فریم وورک ها صحبت کنیم و ببینیم واقعا چه فریم وورکی و در چه جایی باید استفاده شود ، مزایای این spring چی هست که واقعا بهش میگم استاندارده ....
در کنار اینا باید ejb رو هم در نظر بگیریم ........
به نظر من ما که همش داریم همه چیزو مقایسه میکنیم ، ولی نتیجه چی ؟
بیاین بشینیم در مورد تک تک فریم وورک ها صحبت کنیم ، درسته منابع انگلیسی بیشتره و هر کی بگرده پیدا میکنه ، ولی اینو در نظر بگیریم که فعلا کاربرا دارن این سایت رو میبینن
پیشنهاد میکنم هر اطلاعاتی داریم share کنیم ، کاربر بخونه تصمیم بگیره
بیاین از همین spring شروع کنیم هر چی بلدین یا علی ...

spring فریم ورک استاندارد نیست و من در هیچ جا از متنم به این مسئله که spring یک فریم ورک استاندارد هست اشاره نکردم.

اصلا فریم ورک چی هست؟

shahryary
یک شنبه 12 مهر 1388, 13:29 عصر
spring فریم ورک استاندارد نیست و من در هیچ جا از متنم به این مسئله که spring یک فریم ورک استاندارد هست اشاره نکردم.

اصلا فریم ورک چی هست؟


میتونیم برای خودمون استاندارد رو اصلا تعریف کنیم ؟ ما به چه سیستمی استاندارد میگیم ؟ این استانداردها چطور تدوین میشه ؟ و اگه spring استاندارد نیست ! آیا معیار استاندارد ما فرق میکنه یا امکانات Spring ؟
نمیدونم استاندارد رو بسته به چه معیاری باید انتخاب کرد ولی خود سایت http://www.springsource.com/products/enterprise
این فریم وورک و داره استاندارد تعریف میکنه !

cups_of_java
یک شنبه 12 مهر 1388, 14:30 عصر
میتونیم برای خودمون استاندارد رو اصلا تعریف کنیم ؟ ما به چه سیستمی استاندارد میگیم ؟ این استانداردها چطور تدوین میشه ؟ و اگه spring استاندارد نیست ! آیا معیار استاندارد ما فرق میکنه یا امکانات Spring ؟
نمیدونم استاندارد رو بسته به چه معیاری باید انتخاب کرد ولی خود سایت http://www.springsource.com/products/enterprise
این فریم وورک و داره استاندارد تعریف میکنه !


استاندارد سازی درجات مختلف داره. استاندارد ها یک جور تعریف نمی شن. سطوح استاندارد سازی فرق می کنه. غیر از استاندارد هایی که به طور Spec و یا توسط سازمان های استاندارد سازی تنظیم و تعریف میشه. هر آنچه که در فرهنگ و یا عادات جا بیافته و به رسم و یا استفاده بالا تبدیل بشه رو هم استاندارد (از نوع de facto ) می شناسن. Spring هم همین طور هست. یعنی دیگه بین جاوا کاران enterprise تبدیل به یک استاندارد شده که همی می شناسنش و ازش تبعیت می کنند مثل همون Java Spec. comminuty. استاندارد ها رو گاهی میزان کاربرد ها مشخص می کنند نه شرکت ها!

همه می دونیم که Java EE یک پلت فرم هست. یک مجموعه بزرگ از استاندارد ها برای نیاز های سازمانی مختلف. Spring در نقطه مقابل می شینه و می گه به جای اینکه اینقدر قضیه رو سختش کنید بیاید در قالب یک چارچوب (framework) مشخص و ساده (به نسبت ساده البته) جاوا بنویسید. این چارچوب خودش بهترین الگو ها رو انتخاب کرده براتون تا شما در گیر وصل کردن نقاط مختلف برنامتون و طراحی نشید.
(فریم ورک رو میشه چارچوبی از الگوهای تعریف شده و انتخاب شده و بهینه برای یک هدف خاص دونست که قالبی برای کاربرش تعریف می کنه تا کاربر بتونه برای نیاز خودش در راستای همون هدف فریم ورک محصول ایجاد کنه)

مسله اینجایت که باید دید آیا به الگوهای مبنایی مثل Dependency Injection و اصل IOC که بطن spring هست نیازی دارید یا نه!؟ آیا دوست دارین سرویس های مختلف رو کم کم دور POJOهای خودتون بپیجید تا خیر؟ شما می تونید POJOهای موجود در spring رو به EJB تبدیل کنید! می تونید از JAVA Persistence API استفاده کنید و ...

این دو خیلی از هم دور نیستند ولی اینکه چگونه می تونن در آینده به هم پیوند بخورند باید سیر گذار تکنولوژیک رو دید!

اما شما در مواردی نیاز پیدا می کنید که از مدل های استاندارد شده قویتری (یعنی Java EE) استفاده کنید تا بتونید در دل هر containerی قرار بگیرید و نرم افزار های بین سازمانی بسازید. به یک Buss سرویس وصل شید و ... در این موارد شاید کاربرد Spring به صرفه نباشه.

shahryary
یک شنبه 12 مهر 1388, 22:36 عصر
استاندارد سازی درجات مختلف داره. استاندارد ها یک جور تعریف نمی شن. سطوح استاندارد سازی فرق می کنه. غیر از استاندارد هایی که به طور Spec و یا توسط سازمان های استاندارد سازی تنظیم و تعریف میشه. هر آنچه که در فرهنگ و یا عادات جا بیافته و به رسم و یا استفاده بالا تبدیل بشه رو هم استاندارد (از نوع de facto ) می شناسن. Spring هم همین طور هست. یعنی دیگه بین جاوا کاران enterprise تبدیل به یک استاندارد شده که همی می شناسنش و ازش تبعیت می کنند مثل همون Java Spec. comminuty. استاندارد ها رو گاهی میزان کاربرد ها مشخص می کنند نه شرکت ها!

همه می دونیم که Java EE یک پلت فرم هست. یک مجموعه بزرگ از استاندارد ها برای نیاز های سازمانی مختلف. Spring در نقطه مقابل می شینه و می گه به جای اینکه اینقدر قضیه رو سختش کنید بیاید در قالب یک چارچوب (framework) مشخص و ساده (به نسبت ساده البته) جاوا بنویسید. این چارچوب خودش بهترین الگو ها رو انتخاب کرده براتون تا شما در گیر وصل کردن نقاط مختلف برنامتون و طراحی نشید.
(فریم ورک رو میشه چارچوبی از الگوهای تعریف شده و انتخاب شده و بهینه برای یک هدف خاص دونست که قالبی برای کاربرش تعریف می کنه تا کاربر بتونه برای نیاز خودش در راستای همون هدف فریم ورک محصول ایجاد کنه)

مسله اینجایت که باید دید آیا به الگوهای مبنایی مثل Dependency Injection و اصل IOC که بطن spring هست نیازی دارید یا نه!؟ آیا دوست دارین سرویس های مختلف رو کم کم دور POJOهای خودتون بپیجید تا خیر؟ شما می تونید POJOهای موجود در spring رو به EJB تبدیل کنید! می تونید از JAVA Persistence API استفاده کنید و ...

این دو خیلی از هم دور نیستند ولی اینکه چگونه می تونن در آینده به هم پیوند بخورند باید سیر گذار تکنولوژیک رو دید!

اما شما در مواردی نیاز پیدا می کنید که از مدل های استاندارد شده قویتری (یعنی Java EE) استفاده کنید تا بتونید در دل هر containerی قرار بگیرید و نرم افزار های بین سازمانی بسازید. به یک Buss سرویس وصل شید و ... در این موارد شاید کاربرد Spring به صرفه نباشه.
حرف شما متین دوست عزیز ولی ...
آیا لزوما هر چیزی رو که کاربرا استفاده میکنند میشه بهش استاندارد گفت ؟! یه مثال :خود ویندوز که بیش از 90 % سیستم ها رو تشکیل میده ، آیا استاندارده ؟ در مقابل لینوکس
ولی خود این لینوکس رو اومدن استاندارد سازی کردن ( پروسس ها ، کرنل و ..... ) اینا رو کاربرای مختلف و افراد سازمانی و ... انجام دادن .... نه اینکه چون پر کاربرده حتما استاندارده
... البته تا حدودی هم حرف شما رو در مورد de facto قبول دارم
حالا همونطور که گفتین چجوری بیاییم الگوهامونو مشخص کنیم تا یه فریم وورک رو انتخاب کنیم ؟ این نمیشه که بشینیم واسه خودمون یه فریم وورک بنویسیم !
به نظر شما نقطه تقابل spring و EJB و .... کجاست ؟ طبق تعریف هایی که داریم به نظرتون کدوم یک میتونن در آینده موفق تر باشن ؟ البته میدونم که بسته به پروژه کاربرد هر یک متفاوته ...

cups_of_java
دوشنبه 13 مهر 1388, 10:51 صبح
حرف شما متین دوست عزیز ولی ...
آیا لزوما هر چیزی رو که کاربرا استفاده میکنند میشه بهش استاندارد گفت ؟!


همونطور که گفتم باید دید و تعریفمون از استاندارد سازی رو مشخص و طبقه بندی شده کرد. منظور از این استاندارد اون استاندارد های ISO و ... نیست. اینجوری ببینیم Java EE هم استاندارد نیست.



حالا همونطور که گفتین چجوری بیاییم الگوهامونو مشخص کنیم تا یه فریم وورک رو انتخاب کنیم ؟ این نمیشه که بشینیم واسه خودمون یه فریم وورک بنویسیم !
به نظر شما نقطه تقابل spring و EJB و .... کجاست ؟ طبق تعریف هایی که داریم به نظرتون کدوم یک میتونن در آینده موفق تر باشن ؟ البته میدونم که بسته به پروژه کاربرد هر یک متفاوته ...

من فکر نمی کنم ایندو هر کدوم به تنهایی موفق بشن. هر کدون نیاز های خاصی رو جواب می دن همونطور که گفتم اما پیش بینی من با این عقل ناقصم اینه که ایندو به هم نزدیک خواهند شد و به هم خواند رسید. یعنی ترکیب ایندو با هم.
ببینید من فکر نمی کنم بشه Spring رو با EJB مقایسه کرد. Spring یه فریم ورک گسترده و عمومی با کاربرد عمومی هست اما EJB یک تکنولوژی و استاندارد (شاید هم فریم ورک به نوعی دیگه) برای پاسخ دهی به نیاز های Distributed Computing هست. غیر از بحث توزیع شدگی استفاده از EJB جایز نیست. اکثرن فقط به خاطر Persistency و یا Transaction Management از EJB استفاده می کردند و می کنند که این کار اشتباه هست.

این که شما لایه EJB داشته باشی یه چیز جداست! اما Spring می تونه کل معماری و لایه های نرم افزار شما رو در بر یگیره که مثلن یه قسمتش هم EJB باشه.

نمی دونم چقدر از حرفام روشن بود براتون.

shahryary
دوشنبه 13 مهر 1388, 14:15 عصر
همونطور که گفتم باید دید و تعریفمون از استاندارد سازی رو مشخص و طبقه بندی شده کرد. منظور از این استاندارد اون استاندارد های ISO و ... نیست. اینجوری ببینیم Java EE هم استاندارد نیست.




من فکر نمی کنم ایندو هر کدوم به تنهایی موفق بشن. هر کدون نیاز های خاصی رو جواب می دن همونطور که گفتم اما پیش بینی من با این عقل ناقصم اینه که ایندو به هم نزدیک خواهند شد و به هم خواند رسید. یعنی ترکیب ایندو با هم.
ببینید من فکر نمی کنم بشه Spring رو با EJB مقایسه کرد. Spring یه فریم ورک گسترده و عمومی با کاربرد عمومی هست اما EJB یک تکنولوژی و استاندارد (شاید هم فریم ورک به نوعی دیگه) برای پاسخ دهی به نیاز های Distributed Computing هست. غیر از بحث توزیع شدگی استفاده از EJB جایز نیست. اکثرن فقط به خاطر Persistency و یا Transaction Management از EJB استفاده می کردند و می کنند که این کار اشتباه هست.

این که شما لایه EJB داشته باشی یه چیز جداست! اما Spring می تونه کل معماری و لایه های نرم افزار شما رو در بر یگیره که مثلن یه قسمتش هم EJB باشه.

نمی دونم چقدر از حرفام روشن بود براتون.

حرفاتون برام کاملا روشنه ...
این بحث رو چون میخوایم برامون استانداردها و فریم وورک ها روشن بشه و کاربرا بدونن چجوری باید یه بستر و فریم وورک مناسب رو انتخاب کنن ، ادامه و بحث میکنیم .
به نظر من حالا اگه بتونیم فعلا spring رو تشریح کنیم بد نشه !

javaphantom
دوشنبه 13 مهر 1388, 14:32 عصر
خوب پس مشخص شده که فریم ورک یک چارچوب هست پس یعنی چی دایی ؟ یعنی اینکه محدود هستی. ولی خوب بزرگترین خوبیشم اینکه مثل یک box می شه نگاش کرد که کاری به داخل باکس نداری ولی با دادن ورودی مشخص باید خروجی مطلوب رو بدست بیاری.

اما platform همانطور که اشاره شده داستانش خیلی فراتر از یک چهارچوب هست کلا همه این چهارچوب ها روی این platform ساخته می شه. ولی خوب بدیش اینکه باید داخل اون box خودت بیل بزنی.

حالا استاندارد چرا خوبه؟ همیشه تعریف کردن یک سری پیش شرطها و یک سری آرمانها و تلاش برای رعایت کردن و رسیدن به آن آرمانها و ایجاد همفکری و مدیریت آنها خیلی بحث مهمی هست تا هرکی برای خودش هر کاری که دوست داره بکنه و بعدش ذوق کنه. همه جا که ایران و ایرانی نیست که پسر خوب shahryary جان.

کی این آرمانها و پیش شرطها رو تعریف می کنه و یا به بهبود آن کمک می کنه؟ کسی یا کساین که صاحب نظر باشن و مرد عمل .

شما بهتره توی اینترنت در مورد JSR و JCP-The Java Community Process یک جستجوی کوچیکی بزنی و مفهموم مشارکت و استاندارد و از همه مهمتر مدیریت کردن رو بیشتر با هاش آشنا بشی. ماکروسافت نیست که هر جور دوست داره عمل کنه و یک مشت کاربر عامی یا بهتر بگم بی سواد که شما هم به تعداد آنها اشاره کردید از آن استفاده کنند.

کلا همانطور که قبلا هم گفتم مقایسه یک platform با یک framework کاریست اشتباه اما مقایسه ejb با spring و مفاهیم از جمله IoC و یا aspect oriented و یا بحث دیگر تکنولوژیهای مربط به سان که در این فریم ورک در نظر گرفته شده است قابل توجه هست که اگر بد نباشه از قسمت IoC و کلا مفهوم dependency injection و کارکرد یک container در فریم ورک spring و ejb به نظر من آغاز خوبی هست

shahryary
دوشنبه 13 مهر 1388, 16:43 عصر
خوب پس مشخص شده که فریم ورک یک چارچوب هست پس یعنی چی دایی ؟ یعنی اینکه محدود هستی. ولی خوب بزرگترین خوبیشم اینکه مثل یک box می شه نگاش کرد که کاری به داخل باکس نداری ولی با دادن ورودی مشخص باید خروجی مطلوب رو بدست بیاری.

اما platform همانطور که اشاره شده داستانش خیلی فراتر از یک چهارچوب هست کلا همه این چهارچوب ها روی این platform ساخته می شه. ولی خوب بدیش اینکه باید داخل اون box خودت بیل بزنی.

حالا استاندارد چرا خوبه؟ همیشه تعریف کردن یک سری پیش شرطها و یک سری آرمانها و تلاش برای رعایت کردن و رسیدن به آن آرمانها و ایجاد همفکری و مدیریت آنها خیلی بحث مهمی هست تا هرکی برای خودش هر کاری که دوست داره بکنه و بعدش ذوق کنه. همه جا که ایران و ایرانی نیست که پسر خوب shahryary جان.

کی این آرمانها و پیش شرطها رو تعریف می کنه و یا به بهبود آن کمک می کنه؟ کسی یا کساین که صاحب نظر باشن و مرد عمل .

شما بهتره توی اینترنت در مورد JSR و JCP-The Java Community Process یک جستجوی کوچیکی بزنی و مفهموم مشارکت و استاندارد و از همه مهمتر مدیریت کردن رو بیشتر با هاش آشنا بشی. ماکروسافت نیست که هر جور دوست داره عمل کنه و یک مشت کاربر عامی یا بهتر بگم بی سواد که شما هم به تعداد آنها اشاره کردید از آن استفاده کنند.

کلا همانطور که قبلا هم گفتم مقایسه یک platform با یک framework کاریست اشتباه اما مقایسه ejb با spring و مفاهیم از جمله IoC و یا aspect oriented و یا بحث دیگر تکنولوژیهای مربط به سان که در این فریم ورک در نظر گرفته شده است قابل توجه هست که اگر بد نباشه از قسمت IoC و کلا مفهوم dependency injection و کارکرد یک container در فریم ورک spring و ejb به نظر من آغاز خوبی هست
دقیقا ، ما میخوایم بهتر مسیر رو بشناسیم نه اینکه مسیرمونو دور بزنیم ! مثلا چون نتونستیم این کار رو با این تکنولوژی انجام بدیم بریم سراغ یه فناوری دیگه ( چیزیه که فعلا تو ایران رایجه ) و بگیم این فناوری بهتر نیست و خیلی بده و .....
چیزی که میخوام بگم اینه که بهتره زودتر شروع کنیم .... اون مطالبی رو که بلدیم رو بگیم .... بازم میگم شناخت مسیر خیلی مهمه ... به نظر من از spring یا EJB شروع به کالبد شکافی کنیم بهتره ...

mazdadoost
دوشنبه 13 مهر 1388, 22:01 عصر
با تشکر از همگی دوستانی که وقت گذاشتند و در این تاپیک شرکت کردند .خیلی خوشحالم که با استقبال دوستان مواجه شدم.
همونطور که فکر میکردم در کنار هم قرار دادن javaEE و Spring در کنار هم چالش هایی رو از نظر فنی در بین دوستان ایجاد کرده که دقیقا منظور نظرم بوده!! توجه کنید :

javaEE استاندارد رسمی سان برای جاوا در سطح سازمان هاست که هم پلت فرم و هم فریم ورک رو شامل میشه . در واقع مجموعه ای از فریم ورک ها که هر کدوم پیاده سازی یک SPC استاندارد رسمی سان و اعضاء JCP برای EE هست . مجموعه این فریم ورک ها در کنار و در تعامل یک پارچه با امکاناتی که به شکل مشترک برای همه این فریم روک ها در کاتینر javaEE به شکل JSR های خاص javaEE کانتینر تعریف شده پلت فرم javaEE رو تشکیل میدن . به عبارت کلی javaEE هم فریم ورک و هم پلت فرم استاندارد رو برای استفاده از یک پلت فرم پایه و کلیدی به اسم پلت فرم جاوا فراهم میاره . در قلب پلت فرم جاوا (javaSE) یک عنصر اختصاصی به اسم JVM قرار داره که هسته اجرایی تمامی بایت کد های استاندارد جاواست.

حالا قبل از اینکه به Spring بپردازم نظرتون رو به تعاریفی از Platform و Framework جلب می کنم :
1-Platform : قالب نرم افزاری برای اجرای برنامه ها .
(In computing (http://en.wikipedia.org/wiki/Computing), a platform describes some sort of hardware architecture (http://en.wikipedia.org/wiki/Hardware_architecture) or software framework (http://en.wikipedia.org/wiki/Software_framework) (including application frameworks (http://en.wikipedia.org/wiki/Application_framework)), that allows software (http://en.wikipedia.org/wiki/Computer_software) to run. Typical platforms include a computer's architecture (http://en.wikipedia.org/wiki/Computer_architecture), operating system (http://en.wikipedia.org/wiki/Operating_system), programming languages (http://en.wikipedia.org/wiki/Programming_language) and related runtime (http://en.wikipedia.org/wiki/Run_time_system) libraries or graphical user interface (http://en.wikipedia.org/wiki/Graphical_user_interface).) دقت کنید خود Platfom به لحاظ مفهومی تا حدی شامل بر Framework
هم میشه .
منبع (http://en.wikipedia.org/wiki/Platform_%28computing%29)


2-Framework : به شکل خلاصه : ایجاد قالبی برای توسعه برنامه ها بر اساس یک روش مشترک و متحد . البته به شکل دقیقتر در این جا بیان شده(عبارت من دقیقا با منبع همسانی نداره اما مطلب اصلی رو میرسون و در دنیای جاوا کاملا صادقه هر چند میتونه جامع و مانع نباشه) :
A software framework, in computer programming (http://en.wikipedia.org/wiki/Computer_programming), is an abstraction in which common code providing generic functionality can be selectively overridden or specialized by user code providing specific functionality. Frameworks are similar to software libraries (http://en.wikipedia.org/wiki/Software_library) in that they are reusable abstractions of code wrapped in a well-defined API (http://en.wikipedia.org/wiki/Application_programming_interface).
منبع (http://en.wikipedia.org/wiki/Software_framework)

خوب با این تعابیر می خوام این مسئله رو مطرح کنم که Spring هم مانند javaEE هم پلت فرم و هم فریم ورک رو شامل میشه . به عبارتی :

Spring یک استاندارد غیر رسمی برای پیاده سازی برنامه های سازمانی بر پایه پلت فرم جاوا را از طریق پلت فرم و فریم ورک فراهم می آورد .
پلت فرم زیرا : امکان اجرای کد های معمولی جاوا را (POJO) در محیطی Enterprise فراهم می کند از طریق IOC و AOP . با استفاده گسترده از امکانات javaSE به جای متکی بودن به Aplication Server لازم برای یک javaEE کانتینر کامل .
در این باره در ادامه توضیحات کاملتری ارائه می کنم .
فریم ورک زیرا : با ارائه چارچوبی همسان برای توسعه برنامه ها و ایجاد زیر ساخت های لازم برای تسهیل و تمرکز کار توسعه گران بر روی منطق کاری به جای چگونگی پیاده سازی عملکرد کاری .

خوب نتیجه من Spring و javaEE ور در مقابل هم به عنوان دو محوطه برای کار در محیط های Enterprise بر پایه جاوا می بینم که در بعضی موارد همپوشانی دارند در بعضی موارد کاملا متفاوت در بعضی موارد شبیه و در بعضی موارد بی ربط به هم هستند . به عبارتی من قلب هر کدوم از این ها رو تا اون جا که به خصوصیت پلت فرم بودنشون ربط داره ایجاد محیطی برای
ساخت :
کامپوننت های قابل استفاده مجدد در محیط های سازمانی میدونم . یعنی Ejb در مقابل IOCوAOP . در سایر موارد فریم ورک ها هستند که نقش لایه های بالاتر رو برای این کامپوننت ها بازی می کنند .

و همونطور که می دونید فرم ورک های زیادی هست که هر دو پلت فرم میتونند ازشون استفاده کنند .

در نتیجه من باب این مطلب رو با توجه به فرمایشات با ارزش دوستان این طوری بسط میدم :

1- مزایا و معایب Spring و javaEE به عنوان Platform های معماری سازمانی بر اساس جاوا نسبت به یکدیگر .
2- مزایا و معایب Spring و javaEE به عنوان Framework های معماری سازمانی بر اساس جاوا نسبت به یکدیگر .
3- چیز هایی که قرینه ای در یکی از این دو در دیگری وجود نداشته باشد . یا برعکس .
4-مزایای استفاده از javaEE به عنوان technical standard (http://en.wikipedia.org/wiki/Standard) یا De jure (http://en.wikipedia.org/wiki/De_jure) استاندارد در مقابل Spring به عنوان De facto (http://en.wikipedia.org/wiki/De_facto_standard) استاندارد .
5-جاهایی که هر یک از این ها به شکل بارزی بر دیگری برتری دارد . و اینکه این برتری چگونه در انتخابش در استفاده در یک پروژه موثر خواهد بود .

باز هم از دوستان تشکر میکنم و از نظراتشون کمال تشکر رو دارم.

javaphantom
چهارشنبه 15 مهر 1388, 09:25 صبح
spring
یک فریم ورک open source, popular
مبتنی بر xml البته توی 2.5 annotation هم اضافه کرده.

ejb
استاندارد
مبتنی بر annotation , xml

mazdadoost
پنج شنبه 16 مهر 1388, 03:17 صبح
spring
یک فریم ورک open source, popular
مبتنی بر xml البته توی 2.5 annotation هم اضافه کرده.

ejb
استاندارد
مبتنی بر annotation , xml
پس تقریبا یکسان هستن!

javaphantom
پنج شنبه 16 مهر 1388, 09:46 صبح
پس تقریبا یکسان هستن!

در مورد clustering شون چه نظری داره با در نظر گرفتن container قوی ejb

mazdadoost
پنج شنبه 16 مهر 1388, 12:06 عصر
javaphantom جان منظورت اگه در مورد قوی بودن کانتینر ejb کلاستر شدن باشه بنظرم جزء SPC نیست . این امکانیه که appserver ها در اختیار سیستم میذارن . درسته!؟ به نظرم قدرت قدرتی که در کانیتر EJB هست در اینه که بدون اینکه توسعه دهنده رو در گیر کنه به شکل به اصطلاح TRANPRANT منابع ejb ها رو در pool نگه داری میکنه . و این چیزی هست که در spring نیست . مثلا برای پیاده کردن Statfull Session ها در Spring باید بین ها رو با خصوصیت scope=prototype کانفیگ کرد . که این یعنی به ازائ هر درخواست یک نمونه جدید در کانتینر .من دقیقا نمی دونم که Spring چطور منابعش رو مدیریت میکنه .اما با توجه به حجم کم کانتیتر فکر مبکنم به GC جاوا تکیه میکنه .هرچند که یک baen factory کش شده هم داره که با ehcach پیاده سازی شده . اما در مورد ejb منابع کلا در pool قرار می گیرن که باعث میشه انواع ejb ها با قرار گرفتن در pool برای در خواست های مختلف دوباره استفاده بشن . به طور خلاصه :

1- کلاستر شدن نه برای Spring نه ejb به شکل استاندارد نیست . اما با توجه به اینکه appserver های ejb کلا برای کار های بزرگ طراحی شدن تقریبا همیشه با یک ماجول کلاسترینگ قوی ارائه میشند . البته این برای بعضی برنامه ها که بیشتر به availability و scalability نیاز دارن مفیده و شاید حجم زیادی از برنامه ها چنین چیزی رو نیاز ندارند و حتی در خیلی از برنامه های سازمانی حجم کمی از برنامه به این دو ویژگی نیاز داره . پس ماجول کلاسترینگ با حجم منابع مورد نیازش میتونه به عنوان یک عامل هزینه زا در نظر گرفته بشه . در دنیای Spring در حال حاضر اغلب به شکل بسیار کم هزینه تری از Terracotta استفاده میشه .

2- در مورد مدیریت منابع به نظرم جایی هست که کانتینر ejb با Statfull Session Bean ها در مقام بالاتری قرار داره چرا که برای مثال میتونه با 10 SFSB از پس 100 تا در خواست بر بیاد بدون اینکه به Ram بیشتری نیاز داشته باشه . اما Prototype های Spring با تجربه من اینقدر در مدیریت منابع شانس ندارند . هر چند میشه کش بشن . با این حال باز هم Terracottaمی تونه منابع رو برای Spring مدیریت کنه .منتها این ویژگی خود Spring نیست و باید برای رسیدن بهش تا حدی با Terracotta آشنایی داشت . اما در مورد Ejb ها این یک ویژگی آمادست که توسعه دهنده هیچ ارتباطی بهش نداره و سیستم ادمین باید صرفا pool ها رو تعریف کنه .

javaphantom
جمعه 17 مهر 1388, 10:38 صبح
می دونی mazdadoost عزیز من واقعا نمی تونم دقیق بهت بگم که کدوم بهتر یا بدتر همانطور که می بینی توی کار و تجربه کار هست که ضعفها و قوتها معلوم می شه. من تعصب خواصی روی هیچ کدوم از اینها ندارم شاید باورنکنی انقدر که الان کار عملیاتی با spring کردم با ejb اصلا نبوده یعنی می خوام بگم که نیاز تیم من با spring حل شده و واقعا به نظر من مهندسی یعنی همین که شما بتونید یک ابزار درست رو انتخاب کنی یا در صورت نبود اون رو بسازی.
spring خیلی کار رو راحت کرده و فقط کافی هست که شما مفهوم یا به عبارتی درد رو بشناسی و تشخیص بدی و بعد می بینی که چقدر آسون spring برات درمان می کنه.

ejb هزینش بالاست . تیم پشتیبانی و تیم مدیریت تیم assemble و develop و دیگر actorهای این قسمت باید واقعا خیلی دید حرفه و enterprise در ابعاد خیلی بالا و با business های خیلی پیچیده مثل بورس یا بانک درگیر باشند. و به عقیده من در صورتی که business های پیچیده و سنگین نداریم spring بهترین هست.

mazdadoost
جمعه 17 مهر 1388, 21:37 عصر
می دونی mazdadoost عزیز من واقعا نمی تونم دقیق بهت بگم که کدوم بهتر یا بدتر همانطور که می بینی توی کار و تجربه کار هست که ضعفها و قوتها معلوم می شه. من تعصب خواصی روی هیچ کدوم از اینها ندارم شاید باورنکنی انقدر که الان کار عملیاتی با spring کردم با ejb اصلا نبوده یعنی می خوام بگم که نیاز تیم من با spring حل شده و واقعا به نظر من مهندسی یعنی همین که شما بتونید یک ابزار درست رو انتخاب کنی یا در صورت نبود اون رو بسازی.
spring خیلی کار رو راحت کرده و فقط کافی هست که شما مفهوم یا به عبارتی درد رو بشناسی و تشخیص بدی و بعد می بینی که چقدر آسون spring برات درمان می کنه.

ejb هزینش بالاست . تیم پشتیبانی و تیم مدیریت تیم assemble و develop و دیگر actorهای این قسمت باید واقعا خیلی دید حرفه و enterprise در ابعاد خیلی بالا و با business های خیلی پیچیده مثل بورس یا بانک درگیر باشند. و به عقیده من در صورتی که business های پیچیده و سنگین نداریم spring بهترین هست.

کاملا موافقم .و همونطور که گفتی باید دید چرا و چجوری. اگه همینطور سازنده به این تاپیک ادامه بدیم مطمئنا یک منبع درجه یک برای این مطلب در فضای زبان فارسی برای این دو میشه.

shahryary
جمعه 17 مهر 1388, 22:37 عصر
یعنی به نظرتون ejbرو باید در پروژه های سطح بالا نوشت ؟
و فعلا این فریم وورک spring هستش که نسبت به سایر فریم وورک ها برتری داره ( هزینه و پیاده سازی و .. ) ...
میتونیم درمورد معماری spring صحبت کنیم ؟ همونطور که میدونین spring هم برای .net هست و هم برای java به نظرتون تو چه سطحی این دو با هم فرق میکنن ...
همون معماری که واسه جاوا درست کردن آیا واسه .net هم اینجوریه یا نه .... به سبک دیگه ایه ...

mazdadoost
شنبه 18 مهر 1388, 08:57 صبح
یعنی به نظرتون ejbرو باید در پروژه های سطح بالا نوشت ؟
و فعلا این فریم وورک spring هستش که نسبت به سایر فریم وورک ها برتری داره ( هزینه و پیاده سازی و .. ) ...
میتونیم درمورد معماری spring صحبت کنیم ؟ همونطور که میدونین spring هم برای .net هست و هم برای java به نظرتون تو چه سطحی این دو با هم فرق میکنن ...
همون معماری که واسه جاوا درست کردن آیا واسه .net هم اینجوریه یا نه .... به سبک دیگه ایه ...
دوست عزیز در مورد سوالاتی که مطرح کردین :
1- منظورتون رو از سطح بالا بیان کنید . چون به نظرم شفافیت کافی نداره .
2-در مورد معماری Spring هم صحبت خواهد شد .
3-این تاپیک برای مقایسه Spring for java و Spring .net نیست.
موفق باشید.

mazdadoost
شنبه 18 مهر 1388, 10:13 صبح
شما می تونید POJOهای موجود در spring رو به EJB تبدیل کنید!


دوست عزیز می تونید منظورتون رو واضح تر بیان کنید؟
با تشکر.

cups_of_java
شنبه 18 مهر 1388, 10:43 صبح
EJB ها کلن موجودیت های سنگین و پر هزینه ای برای کانتینر ها هستند. چه از نظر ایجاد و حذف - چه از نظر کنترل و هندل هایی که به Context و بقیه اشیای داخل کانتیر باید داشته باشن - چه از دید Activation و Passivation - چه برای اعمال RMI و Distributionو... از همین منظر اعمال مکانیزم Pooling ضروری هستش. کامنتر نمی تونه اشیای درشت دانه رو بسته به درخواست کاربر On Demand ایجاد کنه!
اما در نقطه مقابل در Spring چیزی نداریم جز POJO و اینها ریز دانه و اشیایی کم هزینه هستند. بنابراین می تونن On the fly برای کاربر ایجاد بشن. درسته که در Spring ما Introspection داریم و این هزینه بر هست و حتی چرخه حیات اشیا کنترل می شه توسط Spring اما این مسایل در مقایسه با EJB در کانتینر ها مقیاس کوچکتری داره.

نکته دیگه اینکه prototypeها در Spring برای مواردی استفاده می شن که شما منطق Stateful میخواین (مثل Stateful Session EJBها) و مشخصن اینجا pooling دیگه اون معنی ای که در Stateless ها داره رو نداره!!! و اصلن prototype بودنشون حکمتشون اینه که ریز دانه و زیاد باشن و بسته به درخواست استفاده شن. حالا فکر کنم بشه یه pooling درست و حسابی کنارش چسبوند که خدارو هم خوش بیاد!

می خوام بگم که نمی شه به این راحتی Pooling رو پیش کشید و ایندو فریم ورک رو مقایسه کرد با هم (توجه کنید شما دارید POJO رو با یک شی Container Based مقایسه می کنید) . باز هم می گم جایی که شما Distribution of service داری و جایی که clustering می خوای و Transaction support توصیفی می خوای سمت EJB میری ولی در غیر این صورت این کار بی معنی خواهد بود. Spring به راحتی پاسخ اکثر نیاز های شما رو می ده. (مگر اینکه شما مجبور باشی نرم افزارت رو در یک محیط با معماری استاندارد در کنار نرم افزار دیگران در دل یک container استاندارد نصب کنی! در این صورت Java EE اسنتخاب بهتریه.


ضمنن! اصولن به ما یاد دادن که (الگوهای Java EE رو ببینید) منطق و business شما می ره تو EJB ها! من بعد از سال ها کار و مطالعه یاد گرفتم که این هم می تونه غلط باشه! سیستم هایی می تونن طراحی بشن که (در حالت ایده آل) منطق شما در POJOها قرار داره و این البته کار Domain Modeling و کد قسمت های منطق برنامه رو خیلی ساده و روان می کنه. بعد این منطق رو با سرویس یا تکنولوژی و یا نیاز های غیر وظیف مندی (مثل concurrency - distribution - transaction - ...)‌که می تونن همون EJBها باشن wrap می کنیم. نمی دونم اون دیدی که می خواستم رو تونستم انتقال بدم یا نه!؟

cups_of_java
شنبه 18 مهر 1388, 10:48 صبح
دوست عزیز می تونید منظورتون رو واضح تر بیان کنید؟
با تشکر.

http://static.springsource.org/spring/docs/2.5.6/reference/ejb.html

mazdadoost
شنبه 18 مهر 1388, 11:34 صبح
EJB ها کلن موجودیت های سنگین و پر هزینه ای برای کانتینر ها هستند. چه از نظر ایجاد و حذف - چه از نظر کنترل و هندل هایی که به Context و بقیه اشیای داخل کانتیر باید داشته باشن - چه از دید Activation و Passivation - چه برای اعمال RMI و Distributionو... از همین منظر اعمال مکانیزم Pooling ضروری هستش. کامنتر نمی تونه اشیای درشت دانه رو بسته به درخواست کاربر On Demand ایجاد کنه!
اما در نقطه مقابل در Spring چیزی نداریم جز POJO و اینها ریز دانه و اشیایی کم هزینه هستند. بنابراین می تونن On the fly برای کاربر ایجاد بشن. درسته که در Spring ما Introspection داریم و این هزینه بر هست و حتی چرخه حیات اشیا کنترل می شه توسط Spring اما این مسایل در مقایسه با EJB در کانتینر ها مقیاس کوچکتری داره.

نکته دیگه اینکه prototypeها در Spring برای مواردی استفاده می شن که شما منطق Stateful میخواین (مثل Stateful Session EJBها) و مشخصن اینجا pooling دیگه اون معنی ای که در Stateless ها داره رو نداره!!! و اصلن prototype بودنشون حکمتشون اینه که ریز دانه و زیاد باشن و بسته به درخواست استفاده شن. حالا فکر کنم بشه یه pooling درست و حسابی کنارش چسبوند که خدارو هم خوش بیاد!

می خوام بگم که نمی شه به این راحتی Pooling رو پیش کشید و ایندو فریم ورک رو مقایسه کرد با هم (توجه کنید شما دارید POJO رو با یک شی Container Based مقایسه می کنید) . باز هم می گم جایی که شما Distribution of service داری و جایی که clustering می خوای و Transaction support توصیفی می خوای سمت EJB میری ولی در غیر این صورت این کار بی معنی خواهد بود. Spring به راحتی پاسخ اکثر نیاز های شما رو می ده. (مگر اینکه شما مجبور باشی نرم افزارت رو در یک محیط با معماری استاندارد در کنار نرم افزار دیگران در دل یک container استاندارد نصب کنی! در این صورت Java EE اسنتخاب بهتریه.


ضمنن! اصولن به ما یاد دادن که (الگوهای Java EE رو ببینید) منطق و business شما می ره تو EJB ها! من بعد از سال ها کار و مطالعه یاد گرفتم که این هم می تونه غلط باشه! سیستم هایی می تونن طراحی بشن که (در حالت ایده آل) منطق شما در POJOها قرار داره و این البته کار Domain Modeling و کد قسمت های منطق برنامه رو خیلی ساده و روان می کنه. بعد این منطق رو با سرویس یا تکنولوژی و یا نیاز های غیر وظیف مندی (مثل concurrency - distribution - transaction - ...)‌که می تونن همون EJBها باشن wrap می کنیم. نمی دونم اون دیدی که می خواستم رو تونستم انتقال بدم یا نه!؟
خوبه !
پس تا الان تقریبا میشه به این نتیجه گیری رسید که در مقام کانتینر Ejb یک کانتیر heavy weight و Spring یک کانتیر light weight هست . سوال این جاست که آیا سبک وزن بودن و سنگین وزن بودن یک کانتینر ربطی به نیاز های پروژه ما داره یا خیر ؟ به عبارتی در مورد یک پروژه با نیاز هایی مثل مثال javaphantom عزیز در مورد بانکینگ و بورس و از این قبیل میشه گفت چون Ejb سنگین وزنه پس باید برای توسعه این پروژه های به اصطلاح سنگین بهکار برده شه !؟ یعنی :آیا تناظری یک به یک بین heavy weight و پروژه های به اصطلاح سنگین (این پروژه های سنگین باید معنی بشه!) وجود داره ؟ به نظر من این صرفا نوعی بد فهمی هست و شاید ریشه بسیاری از بزرگ پنداری ها در مورد ejb در javaEE همین مطلب باشه. و الزاما این مطلب صادق نیست.

یک مسئله دیگه مقایسه pojo های Spring با Ejb هاست که به نظرم درسته . چون هردو کانتیر هایی برای مدیریت کامپوننت ها هستند . و تقریبا تمامی کسانی که از Spring استفاده می کنند به این مطلب رسیدن که SFSB های Ejb کارایی بهتری از prototype های Spring در یک محیط توزیع شده دارند. توجه کنید در یک محیط توزیع شده. مثال معروف Shopping Cart رو در نظر بگیرید : در محیط های توزیع شده با هزاران کاربر حجم رم مورد نیاز برای این همه اشیاء واقعا سرسام آور خواهد شد . Spring در حالت معمول برای تامین منابع prototype هاش به gc نیاز داره . و ممکنه با out of memory مواجه بشه . اما pooling در ejb تضمین میکنه که حتی با وجود latency بالا با چنین مشکلی مواجه نشه . و این خیلی مهمه . تکنیک های pooling در ejb کانتیر ها خیلی کارا و اختصاصی هستند و بهتر از gc و jvm برای مدیریت شون مستقیما با بهنیه ترین تکنیک های معماری cpu و محلی پیاده می شند .


ضمنن! اصولن به ما یاد دادن که (الگوهای Java EE رو ببینید) منطق و business شما می ره تو EJB ها! من بعد از سال ها کار و مطالعه یاد گرفتم که این هم می تونه غلط باشه! سیستم هایی می تونن طراحی بشن که (در حالت ایده آل) منطق شما در POJOها قرار داره و این البته کار Domain Modeling و کد قسمت های منطق برنامه رو خیلی ساده و روان می کنه. بعد این منطق رو با سرویس یا تکنولوژی و یا نیاز های غیر وظیف مندی (مثل concurrency - distribution - transaction - ...)‌که می تونن همون EJBها باشن wrap می کنیم. نمی دونم اون دیدی که می خواستم رو تونستم انتقال بدم یا نه!؟در واقع منظورتون ابنه که از ejb به عنوان Service layer برای concurrency - distribution - transaction استفاده بشه؟ خوب پس امکانات خود Spring رو استفاده نکنیم؟

در مورد اینکه میشه در Spring با Pojo ها Ejbساخت منظورتون همینه؟ به نظرم این نمیتونه اسمش Ejb باشه. تا اونجایی که من اطلاع دارم در Spring میشه ejb های 2.x رو هم expose کرد هم access .
(البته نه با امکانات یک ejb کانتینر!)
اما 3.x رو فقط میشه access داشت.

mazdadoost
جمعه 01 آبان 1388, 21:32 عصر
:چشمک: LOOK AT THIS

javaphantom
شنبه 02 آبان 1388, 20:38 عصر
mazdadoost عزیز واقعیت اینکه وقتی JPA اومد و با خودش toplink رو آورد خیلی وقت قبل از اون hibernate خیلی خوب و با دید خیلی باز حرکت کرده بود. می شه گفت سان خوشش اومد و toplink رو وارد کار کرد و JPA یا همون java persistence API رو وارد کار کرد. به عبارت ساده تر کپی کرد. اما خوب از اونجایی که من شخصا با toplink کار کردم و شاهد باگ یا حتی ضعفهایی از اون بودم دوباره به سمت hibernate بر گشتم چی نگزشت که toplink نیست شد یک جورایی و جاش eclipselink اومد و به همراه اون داره JPA 2 می یاد توی j2ee 6
یک مثال دیگه JSF خوب کلی فریم ورک دیگه کنارش اومدن و کمکش کردن. مثل seam مثل rich faces یا ice faces ووو ضعف داشت خیلی ها اصلا سراغشم نرفتن ولی استاندارد بود و پیشنهادی سان.
خوب بد نیست به JSF 2 یک نگاهی بکنیم و ببینم چقدر پیش رفت کرده در j2ee6

بریم سراغ ejb و spring. کاملا درست است در قسمت handle کردن transaction ها spring خیلی دیده وسیع و ابزاری مناسب هست. و ejb یکم خنگه.
من همه داستانهای بالا رو تعریف کردم که بگم این استانداردی که صحبتش هست از رو هوا نیست بلکه 100% فکر پشتشه یا اصلا بهتر بگم کپی هست.
من اعتقادم اینکه که تکنولوژی های استاندارد سان درست که چندگام عقب هست نسبت به دیگر محصولات و شایدم همراه با ضعف اما تبادل این اطلاعات و یا همون interactive بودن این شرکتها باهم داره کمک می کنه که تکنولوژی های سان کامل و کاملتر بشه و من خیلی به این مسئله عقیده دارم که سان به کمک پول oracle و شهرت اون خیلی سریعتر از قبل خودشو به حد مطلوب می رسونه.

ولی واقعیت من بیشتر از این مسئله لذت می برم که در قسمت نرم افزارهای enterprise پلت فرم java انقدر قوی هست و دست آدم رو باز می زاره که بتونه بهترین راه حل رو انتخاب کنه من خودم واقعا به spring ارادت خاصی دارم.

بحث رو می برم سراغ JMS یا همون java message service و نظر دوستان در مورد پیاده سازی jms از طریق فریم ورک Spring چه در قسمت مدیریت و راه اندازی یک broker و چه در قسمت client بدونم.؟

mazdadoost
شنبه 02 آبان 1388, 21:49 عصر
mazdadoost عزیز واقعیت اینکه وقتی JPA اومد و با خودش toplink رو آورد خیلی وقت قبل از اون hibernate خیلی خوب و با دید خیلی باز حرکت کرده بود. می شه گفت سان خوشش اومد و toplink رو وارد کار کرد و JPA یا همون java persistence API رو وارد کار کرد. به عبارت ساده تر کپی کرد. اما خوب از اونجایی که من شخصا با toplink کار کردم و شاهد باگ یا حتی ضعفهایی از اون بودم دوباره به سمت hibernate بر گشتم چی نگزشت که toplink نیست شد یک جورایی و جاش eclipselink اومد و به همراه اون داره JPA 2 می یاد توی j2ee 6
یک مثال دیگه JSF خوب کلی فریم ورک دیگه کنارش اومدن و کمکش کردن. مثل seam مثل rich faces یا ice faces ووو ضعف داشت خیلی ها اصلا سراغشم نرفتن ولی استاندارد بود و پیشنهادی سان.
خوب بد نیست به JSF 2 یک نگاهی بکنیم و ببینم چقدر پیش رفت کرده در j2ee6

بریم سراغ ejb و spring. کاملا درست است در قسمت handle کردن transaction ها spring خیلی دیده وسیع و ابزاری مناسب هست. و ejb یکم خنگه.
من همه داستانهای بالا رو تعریف کردم که بگم این استانداردی که صحبتش هست از رو هوا نیست بلکه 100% فکر پشتشه یا اصلا بهتر بگم کپی هست.
من اعتقادم اینکه که تکنولوژی های استاندارد سان درست که چندگام عقب هست نسبت به دیگر محصولات و شایدم همراه با ضعف اما تبادل این اطلاعات و یا همون interactive بودن این شرکتها باهم داره کمک می کنه که تکنولوژی های سان کامل و کاملتر بشه و من خیلی به این مسئله عقیده دارم که سان به کمک پول oracle و شهرت اون خیلی سریعتر از قبل خودشو به حد مطلوب می رسونه.

ولی واقعیت من بیشتر از این مسئله لذت می برم که در قسمت نرم افزارهای enterprise پلت فرم java انقدر قوی هست و دست آدم رو باز می زاره که بتونه بهترین راه حل رو انتخاب کنه من خودم واقعا به spring ارادت خاصی دارم.

بحث رو می برم سراغ JMS یا همون java message service و نظر دوستان در مورد پیاده سازی jms از طریق فریم ورک Spring چه در قسمت مدیریت و راه اندازی یک broker و چه در قسمت client بدونم.؟
دوست عزیز javaphantom :
حقیقتا نکته کلیدی مهمی که میشد از بحث در مورد تنوع فریم ورک های جاوا و مخصوصا javaEE می شه بهش اشاره کرد و من هم کاملا بهش معتقدم ودر پست های دیگه هم در این موضوع بهش اشاره کردم رو بهش اشاره کردی :در قسمت نرم افزارهای enterprise پلت فرم java انقدر قوی هست و دست آدم رو باز می زاره که بتونه بهترین راه حل رو انتخاب کنه!
در مورد استاندارد های سان هم حق با شماست . در موارد بسیار زیادی حق مطلب ادا شده . تقریبا تمامی jsr های javaEE همین الان هم کاملا جواب گوی نیاز جامعه سازمانی هست . برای مثال من به شخصه برای وب کانتینر استانداردی جامع تر و کامل تر از Servlet ها ندیدم و سراغ ندارم! در استاندارد های سان علاوه بر امکانات جدید لزوم پشتیبانی از امکانات قدیم به ما اطمینان میده که نگران عدم سازگاری نباشیم.
مسئله اینجاست که در مواردی دیر به فکر ابتکاراتی افتادن که میتونسته برای جامعه هدف یعنی و جنابعالی مهم باشه. یکیش کم شدن زمان توسعه و به تبع هزینه های توسعه و نگهداری هست .
البته اینطور نیست که استاندارد های سان همیشه سخت و پیچیده هستند . مثلا jpa احتمالا برای سادگی از بعضی خصوصیات پیشرفته که Hibernate داره بی بهرست .
یا از اون طرف تراکنش های Spring اگر بر اساس aop باشند قابلیت توزیع پذیری ندارند ولی تراکنش های javaEE این امکان رو دارند مگر اینکه Spring هم از این نوع تراکنش برای مدیریت تراکنش هاش استفاده کنه . کلا مسلمه که استاندارد های سان رو هوا نیست (( حتی من پیشبینی میکنم به اومدن javaEE6 اونقدر Spring و javaEE به هم گره بخورند که به مرور از Spring فقط به جای Service layer استفاده بشه و امکانات javaEE رو به مرور Spring رو به ابزاری برای توسعه jsf-jpa-ejb3 به جای beans-hibernate-Spring MVC پیش ببره . البته همونطور که گفتم دسته توسعه دهنده واقعا بازه .)).
در واقع یکی از ویژه گی های جذاب Spring در مقابل javaEE همین تنوع در استفاده از موارد مختلف هست . شما برای Orm می تونید از iBiats -Hibernate-Toplink-jpa وووو استفاده کنید (( بدون اینکه data layer تون با دیتا پروایدر و بیزنش لاجیکتون مخلوط شه )) اما در javaEE میتونید فقط از jpa استفاده کنید . حالا با هر Implementation یی. این مسئله برای web mvc-massaging - soa و کلا هر فناوری دیگری در سازمان ها برای Spring و javaEE صادقه .

خوب کافیه . منم بات موافقم بریم سمت پیاده سازی . برای شروع اگر امکان داره براتون و وقت دارید مراحل کار رو برای یک محیط jms در javaEE و یک appserver انتخابی خودتون توضح بفرمایید تا بنده هم نمونه spring ش رو بذارم .
ممنون . موفق باشید.

javaphantom
یک شنبه 03 آبان 1388, 20:44 عصر
یعنی منظورت اینکه در مورد JMS بشینم توضیح بدم؟

mazdadoost
یک شنبه 03 آبان 1388, 21:32 عصر
یعنی منظورت اینکه در مورد JMS بشینم توضیح بدم؟
ببین فرض کن یه broker داری تو glassfish.از کوتاه ترین روش ممکن یه شی با این مشخصات رو از طریق یک queue بین کلاینت و سرور مبادله کن.
mail{
string massage;
int id;
}
یه مثال رو تشریح کن تا من هم معدل Spring ش رو بذارم .
موفق باشی.(البته اگه خواستی .)

javaphantom
دوشنبه 04 آبان 1388, 20:18 عصر
اول از همه تبریک برای مدیریت بخش رو بهت می گم.

اما خوب همه چیز رو خودت طرح کردی. من توی قسمت client نمی خوام اول وارد بشم.

بحث من در قسمت admin و همون broker هست و کلا config کردن این قسمت.

گفتی glassfish خوب بد نگفتی ولی اگر اجازه بدی بزار برای اینکه این ابهام هم برای من رفع بشه بیاییم از یک messenger service مستقل از هر web application ی صحبت کنیم.

برای مثال من می خوام Open Message Queue استفاده کنم.

سوال آیا می تونم از طریق فریم ورک spring بعنوان یک واسط هم در قسمت admin و هم در قسمت client استفاده کنم.؟

البته این رو خوب می دونم که از طرف clinet باید ok باشه. ا

راحترین و بهترین message service از نظر شما یا هر کی که قبلا کار کرده چیه.
نکته : نمی خوام web application رو مداخله بدم.

با تشکر

mazdadoost
سه شنبه 05 آبان 1388, 17:04 عصر
اول از همه تبریک برای مدیریت بخش رو بهت می گم.

اما خوب همه چیز رو خودت طرح کردی. من توی قسمت client نمی خوام اول وارد بشم.

بحث من در قسمت admin و همون broker هست و کلا config کردن این قسمت.

گفتی glassfish خوب بد نگفتی ولی اگر اجازه بدی بزار برای اینکه این ابهام هم برای من رفع بشه بیاییم از یک messenger service مستقل از هر web application ی صحبت کنیم.

برای مثال من می خوام Open Message Queue استفاده کنم.

سوال آیا می تونم از طریق فریم ورک spring بعنوان یک واسط هم در قسمت admin و هم در قسمت client استفاده کنم.؟

البته این رو خوب می دونم که از طرف clinet باید ok باشه. ا

راحترین و بهترین message service از نظر شما یا هر کی که قبلا کار کرده چیه.
نکته : نمی خوام web application رو مداخله بدم.

با تشکر

ممنون لطف داری.این نیز بگذرد.
می دونی آخه اگه بخوایم javaee رو با spring مقایسه کنیم در قسمت jms و broker کانتینر javaee با بروکر اراءه میشه و با همند!نه؟
اما خوب اینطوری هم که شما گفتی میشه.
به نظر من http://activemq.apache.org/ عالیه .خودم باش کار کردم و حرف نداره! سریع-اسان مطمئن!
موافقی با این ادامه بدم؟
آره در Spring میشه هم jms رو را بندازیم و هم باقی قضایا !البته http://activemq.apache.org/ با یه namespace اختصاصی اراعه میشه که میتونیم کل کانفیگش رو با spring یک پارچه کنیم.

javaphantom
سه شنبه 05 آبان 1388, 21:23 عصر
ممنون لطف داری.این نیز بگذرد.
می دونی آخه اگه بخوایم javaee رو با spring مقایسه کنیم در قسمت jms و broker کانتینر javaee با بروکر اراءه میشه و با همند!نه؟
اما خوب اینطوری هم که شما گفتی میشه.
به نظر من http://activemq.apache.org/ عالیه .خودم باش کار کردم و حرف نداره! سریع-اسان مطمئن!
موافقی با این ادامه بدم؟
آره در Spring میشه هم jms رو را بندازیم و هم باقی قضایا !البته http://activemq.apache.org/ با یه namespace اختصاصی اراعه میشه که میتونیم کل کانفیگش رو با spring یک پارچه کنیم.

apache رو هستم باهات راستش قبلا هم پیشنهاد شده بود ولی ما تصیمیم گرفتیم بریم سراغ سان ولی اگر شما می گی با spring خوب جواب می ده میریم سراغش ممنون از راهنماییی

mazdadoost
چهارشنبه 06 آبان 1388, 10:38 صبح
apache رو هستم باهات راستش قبلا هم پیشنهاد شده بود ولی ما تصیمیم گرفتیم بریم سراغ سان ولی اگر شما می گی با spring خوب جواب می ده میریم سراغش ممنون از راهنماییی
خوبه در اسرع وقت:لبخندساده:.قابلی نداره.

mazdadoost
شنبه 09 آبان 1388, 23:56 عصر
خوب همونطور که گفتم در این POST به یک محیط JMS نوعی در SPRING رسیدگی میشه!
فرض بر اینه که خواننده با JMS آشنایی داره.
1-ACTIVEMQ رو از اینجا دانلود کنید.
http://www.apache.org/dyn/closer.cgi/activemq/apache-activemq/5.3.0/apache-activemq-5.3.0-bin.zip
2-در این مرحله دو راه برای اجرا و کانفیگ ACTIVEMQ داریم :


اجرای جداگانه BROKER با اجرای BIN/ACTIVEMQ.BAT/SHL که این MASSAGE BROKER رو با تنظیمات اولیه بالا میاره.

در این مرحله کافیه MASSAGE BROKER رو به SPRING معرفی کنیم:


<bean id="jmsFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL">
<value>tcp://localhost:61616</value>
</property>
</bean>



با SPRING کل ADMIN رو به شکل زیر انجام بدیم :


<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:amq="http://activemq.apache.org/schema/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd">

<!-- lets create an embedded ActiveMQ Broker -->
<amq:broker useJmx="false" persistent="false">
<amq:transportConnectors>
<amq:transportConnector uri="tcp://localhost:0" />
</amq:transportConnectors>
</amq:broker>

<!-- ActiveMQ destinations to use -->
<amq:queue id="destination" physicalName="org.apache.activemq.spring.Test.spring.embedded"/>

<!-- JMS ConnectionFactory to use, configuring the embedded broker using XML -->
<amq:connectionFactory id="jmsFactory" brokerURL="vm://localhost"/>

در این قسمت یک JMSTEMPLATE ساخته شده .این کلاس کلی کد های JMS رو کم میکنه!
<!-- Spring JMS Template -->
<bean id="myJmsTemplate" class="org.springframework.jms.core.JmsTemplate">
<property name="connectionFactory">
این POOLING خیلی مهمه اینجا!
<!-- lets wrap in a pool to avoid creating a connection per send -->
<bean class="org.springframework.jms.connection.SingleConnectio nFactory">
<property name="targetConnectionFactory">
<ref local="jmsFactory" />
</property>
</bean>
</property>
</bean>

<bean id="consumerJmsTemplate" class="org.springframework.jms.core.JmsTemplate">
<property name="connectionFactory" ref="jmsFactory"/>
</bean>

<!-- a sample POJO which uses a Spring JmsTemplate -->
<bean id="producer" class="org.apache.activemq.spring.SpringProducer">
<property name="template">
<ref bean="myJmsTemplate"></ref>
</property>

<property name="destination">
<ref bean="destination" />
</property>

<property name="messageCount">
<value>10</value>
</property>
</bean>

<!-- a sample POJO consumer -->

<bean id="jmsProducerConnectionFactory"
class="org.springframework.jms.connection.SingleConnectio nFactory"
depends-on="broker"
p:targetConnectionFactory-ref="jmsFactory" />

<bean id="jmsProducerTemplate" class="org.springframework.jms.core.JmsTemplate"
p:connectionFactory-ref="jmsProducerConnectionFactory"
p:defaultDestination-ref="destination" />

</beans>
یا EMBDED:


<bean id="broker" class="org.apache.activemq.xbean.BrokerFactoryBean">
<property name="config" value="classpath:org/activemq/xbean/activemq.xml" />
<property name="start" value="true" />
</bean>

باقی ماجرا رو هم مبتونبد اینجا دنبال کنید.:
http://activemq.apache.org/spring-support.html

javaphantom
سه شنبه 12 آبان 1388, 20:48 عصر
سلام من یک مدتی بود که گرفتار بودم و نتونستم بیام ولی الان که اومدم بسیار خوشحال شدم که این مثال رو دیدم.
خیلی ممنون و تشکر می کنم از وقتی که گذاشتیت