The Electronic Economy in The Arab World

http://us.moheet.com/asp/show_f2.asp?do=1111547




--
h.o.s.a.m.r.e.d
Be OpeN Mind

The Success of Java is Based on a History of Mistakes

Java is ten years old this year so SAP INFO online decided to trace its history and look to the future with Mark Herring, Director, who is responsible for helping to define, set and drive Sun Microsystems' product direction in the Java, Web Services & Tools Business. In his opinion Java is in a sense a history of mistakes. It's a history of doing things that didn't go the way Sun intended, nevertheless ending there incredibly successful.


http://www.sapinfo.net/index.php4?ACTION=noframe&url=http://www.sapinfo.net/public/en/index.php4/article/Article-2532842d264d5d4011/en/articleStatistic  




--
h.o.s.a.m.r.e.d
Be OpeN Mind

(Free Book) J2EE 1.4 BluePrints: Designing Web Services with the J2EE 1.4 Platform

http://java.sun.com/blueprints/guidelines/designing_webservices/
 



--
h.o.s.a.m.r.e.d
Be OpeN Mind

Mind Mapping

Mind Mapping is the technique which was originated by Tony Buzan as a
way of helping people to learn more effectively. Buzan has gone on to
be recognised as the world's leading authority on how to use the brain
more effectively. Mind Maps are now used throughout the world by
businesses, schools and universities and are recognised as the most
effective and versatile thinking tool available.

*For more information:
http://www.mind-mapping.co.uk/index.htm

*Mind maps examples:
http://www.mind-mapping.co.uk/mind-maps-examples.htm

*A nice map:
http://www.mind-mapping.co.uk/images/large/MM---New-ways.gif

*Mind map tool:
http://freemind.sourceforge.net/wiki/index.php/Main_Page

--
h.o.s.a.m.r.e.d
Be OpeN Mind

Describing Web Services and SOAs As Options Proliferate

http://www.theserverside.com/news/thread.tss?thread_id=34250

Making web service clients able to easily consume a SOAP or REST web service is the key to interoperability. This means a standardized, machine readable description that is clean and clear, and which programmers as well as development and management tools can easily use.



--
h.o.s.a.m.r.e.d
Be OpeN Mind

Why smart people defend bad ideas

 
http://www.scottberkun.com/essays/essay40.htm

Posted by Zonk on Saturday May 28, @10:48PM
from the smart-does-not-mean-sensible dept.

CHESTER COPPERPOT writes "Scott Berkun writes an interesting essay on 'Why smart people defend bad ideas '. He states a number of interesting highlights on smart people and dumb ideas. From the article: 'In the software industry, the common example of thinking at the wrong level is a team of rock star programmers who can make anything, but don't really know what to make: so they tend to build whatever things come to mind, never stopping to find someone who might not be adept at writing code, but can see where the value of their programming skills would be best applied.'."

--
h.o.s.a.m.r.e.d
Be OpeN Mind

Java Business Integration Technology Preview is Available

http://www.theserverside.com/news/thread.tss?thread_id=33955

Sun Microsystems has released the Java Business Integration (JBI) Technology Preview based on JSR 208. JBI is the foundation for an SOA. It standardizes the description of a composite services application and makes an SOA extensible and flexible.

--
h.o.s.a.m.r.e.d
Be OpeN Mind

Manage Your Mind

Manage Your Mind

• Mind mapping tool 
  
• Brainstorming Tool
  

--
h.o.s.a.m.r.e.d
Be OpeN Mind

Why Tech. is Advanced in India?

Why Tech. is Advanced in India?

http://us.moheet.com/asp/show_f2.asp?do=1528044


--
h.o.s.a.m.r.e.d
Be OpeN Mind

The definitive BPEL and Java article

The definitive BPEL and Java article

Posted by: Floyd Marinescu on April 13, 2005 @ 09:41 AM

BPEL for Web Services co-author Matjaz Juric discusses the role of BPEL and its relationship with Java in TSS' latest article. The article introduces BPEL and concentrates on the idea of extending BPEL, to be able to compose resources other than web services (EJBs, JMS, etc), and the possibility to mix BPEL and Java code.

BPEL is an important language for the process-oriented approach to SOA. Because BPEL has been designed specifically for definition of business processes it provides good support for various specifics of business processes such as support for long running transactions, compensation, event management, correlation, etc. BPEL is well suited for use with the J2EE platform and many BPEL servers build on top of J2EE. With ideas of combing BPEL and Java (BPELJ), and WSIF, the usability of BPEL is even increasing. We should also look at the emerging JBI (Java Business Integration) specification aka JSR 208 which will give business integration and BPEL an even better documented position in the Java platform.

Read BPEL and Java

--
h.o.s.a.m.r.e.d
Be OpeN Mind

Does EJB 3.0 really make application development easy ?

Does EJB 3.0 really  make application development easy ?

Raghu Kodali has written a blog entry called Does EJB 3.0 really make
application development easy? detailing his migration of one of the
J2EE 1.4 tutorials from EJB 2.1 to EJB 3.0 to see if the claims about
EJB 3.0 regarding simplicity and code size were true.


http://www.jroller.com/comments/raghukodali/Weblog/does_ejb_3_0_really



--
h.o.s.a.m.r.e.d
Be OpeN Mind

Google Future Vision

Not a day went by when someone or the other theorized that Google was
going to build a Web OS, a new kind of application framework or even a
browser. In the other words Google will turn the web into a giant
platform. Google was everywhere! Even in the pages of GQ.

http://www.gigaom.com/2005/03/26/how-yahoo-got-its-mojo-back/

--
h.o.s.a.m.r.e.d
Be OpeN Mind

SOA, MSOA, and Java

SOA is obviously the new buzzword of the day. Among the many acronyms,
one that is seen very often is "Same Old Architecture." In many ways,
this is true. The key differentiator between the paradigms that have
been prevalent in the past and this new incarnation of
"service-orientation" is that the new definition of services is
targeting the business as well as the technical side of the house.
Same old architecture - different politics.

more...
http://www.sys-con.com/story/?storyid=48534&DE=1



--
h.o.s.a.m.r.e.d
Be OpeN Mind

Mastering EJB 3rd Ed Published; Free Book PDF Available

Mastering EJB 3rd Ed Published; Free Book PDF Available
Posted by: Floyd Marinescu on February 18, 2005 @ 11:32 AM

The third edition of the best selling book, Mastering EJB, was just
published and is available for free download off of TSS. The new
edition includes more than 30 percent revised material and five new
chapters covering security, integration, best practices, new EJB 2.1
features, as well as the latest open source Java solutions.

http://www.theserverside.com/news/thread.tss?thread_id=31942




--
h.o.s.a.m.r.e.d
Be OpeN Mind

Requirements Development and Management

Requirements Development and Management

Requirements development activities include the following:

• Identifying the expected user classes for the product
• Eliciting needs from individuals who represent each user class
• Understanding actual user tasks and objectives and the business needs supported by those tasks
• Analyzing the information received from users to distinguish their task needs from functional requirements, business rules, quality attributes, suggested solutions, and extraneous information
• Partitioning system-level requirements into major subsystems and allocating a portion of those requirements to software components
• Understanding the relative importance of quality attributes
• Negotiating implementation priorities
• Translating the collected user needs into written specifications and models
• Reviewing the requirements specifications to ensure a common understanding of the users' stated requirements and to correct any problems before the development group accepts them

Requirements management activities include the following:

• Defining the requirements baseline (a snapshot in time representing the current agreed-on body of requirements)
• Reviewing proposed requirements changes and evaluating the likely impact of each proposed change before deciding whether to approve it
• Incorporating approved requirements changes into the project in a controlled way
• Keeping project plans current with the requirements
• Negotiating new commitments based on the estimated impact of changed requirements
• Tracing individual requirements to their corresponding designs, source code, and test cases
• Tracking requirements status and change activity throughout the project

--
h.o.s.a.m.r.e.d
Be OpeN Mind

Characteristics of Excellent Requirements

Characteristics of Excellent Requirements

How can you distinguish good requirements specifications from those with problems? Several characteristics that individual requirement statements should exhibit, followed by desirable characteristics of the SRS as a whole, are discussed below (Davis 1993; IEEE 1998). A careful review of the SRS by project stakeholders representing different perspectives is the best way to determine whether each requirement has these desired attributes. If you keep these characteristics in mind as you write and review the requirements, you will produce better (although never perfect) requirements documents and you will build better products. 

Requirement Statement Characteristics

Complete

Each requirement must fully describe the functionality to be delivered. It contains all the information necessary for the developer to design and implement that functionality.

Correct

Each requirement must accurately describe the functionality to be built. The reference for correctness is the source of the requirement, such as a customer or a higher-level system requirements specification. A software requirement that conflicts with a corresponding system requirement isn't correct. Only user representatives can determine the correctness of user requirements, which is why it is essential to include users, or their surrogates, in requirements reviews. Requirements reviews that don't involve users can lead to reviewers saying, "That doesn't make sense. This is probably what they meant." This is also known as guessing.

Feasible

It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment. To avoid infeasible requirements, have a member of the software engineering team work with marketing or the requirements analysts throughout the elicitation (requirements-gathering) process. This person can provide a reality check on what can and cannot be done technically, and what can be done only at excessive cost.

Necessary

Each requirement should document something that the customers really need or something that is required for conformance to an external system requirement or a standard. Another way to look at "necessary" is that each requirement comes from an origin you recognize as having the authority to specify requirements. Trace each requirement back to specific voice-of-the- customer input, such as a use case, or some other origin.

Prioritized

Assign an implementation priority to each requirement, feature, or use case to indicate how essential it is to a particular product release. If all the requirements are regarded as equally important, the project manager loses a degree of freedom for responding to new requirements added during development, budget cuts, schedule overruns, or the loss of project personnel.

Unambiguous

All readers of a requirement statement should arrive at a single, consistent interpretation of it. Because natural language is highly prone to ambiguity, write each requirement in simple, succinct, straightforward language of the user domain, not in computerese. Effective ways to reveal ambiguity include holding formal inspections of the requirements documents, writing test cases, developing prototypes, and devising specific usage scenarios.

Verifiable

Examine each requirement to see whether you can devise a small number of tests or use other verification approaches, such as inspection or demonstration, to determine whether the requirement was properly implemented in the product. If a requirement isn't verifiable, determining whether it was correctly implemented becomes a matter of opinion, not objective analysis. Requirements that are inconsistent, infeasible, or ambiguous are also unverifiable.

Requirements Specification Characteristics

Complete

No requirements or necessary information should be missing. Missing requirements are hard to spot, because they are invisible. Focusing on user tasks, rather than on system functions, can help you to prevent incompleteness. If you know you are lacking certain information, use TBD ("to be determined") as a standard flag to highlight these gaps. Resolve all TBDs from a given portion of the requirements before you proceed with construction.

Consistent

Consistent requirements don't conflict with other software requirements or with higher-level (system or business) requirements. Disagreements among requirements must be resolved before development can proceed. You might not know which single requirement (if any) is correct until you do some research.

Modifiable

You must be able to revise the SRS when necessary and maintain a history of changes made to each requirement. This requires that each requirement be uniquely labeled and expressed separately from other requirements so that it can be referred to unambiguously. Each requirement should appear only once in the SRS, as it is easy to generate inconsistencies by changing only one instance of a redundant requirement. A table of contents, an index, and a cross-reference listing will make the SRS easier to modify.

Traceable

You should be able to link each software requirement to its origin and to the design elements, source code, and test cases that implement and verify the correct implementation of the requirement. Traceable requirements are uniquely labeled and are written in a structured, fine-grained way, as opposed to large, narrative paragraphs. 

--
h.o.s.a.m.r.e.d
Be OpeN Mind

Macromedia Taps VoIP For Breeze

Macromedia Taps VoIP For Breeze
By Michael Singer


Macromedia (Quote, Chart) updated its Web conferencing application with new voice over IP (VoIP) capabilities.

As part of Breeze 5's new VoIP plan, the platform now includes a telephone gateway that companies can link to their existing telephony (define) bridges.

In addition to support for VoIP, Breeze 5 also includes the ability to do on-demand video and real-time, multipoint video conferencing.

تقييم وتحديث دور إدارة الجمعيات الأهلية لدعم وتنمية المشروعات الصغيرة

كلية التجارة وإدارة الأعمال
قسم إدارة الأعمال
تقييم وتحديث دور إدارة الجمعيات الأهلية
لدعم وتنمية المشروعات الصغيرة

Evaluating & Modernizing The
Management’s Role of Non- Governmental
Organizations "NGO'S" in Supporting
& Developing Small Enterprises
بحث مقدم للحصول علي درجة الماجستير في إدارة الأعمـال
إعداد
الباحثة/ هداية الله احمد طموم
تحت إشراف

2004

الفصل الأول
الجمعيات الأهلية


ويشمل هذا الفصل:
المبحث الأول : تعريف وسمات الجمعيات الأهلية.
المبحث الثانى : أهمية ودور الجمعيات الأهلية فى مصر .


المبحث الأول
تعريف وسمات الجمعيات الأهلية
تعد الجمعيات الأهلية التطوعية من أهم صور المنظمات الاجتماعية المعاصرة التى انبثق عنها الفكر الإنسانى المتقدم تعبيراً عن القيم الإنسانية النبيلة كالتكافل والتساند والمشاركة الإيجابية للتخفيف من المعاناة فى مواجهة المشكلات ورفع مستوى معيشة الإنسان والوصول به إلى حياة أفضل.
أولاً: تعريف الجمعيات الأهلية:
وتعانى تعريفات مصطلح Ngo's من التعدد الواضح فى التصنيفات والتشتت فى المعايير وكثرة الأسس التى يقوم عليها التعريف والتى تتراوح ما بين الهيكل والوظيفة.
وفيما يلى بعض التعريفات:
• المنظمات غير الحكومية هى منظمات خاصة تطوعية (Pvo's) تم تأسيسها للمساهمة فى تنمية المجتمع. وهذه المنظمات فى الأغلب غير هادفة للربح وعملها خيرى بعيداً عن الاعتبارات السياسية ولكونها ذات توجه تنموى فإن أعمالها تقوم على أهداف محددة تمثل احتياجات مؤسسيها( ).
• المنظمات غير الحكومية عبارة عن مجموعات أو مؤسسات تعمل بشكل مستقل عن الحكومة سواء أكان بشكل كامل أو شبه كامل، وتتسم أعمالها بالأساس بالإنسانية والتعاونية أكثر من تميزها بسيادة القيم التجارية.
• عرف البنك الدولى المنظمات غير الحكومية "Ngo's" بأنها: منظمات خاصة تقوم بأنشطة لدفع المعاناة، والدفاع عن مصالح الفقراء وحماية البيئة وتحقيق تنمية المجتمع( ).
• تعريف الأمم المتحدة: "المنظمات غير الحكومية"مجموعات طوعية لا تستهدف الربح ينظمها مواطنون على أساس محلى أو قطرى أو دولى. ويتمحور عملها حول مهام معينة يقودها أشخاص ذو اهتمامات مشتركة وهى تؤدى طائفة متنوعة من الخدمات والوظائف الإنسانية وتطلع الحكومات على شواغل المواطنين وترصيد السياسات وتشجيع المشاركة السياسية على المستوى المجتمعى.( )
• مفهوم المنظمات غير الحكومية Ngo's يشمل مجموعات مختلفة ومؤسسات مستقلة جزئيا أو كلياً عن الحكومة وتتسم مبدئياً بالإنسانية والتعاونية بعيداً عن الأهداف التجارية ومصطلح NGO'S" يمكننا أن نعتبره ذو طبيعة خاصة: حيث يمكننا إدراك مفهومه من خلال تحديد الحالات التي لا تندرج تحته( ).
وتضيف الباحثة أن عالم الإدارة المعروف بيتر ف. دراكر قد تناول الجمعية الأهلية ضمن مؤسسات القطاع الثالث ووصفها بأنها مؤسسة تغيير السلوك الإنسانى.( )
والباحثة تقدر هذا التعريف وتعتبره معبراً عن حقيقة لمستها هى بنفسها من خلال هذه الدراسة، حيث لاحظت أن العاملين أو المتعاملين مع الجمعيات الأهلية الداعمة للمشروعات الصغيرة اكتسبوا صفات سلوكية إيجابية هى التفكير الابتكارى، التخطيط، تقدير وإدارة الوقت.
وفى ضوء استعراضنا للمفاهيم المختلفة للـ Ngo’s لا يمكننا أن نغفل التعريف القانونى لتلك المنظمات وهو
"كل جماعة ذات تنظيم مستمر لمدة معينة أو غير معينة تتألف من أشخاص طبيعيين أو أشخاص اعتبارية أو منهما معاً لا يقل عددهم في جميع الأحوال عن عشرة وذلك لغرض غير الحصول على ربح مادى"( ).
ويجدر الإشارة إلى أن غالبية المصطلحات السابقة غير شائعة الاستخدام- وهى كلها تعبر عن مفهوم واحد، وفى غالبية الأحوال يتم التعبير عن هذا القطاع بمصطلح "القطاع الأهلى" ( ).
ثانياً: سمات الجمعيات الأهلية:
تتسم الجمعيات الأهلية بالسمات والخصائص التالية:
(1) لها هيكل رسمى، والعنصر المهم هنا هو اتسام الجمعية بالدوام إلى حد كبير. فوجود جماعة غير رسمية ولظروف طارئة أو مؤقتة لا تعتبر جزء من القطاع الأهلى فى ضوء هذه السمة، بغض النظر عما تقدمه تلك الجماعة من مساهمات للمجتمع.
(2) غير حكومية بمعنى أنه لا يجب أن تكون لها علاقة هيكلية مؤسسية بالحكومة وإن كان بإمكانها الحصول على مساعدات مالية أو فنية من الحكومة.
(3) غير هادفة للربح، ويمكن للجمعية أن تحقق ربح خلال العام، ولكن هذا الربح لا يوزع على مجلس الإدارة وإنما يستخدم فى دعم نشاط الجمعية.
(4) ذاتية الحكم، أى أن الجمعية تحكم نفسها بنفسها عن طريق وجود إجراءات داخلية وليس عن طريق كيانات خارجية.
(5) تطوعية، بحيث تشتمل على درجة من التطوعية فى أنشطة وإدارة المنظمة. وهذا لا يعنى أن كل أو معظم الموارد المقدمة للجمعية يجب أن تكون من خلال إسهامات تطوعية أو أن معظم القائمين عليها يكونوا من المتطوعين.
(6) غير دينية، والمقصود هنا عدم تورط الجمعية فى الدعوة إلى أو تعليم ديانة ما.
(7) غير سياسية، بمعنى أن لا يكون لها تحالفات مع الأحزاب السياسية رغم ما قد يكون لها من مواقف بشأن بعض القضايا السياسية( ).
• ولنا أن نلاحظ فى ضوء ما استعرضناه من سمات وخصائص أنه على عكس الحال مع تعريفات الجمعيات الأهلية المتعددة والمختلفة، يتضح لنا أن سمات هذه الجمعيات تتفق فى أغلب الأحيان ومعظمها.
علاوة على ذلك، وفى ضوء العرض لسمات وخصائص الجمعيات الأهلية، يتضح لنا أن هنالك منظور أوسع يمكننا تناول الخصائص من زاويته ألا وهو "البعد الإستراتيجى" وعليه يمكن بلورة أهم خصائص وسمات الجمعيات الأهلية والتى تنعكس بشكل مباشر على إعداد التخطيط الإستراتيجى لهذه المنظمات كما يلى:
أ - أن إحداث التمكين (بناء قدرات الأعضاء والمجموعات المستهدفة، ودعمها، وتنميتها) هو غاية وليس وسيلة. فالتمكين فى الجمعيات الأهلية هو محور وغاية وهدف ورؤية ورسالة ذات بعد استراتيجى حاكم فى المنظمات غير الحكومية.
ب- أنها منظمات غير هادفة للربح، وحتى لو استهدفت الربح، فإن الربح وسيلة مرحلية يكون عائده موجها نحو تدعيم التمكين للمجموعات المستهدفة.
ج- أنها منظمات قائمة على العمل التطوعي وحرية الانضمام ويشكل فيها العمل التطوعى نصيب ملموس إن لم يكن فى أغلب المنظمات فعلى الأقل يكون هو السمة الأساسية فى العديد من الجمعيات الأهلية. وأن هذا العمل التطوعى يسير بالتوازى مع أولئك العاملين فى الجمعيات وفق علاقة رسمية وقانونية يحكمها عقد العمل.
ومن هنا يصبح جزء من قوة العمل يحكمها فقط مدى الانتماء والالتزام نحو الجمعية (المتطوعون) وجزء آخر يحكمه القانون (العاملون التنفيذيون) وجزء ثالث من المتطوعين الذين يتولون مناصب إدارية فى الجمعية أعضاء مجلس الإدارة) يحكمهم الالتزام والانتماء والقانون.
د - أن هذه المنظمات فى أغلب أحوالها مقيدة بحدود نشاط معين، ونطاق جغرافى لا تتجاوزه، فهى حرة فى حدود قيود معينة توضع منذ بداية تكوينها فى نظامها الأساسى.
هـ- أنها تعمل غالباً فى إطار نظم إدارية مبسطة تتناسب وحجم نشاط محدود وهو أمر قد يعوق فى الكثير من الأحوال توسعها ونموها مما يتطلب تغيير جذرى فى هذه النظم.
و - أن تصميم المنظمة غير الحكومية قائم على أساس قيامها بالدفاع عن مصالح جماعات معنية وحمايتها وتمكينها من اجل حياة أفضل وهو أيضاً قد لا يتوفر فى النوعيات الأخرى من المنظمات.
ز- دور هذه المنظمات اللاحق لإحداث التوازن الهيكلى فى المجتمع والذى ينتج عن حدوث تغيرات فى هيكل الاقتصاد، لتلاحق تأثير هذه التغيرات على مجموعاتها المستهدفة وأعضائها وهو دور لا يقع على عائق المنظمات الأخرى.
ح- أن نمط التنافس فى العلاقات بين المنظمات غير الحكومية التى تعمل فى نشاط نوعى واحد غير قائم ولا يجب أن يقوم فالأساس هو التعاون والتفاعل الإيجابى بينهم.
ط- تخضع هذه المنظمات لنمط التنظيم العضوى القائم على روح الفريق والمسئولية الجماعية.
ى- تعدد مصادر تمويل هذه المنظمات وعدم ثباتها واستقرارها يجعل من مشكلة تعظيم مصادر التمويل لها محور ذات بعد استراتيجى فى حركتها( ).

Unit Testing and Testability

Overview

A revolution has occurred
in software development over the last few years. From being the poor cousin of
development, despised by those with more interesting and important things to do,
testing— at least, unit testing—has been welcomed into the
heart of the development process. At last, rather than seen as a tedious
requirement of certain processes (for example, to achieve ISO 9001 compliance),
it has been integrated into a highly productive way of working.

I think this is a very important, and very beneficial, change. In
this chapter I’ll try to explain why I attach so much importance to testability,
and why testability considerations should influence how you go about designing
and implementing applications.

Late in 2002 I spent several weeks developing a testing strategy
for a large J2EE project for a major financial institution. I was working
alongside a testing guru, and my remit was to combine my J2EE expertise with his
experience formulating testing strategies for large projects to formulate a
testing strategy covering the entire project lifecycle. I was asked to recommend
changes in development practice where necessary to ensure that the strategy was
applied. I was also to ensure the developers came onboard, and mentor them in
the coding and testing techniques.

I learned a lot.

• I discovered that my code was much easier to test than
  that of most of the developers on the project. My programming style, described
  in Expert One-on-One J2EE, lends itself to effective
  unit testing. The Spring Framework makes this style easy to practice.

• I became increasingly convinced of the value of test driven (or test first) development.

• I became increasingly convinced that EJB is an enemy of
  testability.

• I reached a better understanding of the goals of unit
  testing.

• I became more convinced of the value of mock objects in
  unit testing.

• I reviewed a number of testing tools.

On the negative side, I was reminded how difficult it is to
interest “old school” developers in unit testing or test first development, and
how difficult it is to introduce agile practices into a large, bureaucratic
organization.

EJB Under the Spotlight

Like most of my colleagues, I was excited by the promise
of EJB when it first appeared. I believed it was the way forward for
enterprise middleware. However, I've since revised my opinions, in the light
of my experiences and those of many colleagues.

Much has changed since the EJB specification was conceived:

• Parts of the specification's design now seem dated.
  For example, dynamic proxies, introduced in J2SE 1.3, call into question the
  container code generation envisaged in the EJB specification and the
  multiple source files needed to implement every EJB.




• The traditional link between EJB and RMI remoting is
  looking dated, because of the emergence of web services and the recognition
  that EJBs sometimes need only local interfaces. EJB is a heavyweight model
  for objects that don't need to offer remote access.




• This is a special case of the fact that basing typical
  applications around distributed business objects-the architectural choice
  EJB implements best-has proved problematic.




• Usage of EJB indicates its strengths and weaknesses.
  Most developers and architects have restricted their use of EJB to stateless
  session beans and (if asynchronous calls are needed) message-driven beans.
  The relative simplicity of the services provided by the EJB container to
  support SLSBs means that the overhead of an EJB container is hard to justify
  in such applications.

• Although EJB has been around for five years, and its
  use is a given in many J2EE projects, it has become apparent that its
  complexity means that many developers still don't understand it. For
  example, many developer candidates I interview can't correctly describe how
  EJB containers handle exceptions and how this relates to transaction
  management.

• The EJB specification is becoming more and more
  complex in an attempt to address problems with EJB. It's now so long and
  complex that few developers or architects will have time to read and
  understand it. With specifications, as with applications, the need for
  continual workarounds and constantly growing complexity suggests fundamental
  problems.

• The complexity of EJB means that productivity in EJB
  applications is relatively poor. A number of tools try to address this, from
  'Enterprise' IDEs to XDoclet and other code generation tools, but the
  complexity still lurks under the surface and imposes ongoing costs.

• Rigorous unit testing and test driven
  development have become increasingly, and deservedly, popular. It's
  become clear that applications making heavy use of EJB are hard to test.
  Developing EJB applications test first requires a lot of
  fancy footwork; essentially, minimization of the dependence of application
  code on the EJB container.

• The emergence of Aspect Oriented
  Programming (AOP) points the way to more powerful-yet potentially
  simpler-approaches to the middleware problems addressed by EJB. AOP can be
  viewed in part as a more general application of the central EJB concepts,
  although of course it's much more than a potential replacement to EJB.

• Source level metadata attributes, as used in .NET,
  suggest a superior alternative in many cases to the verbose XML-based
  deployment descriptors used since EJB 1.1. EJB 3.0 looks like it's heading
  down that road as well, but it's a way off and will carry a lot of baggage.

Experience has also shown EJB to incur greater cost and
deliver fewer benefits than were initially predicted. Developers have
encountered intractable problems that weren't apparent when EJB first
appeared. Experience has shown that EJB fails to deliver in several areas:

• It doesn't necessarily reduce complexity. It
  introduces a lot of complexity.

• The entity bean experiment for persistence has largely
  failed.

• Applications using EJB tend to be less portable
  between application servers than applications using other J2EE technologies,
  such as servlets.

• Despite the promises that EJB would prove the key to
  scalability, EJB systems often perform poorly and don't necessarily scale up
  well. Although statistics are hard to come by, anecdotal evidence suggests
  that the overhead of excessive use of EJB necessitates re-architecture or
  causes outright failure in a significant number of projects.

• EJB can make simple things hard. For example, the
  Singleton design pattern (or alternatives) is hard to implement in EJB.
  

All of these issues suggest that it's wise to analyze exactly
what the value proposition is before using EJB. I hope to equip you with the
tools to do this effectively and dispassionately.