PDA

View Full Version : مقاله: مروری بر Java EE 6 !آنچه انتظار داریم.



mazdadoost
دوشنبه 13 خرداد 1387, 11:28 صبح
با سلام .

مروری اجمالی بر JSR 316: JavaTM Platform, Enterprise Edition 6 (Java EE 6) Specification!
همونطور که از عنوان این JSR برمیاد فرایند برنامه ریزی برای امکانات و موارد جدید و توسعه پلت فرم JavaEE ورژن 6 رو پوشش خواهد داد.
به طور خلاصه اهداف و برنامه های کلی این JSR به قرار زیر می باشد :

1-Extensibility :قابلیت توسعه.
چنانچه با پلت فرم EE اشنایی داشته باشید میدونید در جای جای این پلت فرم علاوه بر موارد استاندارد رسمی که به عنوان ملزومات پیاده سازی JSR های EE 5 مثل EJB3-JPA-JAAC-JSF و و و در پلت فرم موجود هست موارد بسار بیشتری به عنوان استاندارد غیر رسمی مثل Struts-Tapstry-Spring-Hibernate- و .....در جامعه اپن سورس و حتی تجاری موجوده که تا حدود بسار زیادی از نظر کاربرد و عملکرد با استاردهای خود EE همپوشانی دارند.توسعه دهندگان برای بهره برداری از این موارد مختلف مجبورند مقدار بسیار زیادی از انواع پبکربندی (XML-Annonations) رو یاد بگیرند به علاوه اینکه چطور این های رو به شکل یکپارچه ای در AppServer در کنار هم Deploy کنند.با استفاده از Extensibility مکانیزمی واحد برای Plug کردن انواع این راح حل ها به عنوان جایگزین برای معادل های استانداردشون در EE فراهم میشه.که پیکربندی و یکپارچه سازی رو برای برنامه نویسان بسیار راحت تر و دوره آموزش رو کوتاه تر خواهد کرد.
2-Profiles:با پروفایل ها این امکان برای توسعه دهندگان EE فرهم میاد که به جای توسعه کامل کل JSR ها در EE مورد نظرشون فقط یک زیر مجموعه از اون های رو بنا بر نیاز های مورد نظر توسعه دهندگان فراهم بیارند.در واقع سیاست همه یا هیج در پیاده سازی EE تا جد زیادی بردداشته میشه.و مقدار زیادی از امکانات کنونی EE طوری در قسمت های مختلفی تحت Profiles قرار داده میشند تا از همراه کردن قسمت های بی استفاده برای مثلا سازمانی وقتی توسعه دهنده می خواد فقط یه سایت وب دینامیک داشته باشه جلوگیری بشه.اولین پروفایل هم Java EE Web Profile خواهد بود که شامل پیاده سازی JSR هایی برای توسعه وب خواهد بود.
3-Pruning :هرس کردن!
در طی مدت زمانی که از ایجاد EE می گذره مقدار زیادی API در این پلت فرم عظیم قرار گرفته.هدف برنامه ریزان EE 6 از حرص کردن اختیاری کردن بعضی از این API ها ست.مخصوصا اونهایی که بر اثر همپوشانی امکانات و اومدن API های ساده تر کمی قدیمی شدن.
EJB CMP - effectively replaced by Java Persistence
JAX-RPC - effectively replaced by JAX-WS
همونطور که میبینید قراره JPA جای CMP ها و JAX-WS هم جای RPC استایل وب سرویس ها رو بگیرند.
4-SOA:معماری سرویس گرا در حال حاضر به شکل خوبی در EE 5 پشتیبانی میشه.با این وجود پیشرفت هر روزه استاندارد های جدید در این زمینه مثلا استفاده روز افزون از وب سرویس های REST به جای SOAP و پیاده سازی نسبتا سخت REST در EE5 باعث شده تا تمهیدات ویژه ای برای پشتیبانی هر چه کاملتر در زمینه آخرین فناوری های وب سرویس در EE6 به عمل بیاد.

5-سایر ویژگی ها:

JSR-196 Java Authentication SPI for Containers
JSR-236 Timer for Application Servers
JSR-237 Work Manager for Application Servers
JSR-299 Web Beans
JSR-311 JAX-RS: Java API for RESTful Web Services

(در مورد این JSR ها در ادامه صحبت می کنم)

بیداری برای ...
شعاری که در باره جاوا EE6 هست : موج آینده!فلسفه ای که در پشت ویرایش بعدی EE هست برای همگی توسعه دهندگان EE اغوا کننده و تا حد زیادی هیجان انگیز هست.خلاصه اهداف EE 6 رو میشه در سه قسمت گذاشت:
1-Rightsizing:به اندازه کردن.که در بر گیرنده پروفایل ها و حزص کردن میشه
2-Ease OF Development:ساده کردن توسعه .چیزی که در EE 5 با Annonation بیس کردن بسیاری از جنبه های EE مثل پیکربندی و تعریف EJB-JMS-JPA و کم کردن وابستگی به XML کانفیگ بهبود پیدا کرده و قراره در EE6 به پختگی بیشتری برسه!
3-قابلیت توسعه.

بیایید بحث رو دز این باره شروع کنیم که این سه انگیزه به چه نحو می تونه برای استفاده کنندگان نهایی یعنی توسعه دهندگان و کاربران نهایی برنامه های ساخته شده با EE مفید فایده باشه.

گزینه اول :بهبود اندازه های EE با پرو فایل ها و حرص کردن بخش های موجود !پروفایل ها قبلا در javaME بودن!با ورودشون به EE و اولین پروفایل رسمی یعنی WEB پروفایل باید انتظار چه مسائلی رو داشته باشیم؟آیا این چیز جدیدی خواهد بود؟تکه تکه کردن API و گذاشتن در قسمت های مختلف.مثلا در WEB پروفایل قراره مثلا امکانات EJB یا JMS با EE همراه نباشند!ولی Servlet و JSF باشند!این ایده همین الان هم داره ایتفاده میشه!Servlet Container
در حالت جدید فقط JSF به صورت استاندارد با وب پروفایل خواهد بود.شاید این یعنی ما شاهد ظهور Tomcat با عنوان جدید Tomcat EE server web profile خواهیم بود!یعنی Tomcat=JSF+JPA+SERVLET3+WEB Beans!این آخری Web Beans چیز بسیار جالبیه .در نهایت با وجود اینکه اکثر این امکانات الان هم هستن وقابل استفاده اما نمی شه به نکته ای که ظاهرا برنامه ریزان EE6 متوجهش شدن توجه نکرد:استاندارد سازی رسمی استاندارد های غیر رسمی!!منظورم اینه که وقتی قرار ما از JSF و JPA در Tomcat استفاده کنیم چرا نباید به شکل استاندارد ازشون در و مطابق با تائئد سان در Tomcat استفاده کنیم.این شکل از انتشار در EE به توسعه دهندگان Tomcat اجازه میده به شکل استاندارد زیر سایه EE قرار بگیرند. والبته Jetty و Coacho!این یعنی در یک کتاب جاوا,دوره آموزشی جاوا و هر منبع دیگری استفاده و پیکربندی مواردی مثل JSF -JPA و و در همه App server ها چه اونهایی که بزرگند مثل IBM WebS و اراکل چه اونهایی که کوچکترند مثل Tomcat همه چیز حد اقل کاملا شفاف و یکدست خواهد بود!این یکپارچگی احتمالا منجر به حل یک مشکل دیگر هم خواهد شد:یکسان شدن راههای بهینه کردن کارایی در EE!(در این مورد در ادامه صحبت خواهم کرد).با این وجود این مسئله که احتمالا با گذشت زمان و ایجاد انواع جدید تر فناوری ها ما دنیای EE v رو با پروفایل هایی که مدام از این سو و آن سو سر در میارند(البته تحت نظارت سان و JCP) تکه تکه خواهیم یافت.اگر چنین چیزی اتفاق بیفته باز هم عرصه برای راح حل هایی که توسعه دهندگام دنیای جدید رو به شکل متحد تری به جای EE به خودشون جلب می کنند باز تر خواهد شد.مخصوصا دات نت-رابی و پی اچ پی!چرا دوست دارم جاوا انتخاب اول توسعه دهندگان باشه؟
1-برنامه نویس بیشتر یعنی جوامع بزرگتر.هر چه جوامع برنامه نویسی بزگتر شن حل مسائل و مشکلاتشون توسط خودشون و سازمان های منتفع از آموزش بیشتر خواهد شد.کتاب های جدیتر که رفع عطش برای هر چه بهتر و بیشتریاد گرفتن جاوا رو فرو کش میکنند تنها در صورتی در راه خواهد بود که جامعه زیادی به شمت جاوا کشیده شند.در حال حاضر متاسفانه فروش کتاب های انتشارات ارایلی برای جاوا کم شده و برای دات نت رابی و پی اچ پی افزایش یافته.این یعنی زنگ خطر.(برای اشخاص و سازمانهایی که کلی وقت -سرمایه وعلاقه به پای جاوا ریختند).
2-هرچند جاوا به عنوان استاندارد صنعتی و تجاری در زمینه سازمانی و و و هست.با این وجود وجود جایگزین های ساده تر و سبکتر مثل پی اچی پی یا راه حل هایی که Tool support خیلی جامع و یک پارچه مثل دات نت و VS دارند خیل عظیمی از برنامه نویسان نو پا و حتی با تجرب رو به سمت سایر پلت فرم ها فراهم اورده!
3-تعصب و جانبداری؟به هیچ عنوان.

2-آسان سازی:این عالیه.چنتا از این آسان سازی ها :
الف - Servlet 3!قراره پیکربندی سرولت ها هم مثل EJB3 با Annonatin بشه.مثلا:

package com.foo;
@Servlet(name=”MyServlet”, url-pattern=”/myApp/*”)
public class MyServlet {
public void doGet(HttpServletRequest req,
HttpServletResponse res)
{
...
}
در یک کلام پیکربندی XML قراره به شکل پیشفرض وجود داشته باشه. فقط در صورت نیاز به رونویسی پیکربندی پیشفرض ازش استفاده بشه.فهرست چیز های جذاب در این ورژن خلی جذابه به این لینک مراجعه کنید:
http://jcp.org/en/jsr/detail?id=315
ب - JSF 2:برای این یکی هم کلی برنامه هست !این جا رو نگاه کنید!

(http://jcp.org/en/jsr/detail?id=314)
ج-Web Beans:در یه کلام استفاده از EJB ها به جای Managed Beans های JSF!
http://jcp.org/en/jsr/detail?id=299
د-JSR-236 Timer for Application Servers (در پستی یه نمونه از روش کنونی انجام کار ها در یه دروه زمانی به شکل مداوم به Handinux یه روش رو توضیخ دادم با پیاده سازی این JSR خیلی شفاف و راحت میشه!)- JSR-237 Work Manager for Application Servers-JSR-311 JAX-RS: Java API for RESTful Web Services
و و و ...
این jsr ها کمی دچار تعویق در رونمایی در ویرایش EE6 خواهند بود!
JSR-168 Portlet Specification
JSR-170 Content Repository for Java technology API
JSR-207 Process Definition for Java
JSR-208 Java Business Integration (JBI)
JSR-225 XQuery API for Java (XQJ)
JSR-235 Service Data Objects
JSR-286 Portlet Specification 2.0
JSR-289 SIP Servlet v1.1
JSR-301 Portlet Bridge Specification for JavaServer Faces

3-قابلیت توسعه!
این ویژگی حول گنجاندن جاهایی برای چسبوندن فرم فرک های بسیار زیاد دنیای EE به EE همینطور اظافه کردن قابلیت برنامه نویسی EE به زبان هایی مثل Ruby, Javascript and JavaFX in Java EE!جالبه.پاسخی صریح به دات نت و زبانهای متنوعش!اما جای php و #C خالیه!

درنهایت امیدوام شاهد بهبود هایی در زمینه کم شدن هزینه Scale شدن برنامه های EE برای مخصوصا اینترنت و وب نسبت به الان.(متاسفانه در حال حاضر در مقام مقایسه برای Scale کردن مثلا هزار کابر همزمان در EE باید هزینه بیشتری یا حتی خیلی بیشتری نسبت به php یا دات نت پرداخت بشه!االبته شما در مورد EE مرز های گسترده تری نسبت به حد اکثر های دات نت و php خواهید داشت.اما مگه چند در صد سایت ها نیازمند این سطح از مقیاس پذیری هستند؟)

همچنین در مورد jsf:
1-گنجانده شدن طیف وسیعی از UI ها به صورت استاندار در خود SPC .این باعث میشه که این کامپوننت ها در هر پیاده سازی موجود باشند.
2-فرمت خروجی برای Client ها:اگه این امکان باشه تا بشه مثلا خروجی JSF قابل توسعه به شکل واحد در مثلا فرمت Flash-Swnig applet-Ajax html و وو داشته باشه.در حال حاضر هم چنین پیاده سازی هایی برای Client ها و فنا وری هایی مثل Flex-Open Laszlo -Backbase -IceFaces ویا Smart Client هستم.اما یکپارچگی ای که در JSF به وجود میاد مطمئنا باعث موارد بهتری برای جلب توجه برنامه نویسان جدید به خود امکانات ذاتی EE بود.
در خاتمه از وقتی که گذاشتید ممنونم.و مشتاقانه پذیرای نظرات و سوالات شما هستم.
با تشکر.
منابع :
http://jcp.org/
http://www.artima.com/lejava/articles/java_ee_6.html
http://blog.taragana.com/index.php/archive/java-ee-6-highlights/
http://www.javalobby.org/java/forums/t99039.html

fkohantorabi
دوشنبه 13 خرداد 1387, 18:46 عصر
قسمت استادارد سازی خیلی دور از ذهن خواهد بود و اصولا با بازار پویای تولید کنندگان app server مطابقت نمی کند. JBoss مثلا همیشه از spec یکم دور بوده و یک سری چیزها رو به روش خودش حل کرده و بعضا راه حل های خوب رو به community بر گردونده که به استاندارد جاوا اضافه بشود.

به علاوه اکثر app serverها دارای class loading خودشون هستن که معمولا هم این به خاطر بهینه سازی سرعت و حافظه هستش و خود استاندارد جاوا هم این مساله رو به غیر تیکه های خاصی باز گذاشته و بعید می دونم که اصولا به نفع باشه که استانداردش کنه. این دقیقا بحث اینه که کنترل جاوا تا چه حد دیکتاتوری (از طریق JCP) و تا چه حد دموکراسی (از طریق community) باشه. خیلی ها معتقد هستن قدرت JCP باید ماکسیمم همینه باشه که الان هست و نه بیشتر. بوجود امدن JSR جدید هم اصولا چیزی سودمندی نیست.

در مورد profileها هم دیگه شرمنده کردن. البته این می تواند یکی از نوآوریهایی باشه که JBoss شروع کرد (شایدم کسی دیگه نمی دونم) ولی از وقتی OSGi جدی شد و IBM شروع کرد تو هر چیزی یک OSGi Container بزاره کم کم دیگه واضح شد که ساختار app server ها داره می شه مجوعه ای از OSGi Modules. بقیه هم مثل JBoss الان دارن رو این کار میکنند.

در آخر یک مطلب در مورد کتاب ها بگم که یک دلیل که الان زبانهای دیگر دارن محبوب میشن این هست که برنامه نویس جاوا خیلی کمه. من نمیدنم که اونجا سیستم چیه و لی در اکثر دنیا بحران برنامه نویس دارن و مقدار زیادی پروژه ایی که با جاوا شروع شده بود به دلیل نبود برنامه نویس جاوا مجبور شدن به سمت زبانهای دیگر بروند و میزان تقاضا تعیین می کند که ناشران کتاب به کدوم سمت باید بروند. یک چند وقت تول می کشه تا بازار برنامه نویسهای دیگر هم اشباع بشود و دو باره تقریبا همه چیز بر می گردد به جایی که بود.


فرزاد-

mazdadoost
جمعه 17 خرداد 1387, 21:34 عصر
قسمت استادارد سازی خیلی دور از ذهن خواهد بود و اصولا با بازار پویای تولید کنندگان app server مطابقت نمی کند. JBoss مثلا همیشه از spec یکم دور بوده و یک سری چیزها رو به روش خودش حل کرده و بعضا راه حل های خوب رو به community بر گردونده که به استاندارد جاوا اضافه بشود.

به علاوه اکثر app serverها دارای class loading خودشون هستن که معمولا هم این به خاطر بهینه سازی سرعت و حافظه هستش و خود استاندارد جاوا هم این مساله رو به غیر تیکه های خاصی باز گذاشته و بعید می دونم که اصولا به نفع باشه که استانداردش کنه. این دقیقا بحث اینه که کنترل جاوا تا چه حد دیکتاتوری (از طریق JCP) و تا چه حد دموکراسی (از طریق community) باشه. خیلی ها معتقد هستن قدرت JCP باید ماکسیمم همینه باشه که الان هست و نه بیشتر. بوجود امدن JSR جدید هم اصولا چیزی سودمندی نیست.

در مورد profileها هم دیگه شرمنده کردن. البته این می تواند یکی از نوآوریهایی باشه که JBoss شروع کرد (شایدم کسی دیگه نمی دونم) ولی از وقتی OSGi جدی شد و IBM شروع کرد تو هر چیزی یک OSGi Container بزاره کم کم دیگه واضح شد که ساختار app server ها داره می شه مجوعه ای از OSGi Modules. بقیه هم مثل JBoss الان دارن رو این کار میکنند.

در آخر یک مطلب در مورد کتاب ها بگم که یک دلیل که الان زبانهای دیگر دارن محبوب میشن این هست که برنامه نویس جاوا خیلی کمه. من نمیدنم که اونجا سیستم چیه و لی در اکثر دنیا بحران برنامه نویس دارن و مقدار زیادی پروژه ایی که با جاوا شروع شده بود به دلیل نبود برنامه نویس جاوا مجبور شدن به سمت زبانهای دیگر بروند و میزان تقاضا تعیین می کند که ناشران کتاب به کدوم سمت باید بروند. یک چند وقت تول می کشه تا بازار برنامه نویسهای دیگر هم اشباع بشود و دو باره تقریبا همه چیز بر می گردد به جایی که بود.

.
دوست عزیز :
در مورد استاندارد سازی منظور من SPEC بود نه IMPL .همونطوری که الان هست.شما هم میتونید Class Loader خاص خودتون رو طراحی کنید و همینطور لیست بلندی از SPI ها و Interface ها و Abstract کلاس ها که جا های بسیاری رو برای پیادی هر چیز به روش خودتون و دیگران طبق SPEC ها و استاندارد ها باز گذاشته شده.ابن چیزی هست که در مورد کل جاوا همین الان هم صادق هست.در مرود استاندارد های خود App Server ها هم همونطور که گفتم چون جزیی از JSR های رسمی EE نیستند(Jboss Seems-Spring-....)گرچه تسهیلات فراوانی مثل سهولت استفاده و کارایی رو به همراه دارند اما مسئله اینجاست که استاندارد های Defacto هستند.این همون مشکلاتی که در مورد EE نسبت به سایر Alternative ها مثل .net-PHP و حتی ZOPE و رابی هست رو برای EE پیش میاره.
منظورتون از community ,انجمن های غیر رسمی به جز JCP هست یا چیز دیگه ای؟به هر حال به نظر میرسه طبق اظهارات سان و خود JCP تنها نهادی که در ساخت ویرایش های جدید از پلت فرم های جاوا فعالیت داره JCP و اعضاش هستند.
اگه مقدوره بفرمایید:
1- چه چیز در مورد پروفایل ها باعث شرمندگیه؟
2-چرا فکر می کنید به OSGI ربط دارند و چگونه؟(ایا منظورتون اینه که بین bundle های OSGI و Profile های EE 6 تناظر یک به یک هست,یا Profile های EE 6 اصولا نوعی bundle OSGI خواهند بود؟مثل کار هایی که سان برای مثال در Glassfish 3 با OSGI آنجام داده و Spring و Eclipse ,...؟)
3-چرا ایجاد JSR های جدید اصولاچیز سودمندی نیست؟
در نهایت اینکه کم شدن برنامه نویس های دلیل مقدم کم شدن کتاب های برنامه نوسی جاواست.نه دلیل متاخرش!بر نامه نویس های جاوا انقدر ها هم کم نیستند.منتها موارد زیادی باعث استقبال زیاد برنامه نویسان نوپا و حتی جاوا کار های کنونی به جایگزین های جاوا شده.که قسمتیش رو در مقاله گفتم.
با تشکر

fkohantorabi
چهارشنبه 22 خرداد 1387, 01:31 صبح
دوست عزیز :
در مورد استاندارد سازی منظور من SPEC بود نه IMPL .همونطوری که الان هست.شما هم میتونید Class Loader خاص خودتون رو طراحی کنید و همینطور لیست بلندی از SPI ها و Interface ها و Abstract کلاس ها که جا های بسیاری رو برای پیادی هر چیز به روش خودتون و دیگران طبق SPEC ها و استاندارد ها باز گذاشته شده.ابن چیزی هست که در مورد کل جاوا همین الان هم صادق هست.در مرود استاندارد های خود App Server ها هم همونطور که گفتم چون جزیی از JSR های رسمی EE نیستند(Jboss Seems-Spring-....)گرچه تسهیلات فراوانی مثل سهولت استفاده و کارایی رو به همراه دارند اما مسئله اینجاست که استاندارد های Defacto هستند.این همون مشکلاتی که در مورد EE نسبت به سایر Alternative ها مثل .net-PHP و حتی ZOPE و رابی هست رو برای EE پیش میاره.
منظورتون از community ,انجمن های غیر رسمی به جز JCP هست یا چیز دیگه ای؟به هر حال به نظر میرسه طبق اظهارات سان و خود JCP تنها نهادی که در ساخت ویرایش های جدید از پلت فرم های جاوا فعالیت داره JCP و اعضاش هستند.
اگه مقدوره بفرمایید:
1- چه چیز در مورد پروفایل ها باعث شرمندگیه؟
2-چرا فکر می کنید به OSGI ربط دارند و چگونه؟(ایا منظورتون اینه که بین bundle های OSGI و Profile های EE 6 تناظر یک به یک هست,یا Profile های EE 6 اصولا نوعی bundle OSGI خواهند بود؟مثل کار هایی که سان برای مثال در Glassfish 3 با OSGI آنجام داده و Spring و Eclipse ,...؟)
3-چرا ایجاد JSR های جدید اصولاچیز سودمندی نیست؟
در نهایت اینکه کم شدن برنامه نویس های دلیل مقدم کم شدن کتاب های برنامه نوسی جاواست.نه دلیل متاخرش!بر نامه نویس های جاوا انقدر ها هم کم نیستند.منتها موارد زیادی باعث استقبال زیاد برنامه نویسان نوپا و حتی جاوا کار های کنونی به جایگزین های جاوا شده.که قسمتیش رو در مقاله گفتم.
با تشکر

ببخشید که دیر برگشتم. پروفایل به نظر من خیلی دیر دارن میان و خیلی زود تر از این جاش بود که بیان و برای همین بود که گفتم شرمنده کردن. OSGi هم اصولا یک معماری برای همزیستی سرویسهای مختلف داخل یک jvm ارایه داد که خیلی به درد یک app server می خوره و اصولا به نظر میاد که این شیوه فکر بود که باعث شد پروفایلها و احتمالا چیزهای مشابه بیرون بیان. تا اونجایی که من میدونم هم web sphere و هم JBoss دارن از OSGi استفاده می کنند. البته JBoss هنوز داره روش کار می کنه ولی WebSphere 6.x بر پایه OSGi هستش. در آخر مشکل من با jsr شدن تکنولوژیها تو اینه که میوفته دست یکسری آدم خاص و تا حد زیادی نوآوری توش کم میشه. یکی از بحتهایی که من با Emmanuel Bernard چند وقت بیشتر داشتم سر قضیه hibernate و JPA بود که آخرش از کدوم استفاده کنیم و نهایتا به این نتیجه رسیدیم که میشه 80 درصد کد رو به استاندارد نوشت و 20 درصد کد خارج استاندارد و عملا اتفاقی که داره میفته اینه که استاندارد آخر آخرش هم استاندارد نمی شه و اینکه برنامه رو طبق spec بنویس و بین هر تکنولوژی که میخوای حرکت کن عملی نیست یعنی حداقل الان نیست. یک مشکل دیگری که من با استانداردها دارم اینه که معمولا استانداردها یک لایه abstraction روی چیزی که وجود داره اضافه می کنند و معمولا تعداد زیاد لایه های abstraction باعث می شود که برنامه نویس های متوسط اشتباه بکنند. من الان این مشکل رو با برنامه نویسهای تیمم دارم. در هر حالت من هنوز قبول دارم که استانداردها سودمند هم هستند ولی حرف من فقط اینه که برای همه چی دیگه استاندارد نمی خواهیم.



فرزاد-

javaphantom
چهارشنبه 22 خرداد 1387, 04:08 صبح
ببخشید که دیر برگشتم. پروفایل به نظر من خیلی دیر دارن میان و خیلی زود تر از این جاش بود که بیان و برای همین بود که گفتم شرمنده کردن. OSGi هم اصولا یک معماری برای همزیستی سرویسهای مختلف داخل یک jvm ارایه داد که خیلی به درد یک app server می خوره و اصولا به نظر میاد که این شیوه فکر بود که باعث شد پروفایلها و احتمالا چیزهای مشابه بیرون بیان. تا اونجایی که من میدونم هم web sphere و هم JBoss دارن از OSGi استفاده می کنند. البته JBoss هنوز داره روش کار می کنه ولی WebSphere 6.x بر پایه OSGi هستش. در آخر مشکل من با jsr شدن تکنولوژیها تو اینه که میوفته دست یکسری آدم خاص و تا حد زیادی نوآوری توش کم میشه. یکی از بحتهایی که من با Emmanuel Bernard چند وقت بیشتر داشتم سر قضیه hibernate و JPA بود که آخرش از کدوم استفاده کنیم و نهایتا به این نتیجه رسیدیم که میشه 80 درصد کد رو به استاندارد نوشت و 20 درصد کد خارج استاندارد و عملا اتفاقی که داره میفته اینه که استاندارد آخر آخرش هم استاندارد نمی شه و اینکه برنامه رو طبق spec بنویس و بین هر تکنولوژی که میخوای حرکت کن عملی نیست یعنی حداقل الان نیست. یک مشکل دیگری که من با استانداردها دارم اینه که معمولا استانداردها یک لایه abstraction روی چیزی که وجود داره اضافه می کنند و معمولا تعداد زیاد لایه های abstraction باعث می شود که برنامه نویس های متوسط اشتباه بکنند. من الان این مشکل رو با برنامه نویسهای تیمم دارم. در هر حالت من هنوز قبول دارم که استانداردها سودمند هم هستند ولی حرف من فقط اینه که برای همه چی دیگه استاندارد نمی خواهیم.



فرزاد-

صحبت از استاندارد کردید و من خودم از کسانی هسمتم که طرفدار استانداردهای خود سان هستم و سعی می کنم با استاندارد های اون جلو بیام. java persistence چیزی هست که به همراه ejb3 اومده و تقلیدی از hibernate می باشه. با این تفاوت که API های استفاده شده در ان همگی استاندارد هستد و خود سان اعلام کره که در نسخه های آینده این تکنولوژی رو قوی تر و بهتر می کنه. من خودم در حال حاضر با ejb3 و persistence که هر دو استاندارد خود سان هستند و تایید شده می باشند دارم کار می کنم و واقعا می شه گفت که درسته که الان همه با فریم ورکهایی در حال کار هستد که بسیار مردمی هست مانند Spring , Hibernate ولی به نظر من علت آن چند چیز هست که به سمت استانداردی که ازطرف خود سان معرفی شده نمی آیند.
نداشتن نیرویی که واقعا به ساختار خود زبان جاوا مسلط باشه مخصوصا بخش مهمی که در ejb3 استفاده می شه که همان annotation ها می باشه.
هزینه و ریسک بالا برای سویئچ کردن روی تکنولوژی جدید
عدم وجود سیستم های سازمانی که نیاز مبرمی به پیاده سازی با این تکنولوژی قوی باشه. وافعا توی ایران ما چه قدر نرم افزارهای سازمانی داریم که در حال اجراست یا در حال ساخت است؟
نداشتن اطلاعات درست نسبت به قدرت و کارایی این تکنولوژی های جدید به جای تکنولوژی قدیمی که در حال اجرا هستن

من خودم به شخصا در ایران با اینکه می دونم در حال حاضر کسان کمی هستند که با فریم ورک ejb3 به جای Spring و persistence بجای hibernate کار می کنند. ولی این دو را انتخاب کردم ومی تونم بگم واقعا سان و IBM شاهکار کردندو مطمعن هستم که در آینده نزدیک ایران هم به سوی اسانداردهای سان از جمله JSF, EJB3,Persistence خواهد رفت.
من یکی از طرفداران پر و پا قرص Sun Microsystem هستم و می دونم چیز بد بیرون نمی ده و وقتی می گه آینده برای ejb3 و persistence هست پس حتما هست

mazdadoost
چهارشنبه 22 خرداد 1387, 20:13 عصر
با تشکر از fkohantorabi و javaphantom :

fkohantorabi:
با نظرتون مبنی بر احتمال استفاده بیشتر از OSGI ها موافقم.با این وجود با توجه به برنامه ریزی های زیادی که در حال حاضر توصط اعضاء JCP در حال انجام هست و تا نهایت ربع چهارم 2008 پروپوزال اکثر JSR های EE6 نهایی میشه خبر چندانی از همراه شدن EE با یک OSGI Container نیست.هرچند به احتمال خیلی زیاد در پشت صحنه قابلیت Extensibility جاوا EE 6 به شکل عمده در پشت صحنه از طریق همین OSGI صورت خواهد گرفت.(Spring رو میدونم که می خواد به صورت یک bundle OSGI هم ارائه بشه.احتمالا در آینده همه فرم ورک های EE به صورت bundle OSGI هم ارائه خواهد شد.اینطوری میتونید بدون دردسر های پیکربندی نه تنها APP SERVER ها رو به شکل پلاگ این توسعه بدین بلکه میتونید اجرائ استاندارد رو هم غیر فعال کنید و از موارد خودتون استفاده کنید.).

در مورد اینکه در حال حاضر چقدر اشعار Write Once ,Deploy Any Where در EE تحقق پیدا کرده باز واقعا هنوز حتی با Annonation Base شدن قسمت عمده ای از EE ما برای پیکربندی App server های نیاز به کانفیگ خود app server ها داریم.(jrun.xml-jboss.xml ووو).همونطور که گفتم احتمالا این مسائل در EE6 کمتر خواهد شد.
و اما در مورد استاندارد ها! fkohantorabi و javaphantom عزیز:
به نظر بنده استاندارد ها ی کنونی جاوا شامل استاندارد های رسمی و غیر رسمی هست:
1استاندارد های رسمی : چیزهایی که مورد تائئد سان هست. و به شکل استاندارد قراره که با APP SRV های مورد تائید سان همرا باشند.(حالا چه Core و چه Optinal!).دو نکته که حائظ اهمیت در استاندارد ها هستند و من روش تکیه میکنم :
1-ایجاد یکنواختی:در مورد ما اینکه ما از تکنولوژی ها به یک نحو در همه موارد پیاده سازی استاندارد ها استفاده کنیم.که تا حد زیادی بر آورده شده.منتها گاهی مسائلی داره.مثلا هر چند Core JSF IMPL در همه EE ها به یک شکل هست ولی متاسفانه تفاوت هایی در کامپوننت های ارائه شده در سازندگان مختلف هست که شما رو نه تنها مجبور میکنه این تفاوت ها رو یاد بگیرید.بلکه برای انتقال و Deploy کردن روی یه APP SERV دیگه شما باید Depnedics های اون JSF IMPL رو هم در برنامه برنامه بگونجونید!این یعنی فاصله از استاندارد ایده آل!
2-ایجاد حاشیه امنیت : یعنی شما بتونید وقت و سرمایتون رو هم در راستای هزینه های آموزشی وتهیه تکنولوژی مربوطه صرف کنید با این تضمین که بتونید تا مدتی متناسب با هزینه ای که کردین از اون یاد گیری و هزینه ی فناوری استفاده کنید.و یک شبه همه چی زی رو رو نشه!در مورد ما دوست دارم ببینم کدام یک از شما دوستان وقت و هزینه برای یاد گیری و استفاده از JDO کردین!اولین تلاش سان برای استاندارد سازی O/R Maping و پیاده سازی به اصطلاح orthogonal persistence ها!اگه دقت کنید جواب سان به مپر هایی مثل Hibernate و Toplink در واقع همین JDO بود!دوره آموزش و توسعه با JDO طولانی و هزینه بر بود(هزینه تهیه IMPL های این تکنولوژی در موارد زیادی بالاست.).با اومدن JPA چه اتفاقی برای JPA همه استفاده کنندگانش افتاد؟امید وارم بشه حساب بیشتری روی این استاندارد ها کرد.همونطور که انتظار میره و الان هم تا حد زیادی هست!سان و JCP واقعا تلاش میکنند.اما چیز هایی رو مثل موردی که گفتم هم میشه به پای سیاست های تجاری گذاشت هم اقتضات فنی!
2-استاندارد های غیر رسمی(Defacto):به موازات و پس وپیش استاندارد ها برای انجام کار های سازمانی فناوری ها و ابزارهای مختلفی در طیف گسترده ای از موارد مختلف برای انجام هر کاری از پروژه های ساده وب گرفته تا هر کار ممکنی در EE!چرا این فناوری ها جذاب شدن؟به نظ میرسه:
1-آسانی!:چیزهایی در همه پلت فرم های جاوا بوده وهست که حقیقتا منحنی آموزشی بلند مدتی دارن.از طرفی میزان کاری که برای پیاده سازی میبرند هم زیاده!(موارد مختلفی مثل EJB1.1-2-JMS-JMX-JATA-RMI-NEWI/O-Socket ووووو) .میشه به کسانی که قراره از این موارد استفاده میکنند این حق رو داد که به موارد سادتر و که هزینه بری روی بیارند.
2-کارایی و هزینه مقیاس پذیری بهتر به اصطلاح LightWeight تر بودن.میدونیم که استاندارد های یک سیسنم سازمانی حجم عظیمی از ویژگی ها رو میطلبه تا تبدیل به موجودیتی قابل اعتماد و اتکا در مسائل حیاتی همه نیاز های سازمانی بر بیاد!(اینجا بحث پوله!)EE به شکل کنونی دارای فناوری های مفصلی که تضمین کنند این نیاز هاست.همینه که شرکت های بزرگ براش ارزش قائل هستند.اما این تفضیل باعث شده میزان نسبتا زیاد و حتی زیاد و خیلی زیادی قدرت پردازش برای مقیاس کردن پروژه هایی که واقعا نیازی به این حجم قدرت ندارند تحمیل بشه.این هزینه سخت افزاریه!در بهترین حالت شما در حال حاضر و کمی پیشتر می تونید هزینه APP Server برای EE خودتون رو نسبتا با امثال Jboss و Glassfish کاهش تا حتی صفر بدین.اما پیشتر ها برای استفاده مطلوب از امکاناتی بیشتر از توان یه Servlet Contaner مثل EJB-JMS- ووو هزینه زیادی برای محصولات سان-IBM-BEA-Oracle وووو بدین!(حد اقل در دنیای بیرون از ایران!) .خیلی اوقات پروژه هایی هستند که نیاز به امکانات EJB ها JTA ها ووو دارند و بنا بر بودجشون نمی تونن ونمی خوان هزینه سخت افزار ونرم افزار گران قیمت رو بدن.(و همینطور زمان کمتری برای یادگیری کل تیم هاشون دارند!)اینجا بود که فناوری هایی مثل Spring -HiveMind-Hibernate-Strutsووو بوجد میان رشد میکنن و در پرتوی استقبال عمومی به بلوغ میرسند!با مجموعه Tomcat+Hibernate+Spring +Struts (برای مثال !)شما به قدرت زیادی با صرف هزینه خیلی کمتر نسبت به معادل های استاندارد میشدید و حتی الان هم کمو بیش میشد!
نتیجه:چه استاندارد رسمی و چه غیر رسمی هر کدوم رو باید بر اساس نیاز های واقعی دنیای واقعی استفاده کرد.همونطور که ممکنه یه پروژه غیر رسمی و اپن سورس یه شبه نیست بشه همونقدر این احتمال برای نمونه رسمیش هست!کی از آینده خبر داره!؟ااینکه چقدر و چه میزان از این موارد استفاده می کنید به بودجه مالی زمانی ووو ربط داره.در صدش رو اینها معلوم میکنه!
ایا واقعا برای کسی که SE رو در حد متوسطش بلده لازم نیست که با Annonation اشنا باشه!جواب مثبته!آیا کسی که میخواد وارد دنیای EE بشه (در حد بون Certificate هم!)تسلط به SE لازم نیست؟بله!پس کار بیجایی کسی بخواد در دنیای واقعی برای EE و وب برنامه بنویسه ولی به Annonation و پایش در SE اشنا نباشه!به این کار میگن بچه بازی!و این مشکل توسعه دهندگان واقعی نیست که نخوان به EJB 3 وری بیارند یا نیارند!هزینه و ریسک بالا قابل تامل هست!اینجا دقیقا جایی که سازمان باید تصمیم گیری کنه(آموزش-خرید محصولات نرم افزاری و سخت افزاری!)و بله بعضی ها حتی با اومدن امثال EJB 3 هم این حق رو دارند تا با چشم باز به همون استفاده از Spring روی بیارند(Spring هم ورژن 2 بسیار Annonation بیس شده!).پویایی جاوا میطلبه تا برای هر نیازی جوابی داشته باشه.از طرفی آیا استفاده از Annonation کار ما رو در یاد گیری و پیاده سازی ساده تر کرده!این هم قابل تامله!به نظر من کار های انجام شده واقعا قابل تقدیره مخصوصا وب سرویس ها !اما در مورد JPA و EJB 3 چی؟چقدر نسبت به گذشته که با XML ها و پیاده سازی Inteface های EJB2 کار کمتری میکنیم.کمتر هست اما باز هم وقتی کار ها پیچیده تر میشه Anonnaton ها هم ...بله!
سان واقعا حق جاوا رو به جای نیاورده!وقتی که J2EE و J2SE بودند 15 تا 16 سال حاکم واقعی سازمان ها جاوا بود!حالا چرا باید شاهد روی اوردن سازمان ها به دات نت باشیم.؟همین باعث میشه چندان به سان اعتماد نکنم.شاید هم به چیزی که گفته برسه!
چیزی که مهمه اینه که جاوا به حیاتش برای تامین نیازهای ما (دوستارانی که میدونن چرا جاوا رو دوست دارند به شکلی عمیق و راهبردی )ادامه بده!حالا چه استاندارد چه غیر اون ووو (به هر حال همه اینه یعنی جاوا!)...
امید وارم مفید بوده باشه.
موفق باشید.

fkohantorabi
چهارشنبه 22 خرداد 1387, 22:16 عصر
با تشکر از fkohantorabi و javaphantom :

fkohantorabi:
با نظرتون مبنی بر احتمال استفاده بیشتر از OSGI ها موافقم.با این وجود با توجه به برنامه ریزی های زیادی که در حال حاضر توصط اعضاء JCP در حال انجام هست و تا نهایت ربع چهارم 2008 پروپوزال اکثر JSR های EE6 نهایی میشه خبر چندانی از همراه شدن EE با یک OSGI Container نیست.هرچند به احتمال خیلی زیاد در پشت صحنه قابلیت Extensibility جاوا EE 6 به شکل عمده در پشت صحنه از طریق همین OSGI صورت خواهد گرفت.(Spring رو میدونم که می خواد به صورت یک bundle OSGI هم ارائه بشه.احتمالا در آینده همه فرم ورک های EE به صورت bundle OSGI هم ارائه خواهد شد.اینطوری میتونید بدون دردسر های پیکربندی نه تنها APP SERVER ها رو به شکل پلاگ این توسعه بدین بلکه میتونید اجرائ استاندارد رو هم غیر فعال کنید و از موارد خودتون استفاده کنید.).

در مورد اینکه در حال حاضر چقدر اشعار Write Once ,Deploy Any Where در EE تحقق پیدا کرده باز واقعا هنوز حتی با Annonation Base شدن قسمت عمده ای از EE ما برای پیکربندی App server های نیاز به کانفیگ خود app server ها داریم.(jrun.xml-jboss.xml ووو).همونطور که گفتم احتمالا این مسائل در EE6 کمتر خواهد شد.
و اما در مورد استاندارد ها! fkohantorabi و javaphantom عزیز:
به نظر بنده استاندارد ها ی کنونی جاوا شامل استاندارد های رسمی و غیر رسمی هست:
1استاندارد های رسمی : چیزهایی که مورد تائئد سان هست. و به شکل استاندارد قراره که با APP SRV های مورد تائید سان همرا باشند.(حالا چه Core و چه Optinal!).دو نکته که حائظ اهمیت در استاندارد ها هستند و من روش تکیه میکنم :
1-ایجاد یکنواختی:در مورد ما اینکه ما از تکنولوژی ها به یک نحو در همه موارد پیاده سازی استاندارد ها استفاده کنیم.که تا حد زیادی بر آورده شده.منتها گاهی مسائلی داره.مثلا هر چند Core JSF IMPL در همه EE ها به یک شکل هست ولی متاسفانه تفاوت هایی در کامپوننت های ارائه شده در سازندگان مختلف هست که شما رو نه تنها مجبور میکنه این تفاوت ها رو یاد بگیرید.بلکه برای انتقال و Deploy کردن روی یه APP SERV دیگه شما باید Depnedics های اون JSF IMPL رو هم در برنامه برنامه بگونجونید!این یعنی فاصله از استاندارد ایده آل!
2-ایجاد حاشیه امنیت : یعنی شما بتونید وقت و سرمایتون رو هم در راستای هزینه های آموزشی وتهیه تکنولوژی مربوطه صرف کنید با این تضمین که بتونید تا مدتی متناسب با هزینه ای که کردین از اون یاد گیری و هزینه ی فناوری استفاده کنید.و یک شبه همه چی زی رو رو نشه!در مورد ما دوست دارم ببینم کدام یک از شما دوستان وقت و هزینه برای یاد گیری و استفاده از JDO کردین!اولین تلاش سان برای استاندارد سازی O/R Maping و پیاده سازی به اصطلاح orthogonal persistence ها!اگه دقت کنید جواب سان به مپر هایی مثل Hibernate و Toplink در واقع همین JDO بود!دوره آموزش و توسعه با JDO طولانی و هزینه بر بود(هزینه تهیه IMPL های این تکنولوژی در موارد زیادی بالاست.).با اومدن JPA چه اتفاقی برای JPA همه استفاده کنندگانش افتاد؟امید وارم بشه حساب بیشتری روی این استاندارد ها کرد.همونطور که انتظار میره و الان هم تا حد زیادی هست!سان و JCP واقعا تلاش میکنند.اما چیز هایی رو مثل موردی که گفتم هم میشه به پای سیاست های تجاری گذاشت هم اقتضات فنی!
2-استاندارد های غیر رسمی(Defacto):به موازات و پس وپیش استاندارد ها برای انجام کار های سازمانی فناوری ها و ابزارهای مختلفی در طیف گسترده ای از موارد مختلف برای انجام هر کاری از پروژه های ساده وب گرفته تا هر کار ممکنی در EE!چرا این فناوری ها جذاب شدن؟به نظ میرسه:
1-آسانی!:چیزهایی در همه پلت فرم های جاوا بوده وهست که حقیقتا منحنی آموزشی بلند مدتی دارن.از طرفی میزان کاری که برای پیاده سازی میبرند هم زیاده!(موارد مختلفی مثل EJB1.1-2-JMS-JMX-JATA-RMI-NEWI/O-Socket ووووو) .میشه به کسانی که قراره از این موارد استفاده میکنند این حق رو داد که به موارد سادتر و که هزینه بری روی بیارند.
2-کارایی و هزینه مقیاس پذیری بهتر به اصطلاح LightWeight تر بودن.میدونیم که استاندارد های یک سیسنم سازمانی حجم عظیمی از ویژگی ها رو میطلبه تا تبدیل به موجودیتی قابل اعتماد و اتکا در مسائل حیاتی همه نیاز های سازمانی بر بیاد!(اینجا بحث پوله!)EE به شکل کنونی دارای فناوری های مفصلی که تضمین کنند این نیاز هاست.همینه که شرکت های بزرگ براش ارزش قائل هستند.اما این تفضیل باعث شده میزان نسبتا زیاد و حتی زیاد و خیلی زیادی قدرت پردازش برای مقیاس کردن پروژه هایی که واقعا نیازی به این حجم قدرت ندارند تحمیل بشه.این هزینه سخت افزاریه!در بهترین حالت شما در حال حاضر و کمی پیشتر می تونید هزینه APP Server برای EE خودتون رو نسبتا با امثال Jboss و Glassfish کاهش تا حتی صفر بدین.اما پیشتر ها برای استفاده مطلوب از امکاناتی بیشتر از توان یه Servlet Contaner مثل EJB-JMS- ووو هزینه زیادی برای محصولات سان-IBM-BEA-Oracle وووو بدین!(حد اقل در دنیای بیرون از ایران!) .خیلی اوقات پروژه هایی هستند که نیاز به امکانات EJB ها JTA ها ووو دارند و بنا بر بودجشون نمی تونن ونمی خوان هزینه سخت افزار ونرم افزار گران قیمت رو بدن.(و همینطور زمان کمتری برای یادگیری کل تیم هاشون دارند!)اینجا بود که فناوری هایی مثل Spring -HiveMind-Hibernate-Strutsووو بوجد میان رشد میکنن و در پرتوی استقبال عمومی به بلوغ میرسند!با مجموعه Tomcat+Hibernate+Spring +Struts (برای مثال !)شما به قدرت زیادی با صرف هزینه خیلی کمتر نسبت به معادل های استاندارد میشدید و حتی الان هم کمو بیش میشد!
نتیجه:چه استاندارد رسمی و چه غیر رسمی هر کدوم رو باید بر اساس نیاز های واقعی دنیای واقعی استفاده کرد.همونطور که ممکنه یه پروژه غیر رسمی و اپن سورس یه شبه نیست بشه همونقدر این احتمال برای نمونه رسمیش هست!کی از آینده خبر داره!؟ااینکه چقدر و چه میزان از این موارد استفاده می کنید به بودجه مالی زمانی ووو ربط داره.در صدش رو اینها معلوم میکنه!
ایا واقعا برای کسی که SE رو در حد متوسطش بلده لازم نیست که با Annonation اشنا باشه!جواب مثبته!آیا کسی که میخواد وارد دنیای EE بشه (در حد بون Certificate هم!)تسلط به SE لازم نیست؟بله!پس کار بیجایی کسی بخواد در دنیای واقعی برای EE و وب برنامه بنویسه ولی به Annonation و پایش در SE اشنا نباشه!به این کار میگن بچه بازی!و این مشکل توسعه دهندگان واقعی نیست که نخوان به EJB 3 وری بیارند یا نیارند!هزینه و ریسک بالا قابل تامل هست!اینجا دقیقا جایی که سازمان باید تصمیم گیری کنه(آموزش-خرید محصولات نرم افزاری و سخت افزاری!)و بله بعضی ها حتی با اومدن امثال EJB 3 هم این حق رو دارند تا با چشم باز به همون استفاده از Spring روی بیارند(Spring هم ورژن 2 بسیار Annonation بیس شده!).پویایی جاوا میطلبه تا برای هر نیازی جوابی داشته باشه.از طرفی آیا استفاده از Annonation کار ما رو در یاد گیری و پیاده سازی ساده تر کرده!این هم قابل تامله!به نظر من کار های انجام شده واقعا قابل تقدیره مخصوصا وب سرویس ها !اما در مورد JPA و EJB 3 چی؟چقدر نسبت به گذشته که با XML ها و پیاده سازی Inteface های EJB2 کار کمتری میکنیم.کمتر هست اما باز هم وقتی کار ها پیچیده تر میشه Anonnaton ها هم ...بله!
سان واقعا حق جاوا رو به جای نیاورده!وقتی که J2EE و J2SE بودند 15 تا 16 سال حاکم واقعی سازمان ها جاوا بود!حالا چرا باید شاهد روی اوردن سازمان ها به دات نت باشیم.؟همین باعث میشه چندان به سان اعتماد نکنم.شاید هم به چیزی که گفته برسه!
چیزی که مهمه اینه که جاوا به حیاتش برای تامین نیازهای ما (دوستارانی که میدونن چرا جاوا رو دوست دارند به شکلی عمیق و راهبردی )ادامه بده!حالا چه استاندارد چه غیر اون ووو (به هر حال همه اینه یعنی جاوا!)...
امید وارم مفید بوده باشه.
موفق باشید.

مرسی از پست جالبت. یک نکتهه ای که دوست دارم در موردش اینجا بحث کنم وجود annotation هاست. آیا واقعا مفیدن؟ مشکل من با annotation اینه که داره تجزیه مسولیتها توی پروژه رو از بین میبره. خیلی از چیزهایی که ما قبلا تو xml می گذاشتیم به نقش فردی در تیم تعلق داشت که مسولیت deployment رو بر عهده میگیرد و این فرد اصولا لازم نیست که از کد زیاد بداند. با گذاشتن بخشه زیادی از ان داده ها داخل کد الان برنامه نویسها ناخاصته کار deployer رو دارن انجام میدن. تو پروژه های کوچیک این مشکلی نیست ولی یکم سایز پروژه بزرگ بشه این مساله خودش رو نشون میدهد. به نظر من annotation باید با احتیاط استفاده بشود.


فرزاد-

mazdadoost
پنج شنبه 23 خرداد 1387, 07:20 صبح
مرسی از پست جالبت. یک نکتهه ای که دوست دارم در موردش اینجا بحث کنم وجود annotation هاست. آیا واقعا مفیدن؟ مشکل من با annotation اینه که داره تجزیه مسولیتها توی پروژه رو از بین میبره. خیلی از چیزهایی که ما قبلا تو xml می گذاشتیم به نقش فردی در تیم تعلق داشت که مسولیت deployment رو بر عهده میگیرد و این فرد اصولا لازم نیست که از کد زیاد بداند. با گذاشتن بخشه زیادی از ان داده ها داخل کد الان برنامه نویسها ناخاصته کار deployer رو دارن انجام میدن. تو پروژه های کوچیک این مشکلی نیست ولی یکم سایز پروژه بزرگ بشه این مساله خودش رو نشون میدهد. به نظر من annotation باید با احتیاط استفاده بشود.


فرزاد-

دوست عزیز :
از اون جاییکه این تاپیک به برسی EE و انتظارات توسعه دهندگان در ورژن آتیه اون میپردازه پیشنهاد میکنم سعی کنیم در موضوع پیش بریم . مثلا در مورد شما :چه انتظاری از EE6 در زمینه Team Work و Annonation ها دارید!
(البته ذکر یه نکته هم خالی از اشکال نیست:اینکه پشتیبانی از XML همین الان با وجود اومدن Annonation ها به شکل کامل در همه APP SERV ها هست و ضروریه!
اگه به هر نحو با Annonation ها راحت نیستید میتونید از XML ها استفاده کنید.)
راستش به نظر بنده فرق چندانی بین XML ها و Annonation ها در برنامه هایی که به شدت بزرگ شدن نیست!در هر صورت بزرگی و حجم برنامه کار بیشتری می طلبه. و این کار تیم توسعه هست.و جاوا به هر حال کمک خودش رو به عنوان یه ابزار قوی میکنه.اگه Tool Support خوبی داشته باشیم (IDE-UML Designer -...)و نیروی خوب مخصوصا آنالیزور خوب و مشتری فنی IT واقعا اینکه از چی استفاده کنیم مسئله ای نیست.
با تشکر از لطفتون.

javaphantom
پنج شنبه 23 خرداد 1387, 10:49 صبح
با عوض شدن تکنولوژی مسئولیتها هم عوض می شه . این امر فقط در کامپیوتر و قسمت زبان آن نیست. در صنعت هم شما شاهد این تغییر تحول در مسئولیت می شوید و این از نظر من نسبت به قبل فقط نوع مشکل را تغییر می ده و ممکنه که فقط به ظاهر یکسری چیزی عوض شده باشه چون بازهم به دلیل اصل آنتراپی برای ایجاد نظم در یک قسمت ایجاد بی نظمی درجای دیکر بوجود می آید.
اینکه ما در patternی که د spring استفاده می شد وآن dependency injection می باشد و مبتنی بر تنظیم حجم عظمی از xml فایلهاست برای اینکه بتونه مستقل بودن خودش رو نسبت به هر platformی نشون بده و از طریق text این طرفند رو استفاده کرده.
اما در ejb3 ازpattern دیگری که همان pojo است استفاده شده. در ورژنهای قبل ejb2.X و پایین تر واقعان کار با اون سخت و وقت گیر بود بطوریکه استفاده از struts به قدری متداول بود که الان هم در بعضی شرکتها در ایران هنوز دارن از struts استفاده می کنند.که مبتنی بر MVC Pattern هست.
بحث annotation ها چیزه جدیدی نبود که بخواد یکهو ایجاد سروصدا کنه این امر در .Net هم با نام attribute ها که همان meta data هستند بوده و هست. در ورژن ۵ جاوا annotation بوده. استفاده از metadata ها شاید برای خیلی ها روال نبوده
POJO با شعار اینکه شما می توانید از طریق یک فایل ساده و معمولی جاوایی به راحتی وارد دنیای JEE بشید و برخلاف دشواریهای ورژنهای قبل که اگر دوست داشته باشید کامل توضیح خواهم داد محصول ejb3 رو بیرون می ده.
همانور که اطلاع دارید محصول در ejb یک کامپوننت هست نه یک Object جدا از بحث مدیریتی خود Component ها بحث ایجاد و چگونگی ساختار و چگونگی ارتباط ومدیریت و در آخر چیدمان آنها برای اجرا بسیار مهم است. در ejb3 هم حتما ما مسئولیتهایمان مشخص و از هم تفکیک شده است.
بحث به ترتیب ‌Bean Provider
Assembler
Deployer
Administrate
وجود داره و کاملا کار هر کدامشون مشخص است که اگر باز علاقه داشتید من بیشتر در مورد آنها صحبت می کنم.
اما باز به نکته خوبی اشاره کردن آقای mazdadoost که استفاده از xml ها در ejb3 وجود داره با وجود annotation ها. اما بصورت Optional و در صورت استفاده با اولیت بالاتر نسبت به Annotation ها.
لازم به ذکر است که خود Spring هم داره می ره به سمت Annotation می تونید توی سایتش بخونید.

اما اینکه گفته شده امروزه پروژه ها داره به سمت NET. می ره. سوال من اینکه چه پروژه هایی در کجا و در آخر این امار رو از کجا آوردید؟ برای مثال مگر یک بانک می تونه بیاد به OS ویندوز اطمینان کنه که بخواد از تکنولوژی NET. استفاده کنه.؟ شایدم تازگی ها IIS روی سان سلاریس یا روی دیگر platform ها نصب می شه. من نمی دونم؟

fkohantorabi
پنج شنبه 23 خرداد 1387, 23:36 عصر
وجود داره و کاملا کار هر کدامشون مشخص است که اگر باز علاقه داشتید من بیشتر در مورد آنها صحبت می کنم.
اگر شروع کنی که ممنون میشم.



لازم به ذکر است که خود Spring هم داره می ره به سمت Annotation می تونید توی سایتش بخونید.
من خیلی با تصمیماتی که Interface21 می گیره موافق نیستم ولی در کل هم نمی توانم ردشون کنم و بحث مربوطه در مورد وجود xml ها هم قبول دارم ولی هنوز برنامه نویسها می توانند به اشتباه از یکی استفاده کنند. در کل من نمی توانم بطور جدی با annotation ها مخالفت کنم ولی به مقدار زیادی با روشی که استفاده می شوند مشکل دارم و تقریبا این اشکال رو از خیلی تکنولوژی ها می شود گرفت. به عنوان مثال از چیزهایی که تو شرکتهای نسبتا قوی دیدم این بود که اطلاعات دیتابیس توی annotation بود و کلا بعد کامپایل کردن راهی نبود که عوض بشه و خوب چیزهای مشابه این.



فرزاد-

fkohantorabi
پنج شنبه 23 خرداد 1387, 23:49 عصر
پیشنهاد میکنم سعی کنیم در موضوع پیش بریم . مثلا در مورد شما :چه انتظاری از EE6 در زمینه Team Work و Annonation ها دارید!

javaphantom یکم بهش اشاره کرد و من فکر میکنم که بحث در مورد نقشهای مختلفی که EE6 حمایت کنه ما رو به یک جواب برسونه ولی فعلا من ترجیح می دم صبر کنم تا javaphantom یکم اون مطلب رو بیشتر باز کنه. ولیکن از طرفی هم من میدونم که حالا حالاها نمی توانم از EE6 استفاده کنم. من هنوز خیلی وقتها مجبورم از jdk 1.4 استفاده کنم و پروژه ها زیاد تصمیمی برای upgrade کردن ندارن. به قول معروف مدیریت زیاد علاقه ای برای خرج کردن روی تکنولوژی نداره وقتی می تواند با تکنولوژی قدیمی پول در بیاره. به علاوه اینکه معمولا شرکتها یکی دو سال صبر می کنند تا تکنولوژی ثابت بشه قبل از اینکه بخوان استفاده کنندش. اگه می خوای اوج قضیه رو بدونی یه حدس برزن چند پروژه من تو 6 ماه قبل دیدم که هنوز با Struts 1.x داره اجرا می شود؟ خیلی دیدم و اکثر این پروژه ها هنوز دارن از JDBC DAOها استفاده می کنند.

فرزاد-

mazdadoost
جمعه 24 خرداد 1387, 00:31 صبح
با عوض شدن تکنولوژی مسئولیتها هم عوض می شه . این امر فقط در کامپیوتر و قسمت زبان آن نیست. در صنعت هم شما شاهد این تغییر تحول در مسئولیت می شوید و این از نظر من نسبت به قبل فقط نوع مشکل را تغییر می ده و ممکنه که فقط به ظاهر یکسری چیزی عوض شده باشه چون بازهم به دلیل اصل آنتراپی برای ایجاد نظم در یک قسمت ایجاد بی نظمی درجای دیکر بوجود می آید.
اینکه ما در patternی که د spring استفاده می شد وآن dependency injection می باشد و مبتنی بر تنظیم حجم عظمی از xml فایلهاست برای اینکه بتونه مستقل بودن خودش رو نسبت به هر platformی نشون بده و از طریق text این طرفند رو استفاده کرده.
اما در ejb3 ازpattern دیگری که همان pojo است استفاده شده. در ورژنهای قبل ejb2.X و پایین تر واقعان کار با اون سخت و وقت گیر بود بطوریکه استفاده از struts به قدری متداول بود که الان هم در بعضی شرکتها در ایران هنوز دارن از struts استفاده می کنند.که مبتنی بر MVC Pattern هست.
بحث annotation ها چیزه جدیدی نبود که بخواد یکهو ایجاد سروصدا کنه این امر در .Net هم با نام attribute ها که همان meta data هستند بوده و هست. در ورژن ۵ جاوا annotation بوده. استفاده از metadata ها شاید برای خیلی ها روال نبوده
POJO با شعار اینکه شما می توانید از طریق یک فایل ساده و معمولی جاوایی به راحتی وارد دنیای JEE بشید و برخلاف دشواریهای ورژنهای قبل که اگر دوست داشته باشید کامل توضیح خواهم داد محصول ejb3 رو بیرون می ده.
همانور که اطلاع دارید محصول در ejb یک کامپوننت هست نه یک Object جدا از بحث مدیریتی خود Component ها بحث ایجاد و چگونگی ساختار و چگونگی ارتباط ومدیریت و در آخر چیدمان آنها برای اجرا بسیار مهم است. در ejb3 هم حتما ما مسئولیتهایمان مشخص و از هم تفکیک شده است.
بحث به ترتیب ‌Bean Provider
Assembler
Deployer
Administrate
وجود داره و کاملا کار هر کدامشون مشخص است که اگر باز علاقه داشتید من بیشتر در مورد آنها صحبت می کنم.
اما باز به نکته خوبی اشاره کردن آقای mazdadoost که استفاده از xml ها در ejb3 وجود داره با وجود annotation ها. اما بصورت Optional و در صورت استفاده با اولیت بالاتر نسبت به Annotation ها.
لازم به ذکر است که خود Spring هم داره می ره به سمت Annotation می تونید توی سایتش بخونید.

اما اینکه گفته شده امروزه پروژه ها داره به سمت NET. می ره. سوال من اینکه چه پروژه هایی در کجا و در آخر این امار رو از کجا آوردید؟ برای مثال مگر یک بانک می تونه بیاد به OS ویندوز اطمینان کنه که بخواد از تکنولوژی NET. استفاده کنه.؟ شایدم تازگی ها IIS روی سان سلاریس یا روی دیگر platform ها نصب می شه. من نمی دونم؟

دوست عزیز:
1-در مورد مقایسه امکانات موجود در EE6 مثلا EJB3 و امکانات Spring با استناد به جملات خودتون متاسفانه یا جانب انصاف رو رعایت نکردین یا بر اساس اطلاعات نادرست قضاوت کردین:
*)هیچ فرقی بین Spring و EJB3 در استفاده از به اصطلاح Plain Old Java Object یا POJO نیست.اگر کمی با Spring آشنایی داشتید میدونستید که پترن DI یا به عبارت قدیمی ترش Inversion Of Control یا IOC خیلی قبلتر از EJB3 در همین Spring شروع به کار کرد!و همچنان هم Spring همین POJO ها با همین DI کار میکنه.پس مطمئن باشید EJB3 اگه نگیم کاملا تا حد خیلی زیادی وامدار و مدیون Spring هست.
اصولا فلسفه Spring هم ایجاد یه جاگزین سبکتر از EJB بوده که بدون نگرانی از بابت امکانات نرم افزاری و سخت افزاری که برای EJB ها لازمه بشه با مثلا چیزی مثل Tomcat هم امکانات EJB ها رو داشت.همونطور که EJB ها چه Entiti ها و چه Session ها کامپوننت هایی هستند که توسط کانتینر EJB کنترل میشن (Life Cyle Mangment-Trancication-persistence)در Spring هم همه این فرایند ها ممکنه(Applicatin Contex).و تازه به نظر من AOP بیس بودن تراکنش های Spring خیلی رهیافت نوین تری هست و خیلی به اصطلاح declarative تر!و همون سختی هایی که در ورژن های قبلی EJB بوده در تمام امکانات EE بوده(JDBC-JPA-JAAS-RPC-WEB Service-JMS و....)Spring برای تمام Stack جاوا EE جایگزین های ساده تری داشته.در واقع spring یه Full Stack EE Frameworkr که نه تنها شامل امکانات EJB ها بلکه تمامی لایه های EE میشه.و بنده درک نمی کنم چطور شما Struts رو میارید و به جای EJB میذارید!؟به نظر شما MVC همون Service layer هست؟همون Component Managmet هست!اما با توجه به اینکه فرمودین تو ایران اینطوریه چندان هم دور از انتظار نیست که Controler و View های Struts کلا کار EJB ها رو انجام بدن!
پس همون شعار هایی که الان EJB 3 با کلی تاخیر (با تشکر از گوش بزنگی سان !)میده خیلی وقته که Spring داره میده و خوبم از پسش بر اومده و با هزینه های کمتر (Scale-Team Training-Licence-mature)!(راستی این Pattern ی که به عنوان POJO مطرح فرمودین بنده در کل Course های EE Pattern خودم ندیدم!).
2-در مورد بحث Annonation و Metadate ووو ربطی با موظوع نمی بینم.با این حال همونطور که عرض کردم برای یه توسعه دهنده فرقی نمی کنه که از چی استفاده کنه (همش از نظر من حمالیه حد اقل تا الان در قرن بیست و یکم و بقول Ajaxian :بعد از مدها ما هنوز با دستامون کد مینویسیم!).دو پارادایم Tons Of XML و یا XLL Hell و Tons Of Annonation یا Annonation Hell راحتی واقعی کار با EE رو به چالش کشیدن(هر دو مزایا و معایب خودشون رو دارند و اونقدر ها هم راحت نیستند به هر حال کسی برای ee و سازمان ها برنامه مینویسه قرار نیست که زندگی SS..EE..XX ای داشته باشه!).اگه قبلا در EJB باید کلی کلاس و انترفیس می نوشتید و بعد با XML به کانتینر معرفیش میکردین این مشکل در Spring حل شد!بعد ها دیر تر در EJB به زبان دیگه ای حل شد.(حجم کار در هر دو یه اندازس :در Spring بین ها رو تعریف میکنیدو در هم به اصطلاح Inject میکنید در EJB , EJB ها رو با Annonation به کانتینر معرفی میکنید و با Annonation هم Resourcr ها رو به سایر اجزاء سیستم معرفی میکنید!).پس بهتره به جای جانبداری روی اینکه کدوم بهتره توجهمون رو روی چیزی معطوف کنیم که اوضاع رو از این هم ساده تر کنه!
3-لایه های مدیریت پرژه در EE مثل یه چاقوی دو لبه عمل میکنه برای تیم های با بودجه بالا و قوی (Match) خوبه ولی برای تیم هایی که قدرت کمتری دارند مشکل زاست.
در دنیای امروز پول حرف نهایی و میزنه!سری به اینتر نت بزنید و ببینید که چطور جایگزین های EE مثل دات نت رابی Php وغیره به چه نسبت برای توسعه نیاز به تیم های کوچکتری برای پروژه هایی با یک سایز دارند!قضاوت رو به خودتون میسپارم(Petstore دات نت و EE.یا Document managmet های EE با نمونه PHP!)!برای بقاء در این همه آلترناتیو EE باید سعی بیشتری کنه!به نظر شما چه کار هایی؟

4-و در آخر چند کلمه ای در مورد دات نت و ویندوز !
بهتره اول به این مسئله نگاه کنیم که پردازش اطلاعات در سطوح سازمانی چه برنامه هایی رو در بر میگیره!همه تجارت ها و خدماتی که از شرکت ها برای مطرح کردن خودشون در شبکه دارند جزئی از پردازش سازمانیه!از سایت های تجارت الکترونیک تا پرتال ها تا بانکها تا شبکه های اجتماعی همگی به نحوی با این پردازش درگیرن!
با نظر شما اینها ایت های کوچکی هستند؟
Dell (www.Dell.com), MySpace (www.MySpace.com),
Microsoft (www.Microsoft.com).Google(www.goog;e.com) .فقط همین دل به شما قول میدم سایز و میزان تراکنش هاش از کل شبکه بانکی ایران وخیلی اسیایی ها بیشتره!بله از دات نت استفاده میکنه!و گوگل هم!همه اینه ها حتی مایکروسافت هم علاوه بر ویندوز از لینوکس هم استفاده میکنه!و گوگل از ویندوز و لینوکس و سولاریس!و دل و یاهو. از Php!و IBM سری MQ خودش رو برای دات نت هم آماده کرده و سان کتاب منتشر میکنه که چطور بین دات نت و EE رابطه برقرار میشه کرد و ناول پروژه دات نت رو روی Linux با Mono ادامه میده و اتفاقا به مزاج لینوکسی ها هم خوش میاد و کلی اجتماعات براش درست میکنند و ویرچوالیزشن داره با رشد دامنگیر خودش همه چیز های خوبی که در پلت فرم های مختلف از لینوکس گرفته تا وینوز تا مین فریم ها و همزییستی برنامه های سپ با اراکل و دات نت و ee محقق میکنه پس اصلا بعید نیست روی لینوکس دات نت که هیچ کل ویندوز اجرا بشه! ووو این حکایت بده بستونی که میگه هر چیز به جای خویش نیکوست!
و اما در بعضی جاها هم اشخاصی هستند که اعتقادات خودشون رو دارند!
در همین ایران نقل همکارای واقعی خودم:یکی iPhon میخره میگه Symbian و Winmobile آشغاله!امنیت نداره!همش ویروسی میشه!فرداش میبینمش که میگه :خودش خراب شد!چیزش هم روش نریختم!
یکی لینوکس کار میکنه :امر بش مشتبه میشه که فنی ترین آدم روی زمینه که داره OS کار میکنه.و میدونه لینوکس خیلی امنه(شرکت هایی هم که وقتشون رو برای تهیه راه کار های امنیتی لینوکس مثل Macafee ,panda ,symantec ووو صرف میکنن وقتشون رو تلف می کنن چون لینوکس خیلی امنه یا شرکتی با سایز اوراکل سان ادبی سپ ووو و همینطور مصرف کنند گانشون هیچ درکی از امنیت ندارند!ولا وقتو پولشون رو برای تهیه و خرید محصولاتی به این مهمی برای سیستم عامل مبتذلی مثل ویندوز نمی کردند.بعد پیش خودشون به این نتیجه میرسند که ای بابا ان مایکروسافت عجب شرکت نامردی ها!هر چی پوله معلوم نیست در میاره از کجا و ویندوزش هم که آشغاله و تمام محصولاتش که برای ویندوزند هم چون محیط امنی ندارند وقت طلف کردن هستند و لابد میکروسافت با خوردن حق لینوکس و بقیه بزرگترین شرکت نرم افزاری دنیاست!)پس زنده باد لینوکس!
یکی iMac میگیره میگه...به امید روزی که بتونبم در کنار هم جدا از تعصب ها و با درکی بدون آمیختگی با هر گونه تعصب زندگی کنیم.
موفق باشی.

javaphantom
جمعه 24 خرداد 1387, 10:42 صبح
اگر شروع کنی که ممنون میشم.



من خیلی با تصمیماتی که Interface21 می گیره موافق نیستم ولی در کل هم نمی توانم ردشون کنم و بحث مربوطه در مورد وجود xml ها هم قبول دارم ولی هنوز برنامه نویسها می توانند به اشتباه از یکی استفاده کنند. در کل من نمی توانم بطور جدی با annotation ها مخالفت کنم ولی به مقدار زیادی با روشی که استفاده می شوند مشکل دارم و تقریبا این اشکال رو از خیلی تکنولوژی ها می شود گرفت. به عنوان مثال از چیزهایی که تو شرکتهای نسبتا قوی دیدم این بود که اطلاعات دیتابیس توی annotation بود و کلا بعد کامپایل کردن راهی نبود که عوض بشه و خوب چیزهای مشابه این.



فرزاد-

همانطور که قبلا اشاره کردم یکی از دلایلی که امروزه کمتر به سراغ تکنولوژی جدید می آیند کمبود نیرویی است که تسلط کامل به تکنولوژی جدید داشته باشند.
یکی از ایرادهایی که امروزه من می شنوم که خیلی از دوستان که متوسفانه همگی با تجربه هم هستد نسبت به کارشون مخصوصا در قسمت jee اینکه است که همگی به اتفاق می گویند annotation کامپایل می شه و دیگه هیچ کاریش نمی شه کرد و بقولی flexibility رو از بین می بره و در صورتی که بخواهیم تغییر در کار بدیم باید به سراغ ساختار برنامه بریم که کلی دردستر ایجاد می کنه.
همانطور که گفتم وجود xml از ejb3 حذف نشده و درصورت نیاز شما می توانید از آن استفاده کنید و نکته دوم که مهمترین آن است این است که وجود xml نسبت به annotation اولیت دارد یعنی در صورتی که بخواهید در برنامه خود که قبلا با annotation نوشته شده تغییر ایجاد کنید نیازی به این نیست که حتما سراغ ساختار برید xml مربوطه را درست کنید انگار نه انگار که annotation ی وجود داشته.
اما چرا annotation. من خود بر خلاف شما بسیار به annotation علاقه مندم و راحتی آن در فهم بالا بردن سرعت در هنگام Runtime حلاصه بود سرعت بالای پیاده سازی و در نهایت امنیت اون رو نسبت به xml ترجیج می دم. این نظر شخصی من است و باید بگم من خودم خیلی جاها از روی اجبار هم نه از روی دلخواه از xml استفاده می کند.

تشخیص اینکه واقعا کجا و کی از annotation و کجا ازxml استفاده به شود بر می گرده به مستولیت assembler که یک دید کلی تر نسبت به architecture در ejb3 داره.
امروزه همه با وب سرویس دارن کار می کنند و بحث معماری سرویس ارینتد (SOA) همجا وجود داره. یکی از راه حل هایی که برای ایجاد این ارتباط وجود داره WSDL یا همان web service difination language هست که اکثرا بر پایه و اساس xml فایل است یعنی یکی از راه حل هایی که بتوانند زبانی درست کنند که به شود یک وب سرویس را ایجاد کنه برا اساس xml فایل است که از طریق xml فایل ایجاد این ارتباط می شه. ۱۰۰٪ کسانیکه به ant کار کردند منظور من و می فهمند. اما در ejb3 با استفاده از یک خط کوچک یعنی یک annotation دیگر نه نیازی به ant و نه نیازی به یک فایل یا چند فایل حجیم و عظیم و نا خوانای xml است.
سرعت develop بالا می ره. خوانایی بیشتر و راحتی کار. من می تونم به جراعت بگم که اسفاده از annotation برای ساختن framework هایی از جمله ejb3 بسیار بجا و اصولی وباعث قدرتمندتر شدن آن شده است.

javaphantom
جمعه 24 خرداد 1387, 10:59 صبح
دوست عزیز:
1-در مورد مقایسه امکانات موجود در EE6 مثلا EJB3 و امکانات Spring با استناد به جملات خودتون متاسفانه یا جانب انصاف رو رعایت نکردین یا بر اساس اطلاعات نادرست قضاوت کردین:
*)هیچ فرقی بین Spring و EJB3 در استفاده از به اصطلاح Plain Old Java Object یا POJO نیست.اگر کمی با Spring آشنایی داشتید میدونستید که پترن DI یا به عبارت قدیمی ترش Inversion Of Control یا IOC خیلی قبلتر از EJB3 در همین Spring شروع به کار کرد!و همچنان هم Spring همین POJO ها با همین DI کار میکنه.پس مطمئن باشید EJB3 اگه نگیم کاملا تا حد خیلی زیادی وامدار و مدیون Spring هست.
اصولا فلسفه Spring هم ایجاد یه جاگزین سبکتر از EJB بوده که بدون نگرانی از بابت امکانات نرم افزاری و سخت افزاری که برای EJB ها لازمه بشه با مثلا چیزی مثل Tomcat هم امکانات EJB ها رو داشت.همونطور که EJB ها چه Entiti ها و چه Session ها کامپوننت هایی هستند که توسط کانتینر EJB کنترل میشن (Life Cyle Mangment-Trancication-persistence)در Spring هم همه این فرایند ها ممکنه(Applicatin Contex).و تازه به نظر من AOP بیس بودن تراکنش های Spring خیلی رهیافت نوین تری هست و خیلی به اصطلاح declarative تر!و همون سختی هایی که در ورژن های قبلی EJB بوده در تمام امکانات EE بوده(JDBC-JPA-JAAS-RPC-WEB Service-JMS و....)Spring برای تمام Stack جاوا EE جایگزین های ساده تری داشته.در واقع spring یه Full Stack EE Frameworkr که نه تنها شامل امکانات EJB ها بلکه تمامی لایه های EE میشه.و بنده درک نمی کنم چطور شما Struts رو میارید و به جای EJB میذارید!؟به نظر شما MVC همون Service layer هست؟همون Component Managmet هست!اما با توجه به اینکه فرمودین تو ایران اینطوریه چندان هم دور از انتظار نیست که Controler و View های Struts کلا کار EJB ها رو انجام بدن!
پس همون شعار هایی که الان EJB 3 با کلی تاخیر (با تشکر از گوش بزنگی سان !)میده خیلی وقته که Spring داره میده و خوبم از پسش بر اومده و با هزینه های کمتر (Scale-Team Training-Licence-mature)!(راستی این Pattern ی که به عنوان POJO مطرح فرمودین بنده در کل Course های EE Pattern خودم ندیدم!).
2-در مورد بحث Annonation و Metadate ووو ربطی با موظوع نمی بینم.با این حال همونطور که عرض کردم برای یه توسعه دهنده فرقی نمی کنه که از چی استفاده کنه (همش از نظر من حمالیه حد اقل تا الان در قرن بیست و یکم و بقول Ajaxian :بعد از مدها ما هنوز با دستامون کد مینویسیم!).دو پارادایم Tons Of XML و یا XLL Hell و Tons Of Annonation یا Annonation Hell راحتی واقعی کار با EE رو به چالش کشیدن(هر دو مزایا و معایب خودشون رو دارند و اونقدر ها هم راحت نیستند به هر حال کسی برای ee و سازمان ها برنامه مینویسه قرار نیست که زندگی SS..EE..XX ای داشته باشه!).اگه قبلا در EJB باید کلی کلاس و انترفیس می نوشتید و بعد با XML به کانتینر معرفیش میکردین این مشکل در Spring حل شد!بعد ها دیر تر در EJB به زبان دیگه ای حل شد.(حجم کار در هر دو یه اندازس :در Spring بین ها رو تعریف میکنیدو در هم به اصطلاح Inject میکنید در EJB , EJB ها رو با Annonation به کانتینر معرفی میکنید و با Annonation هم Resourcr ها رو به سایر اجزاء سیستم معرفی میکنید!).پس بهتره به جای جانبداری روی اینکه کدوم بهتره توجهمون رو روی چیزی معطوف کنیم که اوضاع رو از این هم ساده تر کنه!
3-لایه های مدیریت پرژه در EE مثل یه چاقوی دو لبه عمل میکنه برای تیم های با بودجه بالا و قوی (Match) خوبه ولی برای تیم هایی که قدرت کمتری دارند مشکل زاست.
در دنیای امروز پول حرف نهایی و میزنه!سری به اینتر نت بزنید و ببینید که چطور جایگزین های EE مثل دات نت رابی Php وغیره به چه نسبت برای توسعه نیاز به تیم های کوچکتری برای پروژه هایی با یک سایز دارند!قضاوت رو به خودتون میسپارم(Petstore دات نت و EE.یا Document managmet های EE با نمونه PHP!)!برای بقاء در این همه آلترناتیو EE باید سعی بیشتری کنه!به نظر شما چه کار هایی؟

4-و در آخر چند کلمه ای در مورد دات نت و ویندوز !
بهتره اول به این مسئله نگاه کنیم که پردازش اطلاعات در سطوح سازمانی چه برنامه هایی رو در بر میگیره!همه تجارت ها و خدماتی که از شرکت ها برای مطرح کردن خودشون در شبکه دارند جزئی از پردازش سازمانیه!از سایت های تجارت الکترونیک تا پرتال ها تا بانکها تا شبکه های اجتماعی همگی به نحوی با این پردازش درگیرن!
با نظر شما اینها ایت های کوچکی هستند؟
Dell (www.Dell.com), MySpace (www.MySpace.com),
Microsoft (www.Microsoft.com).Google(www.goog;e.com) .فقط همین دل به شما قول میدم سایز و میزان تراکنش هاش از کل شبکه بانکی ایران وخیلی اسیایی ها بیشتره!بله از دات نت استفاده میکنه!و گوگل هم!همه اینه ها حتی مایکروسافت هم علاوه بر ویندوز از لینوکس هم استفاده میکنه!و گوگل از ویندوز و لینوکس و سولاریس!و دل و یاهو. از Php!و IBM سری MQ خودش رو برای دات نت هم آماده کرده و سان کتاب منتشر میکنه که چطور بین دات نت و EE رابطه برقرار میشه کرد و ناول پروژه دات نت رو روی Linux با Mono ادامه میده و اتفاقا به مزاج لینوکسی ها هم خوش میاد و کلی اجتماعات براش درست میکنند و ویرچوالیزشن داره با رشد دامنگیر خودش همه چیز های خوبی که در پلت فرم های مختلف از لینوکس گرفته تا وینوز تا مین فریم ها و همزییستی برنامه های سپ با اراکل و دات نت و ee محقق میکنه پس اصلا بعید نیست روی لینوکس دات نت که هیچ کل ویندوز اجرا بشه! ووو این حکایت بده بستونی که میگه هر چیز به جای خویش نیکوست!
و اما در بعضی جاها هم اشخاصی هستند که اعتقادات خودشون رو دارند!
در همین ایران نقل همکارای واقعی خودم:یکی iPhon میخره میگه Symbian و Winmobile آشغاله!امنیت نداره!همش ویروسی میشه!فرداش میبینمش که میگه :خودش خراب شد!چیزش هم روش نریختم!
یکی لینوکس کار میکنه :امر بش مشتبه میشه که فنی ترین آدم روی زمینه که داره OS کار میکنه.و میدونه لینوکس خیلی امنه(شرکت هایی هم که وقتشون رو برای تهیه راه کار های امنیتی لینوکس مثل Macafee ,panda ,symantec ووو صرف میکنن وقتشون رو تلف می کنن چون لینوکس خیلی امنه یا شرکتی با سایز اوراکل سان ادبی سپ ووو و همینطور مصرف کنند گانشون هیچ درکی از امنیت ندارند!ولا وقتو پولشون رو برای تهیه و خرید محصولاتی به این مهمی برای سیستم عامل مبتذلی مثل ویندوز نمی کردند.بعد پیش خودشون به این نتیجه میرسند که ای بابا ان مایکروسافت عجب شرکت نامردی ها!هر چی پوله معلوم نیست در میاره از کجا و ویندوزش هم که آشغاله و تمام محصولاتش که برای ویندوزند هم چون محیط امنی ندارند وقت طلف کردن هستند و لابد میکروسافت با خوردن حق لینوکس و بقیه بزرگترین شرکت نرم افزاری دنیاست!)پس زنده باد لینوکس!
یکی iMac میگیره میگه...به امید روزی که بتونبم در کنار هم جدا از تعصب ها و با درکی بدون آمیختگی با هر گونه تعصب زندگی کنیم.
موفق باشی.

از اینکه وقت گذاشتید و ین گونه کامل پاسخ منو دادید متشکرم.
در مورد spring و ejb3‌همین رو متذکر می شم و بحث رو تمام می کنم که spring یک فریم ورک استاندارد نیست. با تمام قابلیتهای آن که من آن را قبول دارم. درصورتی که ejb3 استاندارد خود سان هست.
اما POJO یا همان Plain Old Java Object شما کاملا درست می گید یک pattern نیست و من اشتباها در پست قبلیم کلمه Pattern جلوش گذاشتم و منظور من نسبت به مقایسه با ejb2.X بود که شعار ejb3 استفاده از یک فایل معمولی جاوا برای راحتی کار و روی آوردن به خود سان است که همانطور که گفته شده همه از وحشت و سخت بودن کار در نسخ قبلی و روفتن به سوی spring, struts برگردن سراغ خود ماهیت و استاندارد جاوا.
در مورد اجرایی شدن پروژه ها حالا از طریق کدام تکنولوژی و یا کدام ساختار من به هیچ عنوان با شما بحث نمی کنم چون این مسئله بر می کرده به تیم تحلیل گر- معمار- مدیریت و وو که درباره این مسئله صحبت کردن ربطی به اینجا نداره و اصلا همانطور که گفتم اشتباست. من فقط این برام جالب بود که بدونم از کدام کجا و کدام سایت رسمی اعلام شده که برنامه های سازمانی که امروز در سطح دنیا داره ایجاد می شه روند به سوی Microsoft یا هر شرکت یا تکنولوژی دیگر دارد. و واقعا برای من جالبه بدونم که مخصوصا ماکروسافت با اون معماری ضیفی که در قست web داره نسبت به سان چه جوری می خواد در مقابل معماری و تکنولوژی های سان مقابله کنه. لازم به ذکر است که بیش از ۳۰۰ شرکت IT دنیا دارن با سان همکاری می کنند. ازجمله IBM Apple Nokia,,,,,,,,,,

mazdadoost
شنبه 25 خرداد 1387, 10:58 صبح
دوستان عزیز :
با تشکر از توجهتون به تاپیک.
فکر میکنم بحث هامون در مورد استاندارد ها(Official و Deffacto) تا حدی به نتیجه رسیده.همونطور که javaphantom گفت اینجا بحثی روی ترجیح روی کدام تکنولوژی نیست.هدف انتظارات ee کار ها از ورژن اتیه Ee هست.مینونیم بحث راجع به فریم ورک ها رو در این تاپیک ادامه بدیم(http://barnamenevis.org/forum/showthread.php?t=104473).
راستی نه تنها شرکت های ای تی و غیر IT ی بزرگی دارند با سان همکاری راهبردی میکنند بلکه 1000 شرکت برتر فورچن هم دارند از جاوا استفاده می کنند.ولی همین شرکت ها اغلب با میکروسافت هم همکاری های راهبردی دارند.و جاوا با بوجود اینکه انتخاب اول سازمان هاست منتها همونطور که قبلا هم گفتم دات نت هم داره با سرعت زیادی رشد میکنه.به نظرم یکی از دلیل هاش اینه که کپی برداری از خود جاواست به علاوه اسان کردن چیز هایی که جاوا کار ها رو اذیت میکنه.حالا بحث من اینه که چرا خود جاوا و سان نیان و این نقاط سخت رو پوشش بدن!همین.در رابطه با آمار هم مجله فورچن رو نگاهی بمندازید ما در شرکت داریم منتها اون نسخش ماله سال پیش بود در دسترسم نیست.میتونید سری به سایت http://www.dice.com
بزنید و نتیجه جستجو برای مشاغل دات نت و EE رو مقایسه کنید.به نظر شما این همه شغل برای دات نت نشون دهنه پروژه هایی نیست که برای پیشرغت به ئات نت کار نیاز دارند!؟البته میشه اینطور هم فکر کرد که مشاغل IT برای Java پر شدن و بازارش اشباح شده .اما باز هم میتونیم نتیجه بگیریم که دات نت در حال پیشرفت در سازمان هاست!دات نت که فقط ASP .net نیست!کلی راح حل های جامع مایکروسافت باش یکپارچه شدن!(Exchange سرور محبوب همه سازمان ها-شر پوینت-افیس -ووووو)
لینک سرچ برای EE:
http://seeker.dice.com/jobsearch/servlet/JobSearch?op=300&LOCATION_OPTION=2&AREA_CODES=&ZIPCODE=&RADIUS=64.37376&COUNTRY=&METRO_AREA=33.78715899%2C-84.39164034&TRAVEL=0&SORTSPEC=0&FRMT=0&DAYSBACK=30&NUM_PER_PAGE=30&N=0&FREE_TEXT=java+ee&Ntx=mode+matchall&x=0&y=0
لینک سرچ برای دات نت:
http://seeker.dice.com/jobsearch/servlet/JobSearch?op=300&N=0&Hf=0&NUM_PER_PAGE=30&Ntk=JobSearchRanking&Ntx=mode+matchall&AREA_CODES=&AC_COUNTRY=1525&QUICK=1&ZIPCODE=&RADIUS=64.37376&ZC_COUNTRY=0&COUNTRY=1525&STAT_PROV=0&METRO_AREA=33.78715899%2C-84.39164034&TRAVEL=0&TAXTERM=0&SORTSPEC=0&FRMT=0&DAYSBACK=30&LOCATION_OPTION=2&FREE_TEXT=microsoft+.net&WHERE=&SEARCH.x=0&SEARCH.y=0
موفق باشید.

javaphantom
شنبه 25 خرداد 1387, 12:47 عصر
دوستان عزیز :
با تشکر از توجهتون به تاپیک.
فکر میکنم بحث هامون در مورد استاندارد ها(Official و Deffacto) تا حدی به نتیجه رسیده.همونطور که javaphantom گفت اینجا بحثی روی ترجیح روی کدام تکنولوژی نیست.هدف انتظارات ee کار ها از ورژن اتیه Ee هست.مینونیم بحث راجع به فریم ورک ها رو در این تاپیک ادامه بدیم(http://barnamenevis.org/forum/showthread.php?t=104473).
راستی نه تنها شرکت های ای تی و غیر IT ی بزرگی دارند با سان همکاری راهبردی میکنند بلکه 1000 شرکت برتر فورچن هم دارند از جاوا استفاده می کنند.ولی همین شرکت ها اغلب با میکروسافت هم همکاری های راهبردی دارند.و جاوا با بوجود اینکه انتخاب اول سازمان هاست منتها همونطور که قبلا هم گفتم دات نت هم داره با سرعت زیادی رشد میکنه.به نظرم یکی از دلیل هاش اینه که کپی برداری از خود جاواست به علاوه اسان کردن چیز هایی که جاوا کار ها رو اذیت میکنه.حالا بحث من اینه که چرا خود جاوا و سان نیان و این نقاط سخت رو پوشش بدن!همین.در رابطه با آمار هم مجله فورچن رو نگاهی بمندازید ما در شرکت داریم منتها اون نسخش ماله سال پیش بود در دسترسم نیست.میتونید سری به سایت http://www.dice.com
بزنید و نتیجه جستجو برای مشاغل دات نت و EE رو مقایسه کنید.به نظر شما این همه شغل برای دات نت نشون دهنه پروژه هایی نیست که برای پیشرغت به ئات نت کار نیاز دارند!؟البته میشه اینطور هم فکر کرد که مشاغل IT برای Java پر شدن و بازارش اشباح شده .اما باز هم میتونیم نتیجه بگیریم که دات نت در حال پیشرفت در سازمان هاست!دات نت که فقط ASP .net نیست!کلی راح حل های جامع مایکروسافت باش یکپارچه شدن!(Exchange سرور محبوب همه سازمان ها-شر پوینت-افیس -ووووو)
لینک سرچ برای EE:
http://seeker.dice.com/jobsearch/servlet/JobSearch?op=300&LOCATION_OPTION=2&AREA_CODES=&ZIPCODE=&RADIUS=64.37376&COUNTRY=&METRO_AREA=33.78715899%2C-84.39164034&TRAVEL=0&SORTSPEC=0&FRMT=0&DAYSBACK=30&NUM_PER_PAGE=30&N=0&FREE_TEXT=java+ee&Ntx=mode+matchall&x=0&y=0
لینک سرچ برای دات نت:
http://seeker.dice.com/jobsearch/servlet/JobSearch?op=300&N=0&Hf=0&NUM_PER_PAGE=30&Ntk=JobSearchRanking&Ntx=mode+matchall&AREA_CODES=&AC_COUNTRY=1525&QUICK=1&ZIPCODE=&RADIUS=64.37376&ZC_COUNTRY=0&COUNTRY=1525&STAT_PROV=0&METRO_AREA=33.78715899%2C-84.39164034&TRAVEL=0&TAXTERM=0&SORTSPEC=0&FRMT=0&DAYSBACK=30&LOCATION_OPTION=2&FREE_TEXT=microsoft+.net&WHERE=&SEARCH.x=0&SEARCH.y=0
موفق باشید.

n هزار بار این بحث اینجا مطرح شده که نمی دونم NET. بهتره یا جاوا من هیچ دلم نمی خواد زیاد توی این فروم موضوع مطرح کنم هی شما من و وادار می کنی. دوست عزیز مهندسی نرم افزار مبتنی براستفاده از تکنولوژی نیست. ۳۰ سال پیش با cobol برنامه می نوشتن الان با NET. چه می دونم ۳۰ سال دیگه یک تکنولوژی جدید یک زبان جدید و و وو حالا من بیام سخنی درباب جاوا بگم یا برم C# یاد بگیرم فکرکنم استاد شدم. گوربای ماکروسافت و سان ماکروسیستم. اینجا اومدی بحث فریم ورک می کنی یک مشت لینک هم پشت سرم می زاری چند تا متنم ترجمه می کنی دمت گرم که می کنی این کارو بعد یهو می پری سر کاریابی NET. بیشتر نسبت به جاوا.عمل مقایسه موقعی معنی می ده که بابا طرف توی کارش به صورت تجربی با چندتا فریم ورک کار کرده باشه بیاد بگه این اینجا خوبه او اونجا بده. اومدی مقایسه تئوری می کنی من گفتم اگر اینجوری بخوای حساب کنی آدم می ره دنباله خود جنس نه بدلش. بعدش آمارایی که می دی خیلی هاش رسمی نیست و یا اصلا آمار نمی دی. توی چند پست قبلیت گفتی پروژه ها همه داره به سمت NET. می ره گفتم از کجا می گی رفتی اسم ۴ تا سایت برای من زدی که اینا با NET. پیاده سازی شده. این شد دلیل. خوب منم می گم yahoo با php درست شده. ولی وقتی می ری عمق قضیه رو نگاه می کنی می بینی بابا yahoo بیشتر از ۱۰ دلیل داشته که مثلا سیستم عاملشو BSD گرفته از زبان php استفاده کرد و فلان معماری رو انتخاب کرده و از این تکنولوژی استفاده کرده.
ایران که نیست که طرف یک چیزی شنیده C# یک کلاس مجتمع فنی هم رفته یک مدرک مهندسی هم گرفته که اکثرا اونم ندارن بعد می خواد هرچی میاد جلوی دستش بگه با C# پیاده سازی بشه. شما آمار fail شدن پروژهایی که با همین NET. , VB و C# توی این مملکت هست رو دارید. مگر ما چندتا پروژه سازمانی داشتیم که بخواهیم با جاوا کار کنیم یا سراغ معماری J2EE بریم. وقتی صحبت از پروژه سازمانی می کنیم یعنی خیلی چیزهای دیگر روداریم که باید در نظر بگیرم. آیا شما می دونید بحث و وجود IT و Service Oriented مدیون همین پروژهای سازمانی هست. آیا می دونیم ایران جیزی به اسم IT نداره. کل بوجه و امکاناتی که برای IT ایران هزینه شده آماری که پارسال خودشون توی اخبار اعلام کرد کلا حدود ۵۰۰ ملیون دلار بوده از اول تا همون پارسال. آیا می دونه فقط google یک شرکت از شرکتهای آمریکایی utube رو ۱.۲ میلیارد دلار خریده. مملکتی که وزیر امور ارتباطاتش چند وقت پیش اعلام کرده که سرعت اینترت ۱۲۸ برای خونه ها و کاربرهای معمولی بسیار زیاده و می تونه یک دانشگاه از اون استفاده کنه و اضافه کردن که من یعنی خودشون در زمان دانشجوییم دیدم تازه ایشون دیدن که با ۳ کلیلوبایت هم در محیط text می شه کار کرد. معلومه که همه توی این مملکت می رن سمت .NET. می خواستی برات پایتون کارآگهی بدن. اینجا تا می گن چی کار کنیم خوب کد بزنیم. با چی کار کنیم؟ چی با کلاستره.اگر داری درحال حاضر در مورد تکنولوژیهایی که برای نرم افزارهای سازمانی استفاده می شه صحبت می کنی ejb حرفه اول رو می زنه چه خوشت بیاد چه نیاد. تازه بقوله خودت ماکروسافت داره می ره که رشد کنه. اونم چیزیش به جیبه من و تو نمی ره. تازه تحریم هم هستیم. ویندوز قلابی و لت و پار شده توی پایتخت و بازارچه رضا بد جوری روی اخلاق مردم حلال دوست و حلال خور ایران تاثیر گذاشته. اگر یک بار ۱۰۰ دلار برای همون سیستم عاملت که تازه بازم پراز باگ کرم و ویروس هست و باید کلی دیگه هزینه برای نگهداریش کنی می پرداختی اون موقع وقتی می خواستی از بقیه تکنولوژیهاش استفاده کنی تازه می فهمیدی که چقدر وابسته به پشتیانی بی خود این بابا هستی.الان هم می گم استفاده از تکنولوژی به معنای مهندسی نرم افزار نیست. من و ببخش که تند صحبت می کنم ولی خودت ببین هیچ کس توی این قست صحبت نو و تازه ای نداشت. من می خواستم چند نمونه کد از spring و ejb3 بیارم و در موردش صحبت کنم هر چند که می دونستم ۲ یا ۳ نفر بیشتر از این مسئله استفبال نخواهند کرد ولی همون بهتر که ادامه بحث رو توی همون لینکی که دادی ادامه بدی.

mazdadoost
شنبه 25 خرداد 1387, 14:47 عصر
javaphantom:
1-بنده نگفتم جاوا بهتره یا دات نت.فقط مقایسه.نتیجه گیری رو به عهده خوانندگان میذارم.و شما.بنده کی گفتم همه پروژه ها داره به سمت دات نت میره؟
2-یه مشت لینک؟ترجمه؟اگر با لینک ها مشکل دارید بشون توجه نکنید.اگر شما علمی دارید بنده نمی دونم از کجا کسب کردین ولی من نتونستم از Paper های فارسی استفاده کنم .هر چی یاد گرفتم نتیجه 12 سال کار و مطالعه و زندگی با جاواست.خوب ترجمه هم از محفوضاتم میکنم!(خوش به حالت که علم لدنی داری و از بدو تولد جامع علوم Software بودید و هستید و انشا .. خواهبد بود همه که مثل شما چنین سعادتی و ندارند!)
3-مهندسی نرم افزار؟واقعا چه ربطی داره؟
4-شما رو نمیدونم ولی من در شرکتی هستم که زیز مجموعه متمول ترین شرکت ایرانه!خیلی قبل تر از اینکه حرف جاوا در میون جامعه اینترنتی ایران مطرح بشه این شرکت طالب جاوا بوده و باش پروژه پیش می برده و میبره و خواهد برد.و آدم هایی مثل من هم از برکت همین کار و پیشه زندگی میکنند.اینکه فرمودین استفاده از فریم ورک و دات نت و استادی و تجربه و....گز نکرده پاره کردی جانم.کسی در مورد استادی دیگران اظهار نظر میکنه که خودش رو خیلی استاد میدونه وملاک هاتون هم که گفتین پس حالا قضاوت کنید کی استاده!
5-مقایسه تئوری؟کار عملی .بنده طبق تجربیاتم تو همین ایران هر چی گفتم بوده.(جالبش اینجاست که واقعا نمیدونم کی گفتم همه باید برن با فرعش که مثلا Spring ه کار کنن نه اصلش که EJB و ....).شاید شما جایی باشید که همه ادعای فلان چیزو دارند و کدینگ رو بش می گن کد زدن(مگه گارگاه خشت زنیه!بله حتما نشونه اوج مهارت در فرایند خطیر حمالیه!)و اینقدر هم روش تکیه می کنند.و پروژه IT ش فلان هزینست و هرکی بیسواده رفته مجتمع فنی و هر کی جاوا بلده ول معطله چون کسی توایران JavaEE رو برای پروژه هاش انتخاب نمی کنه و مردمش ویندوز قلابی میخرن و لینوکس کاراش نهایت دانش و فظلند و ووو ولی بنده در جایی کار میکنم که مجبوره با استاندارد های جهانی پیش بره تا ISO برای هر سانتیمتر کارش بگیره تا تو دنیا قبولش داشته باشند.هر چی داره اصلی و پولی حتی Redhat ش رو هم با لایسنس استفاده میکنه(وقتی که کاری باید بشه میشه تحریم چیه.بیا و در عمل ببین!)!نتیجه اینکه اگه اینطوری که شما گفتین وضعیت جاوا و نرم افزار در ایران هست شما هم ول معطلید که دارید جاوا کار میکنید و زور میزنید که بگید EJB خرف اول و آخر و میزنه یخوشت بیاد یا نیاد.ما که داریم از EJB 2 تا حالا ازش پول درمیاریم اینقدر روش تکیه نداریم .روی هر فرم ورک دیگش هم.(بماند وقتی ما RMI کار کردیم با خسارت برای اتوماسیون بعد JMX با خسارت(البته به احتساب زمان) تا الان که به قول شما EJB 3 و Annonation و وووو).حالا شما هی آسمون ریسمون بباف....و اظهار فضل کن!
6-بنده از آمار هایی که میدم هیچ منظوری ندارم جز جلب توجه شما و سایر کسانی که دارند بحثو دنبال میکنند.باور کنید از صمیم قلب دوست دارم که جاوا حرف اول و آخر رو بزنه چون اولین فناوری ای هست که certificate ش رو گرفتم و اولین نرم افزاری که واقعا دوست دارم.از بابت شغل خودم هم خیالم راحته اگه قرار بشه پروژه ای با دات هم انجام بشه مشکلی ندارم.
در آخر باید به خدمتتون برسونم شما تند صحبت نکردین متاسفانه بی ادبانه بود و بیشتر به حال یه بچه تا آدم بزرگسال.و این تایپکرو هم که داشت با تلاش من شما وfkohantorabi به نتیجه میرسید با فرمایشات عالیتون منحرف کردین و بعد به دیگری و مقصر میدونید اگه کمی منصف بودین می دیدید که بنده در هر پستی علاوه بر اینکه سعی کردم بحثو به سمت چیزی که عرض کردم یعنی انتظارات ببرم باید چیز هایی هم که بهنظرم اشتباه میومد یا ناقص بیان شده بود رو اصلاح میکردم تا باعث بدفهمی کسی نشه!شما هم آگر می خواید وقت بذارید و کاری انجام بدبن منتی سر کسی نیست منتها با این بضاعت یه فروم واقعا زحمت میکشید که دو تا از پروژهاتون رو که به Spring و EJB 3 کار کردین سورس و توضیحاتشو اینجا مطرح میکنید و به بیان تجربیات عملیتون که در ایران بسیار هم نادره همت میذارید.(ولی چه فایده در ایران به جز چن پروژه و شرکت هایی که شما فقط میشناسید و کار کردین با EE کار نمیکنند و بدرد 2 3 نفر هم بیشتر نمی خوره و زحمتتون هم بی ارج میمونه!).
حق با آقای انیشتن هست :دوچیز همیشه نا متناهی می باشد یکی برزگی کهکشانها و دومی حماقت بشریت.مخصوصا وقتی ریشه حماقت آدم جهل مرکب باشه!

handinux
شنبه 25 خرداد 1387, 16:31 عصر
ضمن تشکر از دوست عزیز جناب مزدا دوست ، کهن ترابی
اگر لطف کنید بحث را بدون نظر به پست های جفنگ دیگران ادامه بدهید تا یک نتیجه گیری درست و قابل استفاده ار آن داشته باشیم.

javaphantom
شنبه 25 خرداد 1387, 16:36 عصر
javaphantom:
1-بنده نگفتم جاوا بهتره یا دات نت.فقط مقایسه.نتیجه گیری رو به عهده خوانندگان میذارم.و شما.بنده کی گفتم همه پروژه ها داره به سمت دات نت میره؟
2-یه مشت لینک؟ترجمه؟اگر با لینک ها مشکل دارید بشون توجه نکنید.اگر شما علمی دارید بنده نمی دونم از کجا کسب کردین ولی من نتونستم از Paper های فارسی استفاده کنم .هر چی یاد گرفتم نتیجه 12 سال کار و مطالعه و زندگی با جاواست.خوب ترجمه هم از محفوضاتم میکنم!(خوش به حالت که علم لدنی داری و از بدو تولد جامع علوم Software بودید و هستید و انشا .. خواهبد بود همه که مثل شما چنین سعادتی و ندارند!)
3-مهندسی نرم افزار؟واقعا چه ربطی داره؟
4-شما رو نمیدونم ولی من در شرکتی هستم که زیز مجموعه متمول ترین شرکت ایرانه!خیلی قبل تر از اینکه حرف جاوا در میون جامعه اینترنتی ایران مطرح بشه این شرکت طالب جاوا بوده و باش پروژه پیش می برده و میبره و خواهد برد.و آدم هایی مثل من هم از برکت همین کار و پیشه زندگی میکنند.اینکه فرمودین استفاده از فریم ورک و دات نت و استادی و تجربه و....گز نکرده پاره کردی جانم.کسی در مورد استادی دیگران اظهار نظر میکنه که خودش رو خیلی استاد میدونه وملاک هاتون هم که گفتین پس حالا قضاوت کنید کی استاده!
5-مقایسه تئوری؟کار عملی .بنده طبق تجربیاتم تو همین ایران هر چی گفتم بوده.(جالبش اینجاست که واقعا نمیدونم کی گفتم همه باید برن با فرعش که مثلا Spring ه کار کنن نه اصلش که EJB و ....).شاید شما جایی باشید که همه ادعای فلان چیزو دارند و کدینگ رو بش می گن کد زدن(مگه گارگاه خشت زنیه!بله حتما نشونه اوج مهارت در فرایند خطیر حمالیه!)و اینقدر هم روش تکیه می کنند.و پروژه IT ش فلان هزینست و هرکی بیسواده رفته مجتمع فنی و هر کی جاوا بلده ول معطله چون کسی توایران JavaEE رو برای پروژه هاش انتخاب نمی کنه و مردمش ویندوز قلابی میخرن و لینوکس کاراش نهایت دانش و فظلند و ووو ولی بنده در جایی کار میکنم که مجبوره با استاندارد های جهانی پیش بره تا ISO برای هر سانتیمتر کارش بگیره تا تو دنیا قبولش داشته باشند.هر چی داره اصلی و پولی حتی Redhat ش رو هم با لایسنس استفاده میکنه(وقتی که کاری باید بشه میشه تحریم چیه.بیا و در عمل ببین!)!نتیجه اینکه اگه اینطوری که شما گفتین وضعیت جاوا و نرم افزار در ایران هست شما هم ول معطلید که دارید جاوا کار میکنید و زور میزنید که بگید EJB خرف اول و آخر و میزنه یخوشت بیاد یا نیاد.ما که داریم از EJB 2 تا حالا ازش پول درمیاریم اینقدر روش تکیه نداریم .روی هر فرم ورک دیگش هم.(بماند وقتی ما RMI کار کردیم با خسارت برای اتوماسیون بعد JMX با خسارت(البته به احتساب زمان) تا الان که به قول شما EJB 3 و Annonation و وووو).حالا شما هی آسمون ریسمون بباف....و اظهار فضل کن!
6-بنده از آمار هایی که میدم هیچ منظوری ندارم جز جلب توجه شما و سایر کسانی که دارند بحثو دنبال میکنند.باور کنید از صمیم قلب دوست دارم که جاوا حرف اول و آخر رو بزنه چون اولین فناوری ای هست که certificate ش رو گرفتم و اولین نرم افزاری که واقعا دوست دارم.از بابت شغل خودم هم خیالم راحته اگه قرار بشه پروژه ای با دات هم انجام بشه مشکلی ندارم.
در آخر باید به خدمتتون برسونم شما تند صحبت نکردین متاسفانه بی ادبانه بود و بیشتر به حال یه بچه تا آدم بزرگسال.و این تایپکرو هم که داشت با تلاش من شما وfkohantorabi به نتیجه میرسید با فرمایشات عالیتون منحرف کردین و بعد به دیگری و مقصر میدونید اگه کمی منصف بودین می دیدید که بنده در هر پستی علاوه بر اینکه سعی کردم بحثو به سمت چیزی که عرض کردم یعنی انتظارات ببرم باید چیز هایی هم که بهنظرم اشتباه میومد یا ناقص بیان شده بود رو اصلاح میکردم تا باعث بدفهمی کسی نشه!شما هم آگر می خواید وقت بذارید و کاری انجام بدبن منتی سر کسی نیست منتها با این بضاعت یه فروم واقعا زحمت میکشید که دو تا از پروژهاتون رو که به Spring و EJB 3 کار کردین سورس و توضیحاتشو اینجا مطرح میکنید و به بیان تجربیات عملیتون که در ایران بسیار هم نادره همت میذارید.(ولی چه فایده در ایران به جز چن پروژه و شرکت هایی که شما فقط میشناسید و کار کردین با EE کار نمیکنند و بدرد 2 3 نفر هم بیشتر نمی خوره و زحمتتون هم بی ارج میمونه!).
حق با آقای انیشتن هست :دوچیز همیشه نا متناهی می باشد یکی برزگی کهکشانها و دومی حماقت بشریت.مخصوصا وقتی ریشه حماقت آدم جهل مرکب باشه!

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

mazdadoost
سه شنبه 28 خرداد 1387, 12:28 عصر
با تشکر از دوستان handinux , javaphantom:
ضمن تشکر از لطف دوستان به نظرم تا الان دو پیشنهاد بنده مواردی در مورد بهبود در JSF و Scale ارزانتر و نظرات fkohantorabi در باره مشکلاتشون با Annonation و Team work چنانچه سایر دوستان انتظاری در نظر دارند بفرمایند تا ضمن بحث دربارشون نتیجه گیری هم کنیم.
با تشکر.

fkohantorabi
سه شنبه 28 خرداد 1387, 18:21 عصر
یکی از ایرادهایی که امروزه من می شنوم که خیلی از دوستان که متوسفانه همگی با تجربه هم هستد نسبت به کارشون مخصوصا در قسمت jee اینکه است که همگی به اتفاق می گویند annotation کامپایل می شه و دیگه هیچ کاریش نمی شه کرد و بقولی flexibility رو از بین می بره و در صورتی که بخواهیم تغییر در کار بدیم باید به سراغ ساختار برنامه بریم که کلی دردستر ایجاد می کنه.

ببین ساید در خیلی از موارد حرفی که تو میزنی درست باشه ولی برای من حالتهایی پیش اومده که واقعا قضیه رو سخت کرده. مثلا یک بار یک قسمت از برنامه رو ما outsource کرده بودیم و طبق license برنامه ما صاحب کد نبودیم ولی هنوز تنظیماتی رو نیاز داشتیم بکنیم که تولید کنندهای اصلی توی annotation ها گذاشته بودن. در مورد استفاده از annotationها در EJB هم قبول دارم که مقدار زیادی (شاید همشون) برای کاری که طراحی شدن خوبن و شاید واقعا annotation ها برای فریم ورکها انتخاب خوبی باشند. در آخر درست میگی که خیلیها و من فکر میکنند که annotation غیر قابل تغییر و استاتیک هستش. آیا غیر از این هستش و اگر نه چه راههایی برای تغییرات annotationها هست و چه طوری این رو می شه تو پروسه تولید یک تیم JEE قرار داد؟ چه نقشی توی تیم می تواند اینکار رو بکند؟


فرزاد-

javaphantom
سه شنبه 28 خرداد 1387, 18:24 عصر
با تشکر از دوستان handinux , javaphantom:
ضمن تشکر از لطف دوستان به نظرم تا الان دو پیشنهاد بنده مواردی در مورد بهبود در JSF و Scale ارزانتر و نظرات fkohantorabi در باره مشکلاتشون با Annonation و Team work چنانچه سایر دوستان انتظاری در نظر دارند بفرمایند تا ضمن بحث دربارشون نتیجه گیری هم کنیم.
با تشکر.

نظر من اینکه در آینده با آمدن JSF 2 شاید دارم نسخه آن را اشتباه می گم ولی بهتره بگم نسل بعدی JSF که بصورت default بدون استفاده ICEFaces یا هر تکنولوژی دیگر AJAX را پشتبانی خواهد کرد و تا اونجا که یادم هست معماری آن نیز عوض خواهد شد. اما نکته جالب آن سازگاری زیاد آن با ejb3 می باشد. که به نظر من به نظر من دیگر نه نیاز به seam یا فریم ورک دیگری نخواهد بود.
باز هم می گم با آمدن ejb3.1 استفاده از ejb3 هم در همه جا به روال و استفبال همگان در آینده نزدیک خواهد شد. و فکر کنم رغیب سرسختی برای دیگر فریم ورکهای موجود در بازار بشه. ejb3 نقطه قدرت jee میباشد. البته به نظر من
annotation و کاربرد روز افزون او در همه platform های جاوا هم روز به روز افزایش پیدا خواهد کرد.
واقعا برای بالا بردن performance برنامه توسط JVM بهترین روش همان annotation ها هستند که هین Runtime به ما کمک می کنند که یک اجرای بهینه داشته باشیم.

mazdadoost
سه شنبه 28 خرداد 1387, 19:10 عصر
با تشکر از دوستان.
1-در حال حاضر ما وقتی کار تمام کار هامون رو نهایی میکنیم و WAR یا EAR هامون رو اسمبل و دیپلوی میکنیم به دو دلیل مشکلی با فایل های Annonation کامپایل شده نداریم:
اول : اینکه تا اونجایی که ممکنه سعی میکنیم اجزاع برنامه به هم گره نخورن(Lossly Cuppeld).
دوم: اگر قرار شد که هر تغیری هم انجام بشه کسی که اون فایل رو نوشته تو ورژن کنترل نگاه میکنه و با دقت تغیرات رو میده و در نهایت امکانات Hotdeploy اپ سرور تغیرات رو منعکس میکنه.
به هر حال ما راستش جرات نمی کنیم که تو لایه O/R و Percistance دست ببریم توی هر فرم ورکی (Hibernate-jpa...)واقعا یه کابوس بوده برامون این کارها.(تجربه به ما ثابت کرده که حتی پیگیری کامل متولوژی که برای ما RUF هست -گرچه دوستش ندارم ولی چون مشکل تائئد برای ISO رو کم میکنه ازش استفاده می کنیم.-نمیتونه کمک چندانی وقتی وسط یا آخر کار متوجه می شیم جایی رو چه تو منطق کاری چه تو ساختار داده هامون اشتباه کار کردیم بکنه راستش من و یکی دیگه از بچه ها وقتی این کارا پیش میاد از وقتی روی Annonation سویچ کردیم به نظر کار تایپیمون کمتر شده ولی گشتن تو فایل ها و پیدا کردن ربطشون حتی با مستندات واقعا برامون خسته کنندس مخصوصا جایی که یه EJB یا JPA خیلی جا ها Inject شده باشند. !).با این وجود به نظر مون همه چیز هایی که الان هست کاملا تو این زمینه برامون مغتنم هست و لذت می بریم ازشون وقتی دل و دماق روز های اول کارمون رو داریم!

2-اینکه نسل آینده JSF شامل پشتیبانی ذاتی از AJAX بشه عالیه.و البته یه 60 تا 70 تا کامپوننت ذاتی و اینکه خروجیش هم برای فرمت های Flash-appletهم فراهم بشه.از طرفی همئنطور که گفتم با اومدن WEB BEAN ها می تونیم از EJB هامون به جای Managed Bean های JSF استفاده کنیم.
راستی javaphantom اگه فرصت کردین در مورد EJB 3.1 توضیح بدین.
موفق باشید.

javaphantom
سه شنبه 28 خرداد 1387, 20:21 عصر
با تشکر از دوستان.
1-در حال حاضر ما وقتی کار تمام کار هامون رو نهایی میکنیم و WAR یا EAR هامون رو اسمبل و دیپلوی میکنیم به دو دلیل مشکلی با فایل های Annonation کامپایل شده نداریم:
اول : اینکه تا اونجایی که ممکنه سعی میکنیم اجزاع برنامه به هم گره نخورن(Lossly Cuppeld).
دوم: اگر قرار شد که هر تغیری هم انجام بشه کسی که اون فایل رو نوشته تو ورژن کنترل نگاه میکنه و با دقت تغیرات رو میده و در نهایت امکانات Hotdeploy اپ سرور تغیرات رو منعکس میکنه.
به هر حال ما راستش جرات نمی کنیم که تو لایه O/R و Percistance دست ببریم توی هر فرم ورکی (Hibernate-jpa...)واقعا یه کابوس بوده برامون این کارها.(تجربه به ما ثابت کرده که حتی پیگیری کامل متولوژی که برای ما RUF هست -گرچه دوستش ندارم ولی چون مشکل تائئد برای ISO رو کم میکنه ازش استفاده می کنیم.-نمیتونه کمک چندانی وقتی وسط یا آخر کار متوجه می شیم جایی رو چه تو منطق کاری چه تو ساختار داده هامون اشتباه کار کردیم بکنه راستش من و یکی دیگه از بچه ها وقتی این کارا پیش میاد از وقتی روی Annonation سویچ کردیم به نظر کار تایپیمون کمتر شده ولی گشتن تو فایل ها و پیدا کردن ربطشون حتی با مستندات واقعا برامون خسته کنندس مخصوصا جایی که یه EJB یا JPA خیلی جا ها Inject شده باشند. !).با این وجود به نظر مون همه چیز هایی که الان هست کاملا تو این زمینه برامون مغتنم هست و لذت می بریم ازشون وقتی دل و دماق روز های اول کارمون رو داریم!

2-اینکه نسل آینده JSF شامل پشتیبانی ذاتی از AJAX بشه عالیه.و البته یه 60 تا 70 تا کامپوننت ذاتی و اینکه خروجیش هم برای فرمت های Flash-appletهم فراهم بشه.از طرفی همئنطور که گفتم با اومدن WEB BEAN ها می تونیم از EJB هامون به جای Managed Bean های JSF استفاده کنیم.
راستی javaphantom اگه فرصت کردین در مورد EJB 3.1 توضیح بدین.
موفق باشید.

reduce number of required interface
loosen packaging restriction
java persistence API will evolve as a separate specification and expert group
این آخری به نظر من خطری برای hibernate خواهد بود البته این نظر من هست.
داستان jar فایل درست کردن رو یک جورایی در فسمت دوم راحتر کرده و فقط با داشتن war کار راه میوفته.
من راستش تازه با ejb3 دارم خوب کار می کنم وهنوز که هنوز درگیرش هستم مخصوصا java persistence به جای hibernate اما همونجور که خود سان باز تبلیغ کرده می گه java persistence آینده خوبی داره.
ببیند دوست عزیزشما می تونید در خود سایت سان بیشتر اطلاعات بگیرد. اینجا چون نمی شه انگلیسی تایپ کرد من نمی تونم مستقیم کاپی کنم و ترجمه هم وقت گیره. اما اگر مایل باشید من در قسمت JNDI در ejb3 یک مثال عملی بزنم و اون رو با ejb2.X مقایسه کنیم که اولن با pojo style رو مرور کنیم و بعد خاصیت annotation را بیشتر نشون بدیم. البته بستگی به نظر وخواسته دیگران هم هست شاید بقیه خوششون نیاد

mazdadoost
سه شنبه 28 خرداد 1387, 20:56 عصر
دوست عزیز اگه میشه روی همون ejb3.1 فوکوس کنیم وببینیم چطور کار هار رو در زمینه Enterprise بهبود می بخشه.
قدر مسلم هر جایی که در EE , Annonation کار شده استفاده از JNDI , اون Contex های ... منسوخ شده.و این رو واقعا ازش لذت می بریم.
اگر لطف کنید و در تاپیک فریم ورک های EE بحث Annonation رو ادامه بدین بسیار منون میشم.راستی نگاهی به JSR برای EJB 3.1 آنداختم .

javaphantom
سه شنبه 28 خرداد 1387, 22:15 عصر
دوست عزیز اگه میشه روی همون ejb3.1 فوکوس کنیم وببینیم چطور کار هار رو در زمینه Enterprise بهبود می بخشه.
قدر مسلم هر جایی که در EE , Annonation کار شده استفاده از JNDI , اون Contex های ... منسوخ شده.و این رو واقعا ازش لذت می بریم.
اگر لطف کنید و در تاپیک فریم ورک های EE بحث Annonation رو ادامه بدین بسیار منون میشم.راستی نگاهی به JSR برای EJB 3.1 آنداختم .

دوست عزیز من به هیچ عنوان در این نسخه اطلاعات کامل و چامعی که خودم شخصا درگیر شده باشم ندارم باید زمان بزارم و بخونم من تنها کاری می تونم بکنم اینکه لینک بدم همین
چقدر در مورد خود ejb3 و java persistence صحبت شده؟ من فکر کنم که در داخل همین فروم در مورد ejb3.1 یک اشاراتی شده است. اونم بد نیست که searchی بکنید.

fkohantorabi
چهارشنبه 29 خرداد 1387, 04:33 صبح
دوست عزیز اگه میشه روی همون ejb3.1 فوکوس کنیم وببینیم چطور کار هار رو در زمینه Enterprise بهبود می بخشه.
قدر مسلم هر جایی که در EE , Annonation کار شده استفاده از JNDI , اون Contex های ... منسوخ شده.و این رو واقعا ازش لذت می بریم.
اگر لطف کنید و در تاپیک فریم ورک های EE بحث Annonation رو ادامه بدین بسیار منون میشم.راستی نگاهی به JSR برای EJB 3.1 آنداختم .


یکی از چیزایی که توی 3.1 داشت بحث می شد که خود من علاقه مند بودم بهش بحث asynchronous stateless session bean call بود. نمی دونم اصلا به جایی رسید یا نه ولی در یک مورد خاص من مجبور شدم که همین کار با استفاده از کلاس Exchange بکنم که آخرش هم به ضرر معماری کل برناممون شد.


فرزاد-

fkohantorabi
چهارشنبه 29 خرداد 1387, 04:36 صبح
reduce number of required interface
loosen packaging restriction
java persistence API will evolve as a separate specification and expert group
این آخری به نظر من خطری برای hibernate خواهد بود البته این نظر من هست.

چرا فکر میکنی برای hibernate بد می شود؟


فرزاد-

javaphantom
چهارشنبه 29 خرداد 1387, 14:02 عصر
چرا فکر میکنی برای hibernate بد می شود؟


فرزاد-

خوب همه می رن سراغ خود API های java persistence و از اون استفاده می کنند بجایی اینکه از hibernate و API های اون استفاده کنند.البته این نظر من هست.

mazdadoost
پنج شنبه 30 خرداد 1387, 09:24 صبح
دوست عزیز :fkohantorabi
میتونم بپرسم اون مورد خاصی که لازم شد Session Bean هاتون رو اسنکرون کنید(بروز رسانی مقدار برای همه Bean Client ها؟)بفرمایید؟چرا در اون مورد خواص از مثلا Entity Bean های کش شده استفاده نکردین؟ممنون میشم توضیح بدین.

دوست عزیز : javaphantom :تا اون جایی که بنده اطلاع دارم Hibernate ای ها جز Expert Groupe برای EJB3 و زیر مجموعش jpa هستن و همونطور که می دونید Hibernate الان یه IMPL از JPA هم به حساب میاد به علاوه یه سری Annonation های اضافه.به نظر اینده JPA و Hibernate به هم گره خورده باشه.به عبارتی این دو تا همدیگرو به دنبال هم بکشن.
با تشکر.

saeed_Z_F
شنبه 01 تیر 1387, 19:17 عصر
سلام
از همه دوستان صمیمانه متشکرم که با شروع بحث های بسیار خوب و فنی ذکات علم خودشونو می دن خیلی خوشحالم که بعد از مدتها بخش جاوای سایت برنامه نویس داره رشد خوبی میکنه امیدوارم همیشه پایدار باشید .
در سایت www.theserverside.com (http://www.theserverside.com) یه بنده خدایی در مورد امکانات جدید در EJB 3.1 مقاله می نویسه تا حالا 4 قسمت نوشته :
http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesinEJB3-1
http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesEJB31
http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesEJB31-3
http://www.theserverside.com/tt/articles/article.tss?track=NL-461&ad=646659&l=NewFeaturesinEJB3-Part4&asrc=EM_NLN_3855810&uid=6439444

امیدوارم بدردتون بخوره

fkohantorabi
سه شنبه 11 تیر 1387, 02:54 صبح
دوست عزیز :fkohantorabi
میتونم بپرسم اون مورد خاصی که لازم شد Session Bean هاتون رو اسنکرون کنید(بروز رسانی مقدار برای همه Bean Client ها؟)بفرمایید؟چرا در اون مورد خواص از مثلا Entity Bean های کش
با تشکر.



خیلی دقیق نمیتونم توضیح بدم چون باید همه ساختار اون برنامه رو توضیح بدم ولی قضیه به این ترتیب بود که درخواست از سمت کلاینت میومد و توسط یه ejb یکسری کار انجام میشد که نتیجش تا آخر پردازش درخواست لازم نبود و در نهایت قبل تمام کردن درخواست کلاینت باید چک می شد که نتیجه چی بوده و در این قسمت فقط مثلا 5 ثانیه می شد صبر کرد تا جواب رو گرفت. من دقیقا نمی دونم که اینکار رو چطوری با entity beanها باید انجام بدم ولی کلا فکر میکنم که entity bean برای یه همچین کاری خیلی سنگین باشه.


فرزاد-

mazdadoost
دوشنبه 31 تیر 1387, 18:30 عصر
خیلی دقیق نمیتونم توضیح بدم چون باید همه ساختار اون برنامه رو توضیح بدم ولی قضیه به این ترتیب بود که درخواست از سمت کلاینت میومد و توسط یه ejb یکسری کار انجام میشد که نتیجش تا آخر پردازش درخواست لازم نبود و در نهایت قبل تمام کردن درخواست کلاینت باید چک می شد که نتیجه چی بوده و در این قسمت فقط مثلا 5 ثانیه می شد صبر کرد تا جواب رو گرفت. من دقیقا نمی دونم که اینکار رو چطوری با entity beanها باید انجام بدم ولی کلا فکر میکنم که entity bean برای یه همچین کاری خیلی سنگین باشه.


فرزاد-

دوست عزیز :
اگر وقت بذارید و برام توضیح بیشتری بدید ممنون میشم.