________________________________________________________________

                TheServerSide.com Newsletter #2

TheServerSide.com newsletters are designed to bring the most important news from the J2EE industry to your door, along with providing you with exclusive J2EE articles and advanced topics not found anywhere else. Our newsletters will also keep you informed with whats new on TheServerSide. Newsletter mailings will be infrequent, probably on a monthly basis. Instructions for unsubscribing are at the end of this newsletter.
________________________________________________________________


IN THIS ISSUE:

  * EJB Guru Spotlight - An Interview with Ed Roman
  * Developers Corner - Pessimistic Vs. Optimistic Concurrency
  * Future Trends in EJB - Java Data Objects vs. Entity Beans
  * New article on TheServerSide.com - Job Scheduling in J2EE
  * Latest News Headlines From the J2EE Industry
  * A word from The Middleware Company

 


________________________________________________________________

EJB GURU SPOTLIGHT - INTERVIEW WITH ED ROMAN

Ed Roman is one of the world's leading authorities on EJB and J2EE.  Heis the author of Mastering Enterprise JavaBeans and the Java 2 Platform,Enterprise Edition, an advanced book on EJB and J2EE development, publishedby John Wiley & Sons, August 1999.  He is also CEO of The Middleware Company(http://www.middleware-company.com), a firm specializing in EJB training andconsulting.  Ed has been heavily involved with Sun Microsystems' middleware technologies from their inception, and has designed, built, and deployed a variety of enterprise applications, including architecting and developing complete application server products.  He routinely devotes a significant amount of time towards influencing and refining Sun's enterprise specifications, and is regular contributor to http://www.TheServerSide.com, a J2EE community.

Q: What do you see as being the biggest change affecting the Java community in the last year?

The biggest change is Microsoft's decision to drop Java in favor of C#(pronounced "see-sharp").  C# has a chance of becoming the de-facto programming language for Win32-only applications, just as Java has become the de-facto programming language for cross-platform applications.  Another noteworthy advancement in technology is Microsoft's .NET initiative.  Thereare some powerful ideas in their new architecture, and if Microsoft can execute on their promises, .NET will definitely give Java a run for its money.  It's going to be an interesting battle ahead.

Q: How do you find Java stacks up to other programming languages, such as C++, for designing large-scale enterprise applications?

Java is my top pick.  Why?  Because:

* Java has built-in security, networking, and threading, all essential for enterprise-class applications.
* The virtual machine model, along with garbage collection, means applications are more reliable and less error-prone.
* The fact that Java is divided into 3 platforms (J2ME, J2SE, and J2EE) means different markets benefit from different flavors of Java.
* Enterprise-class applications are often written by ISVs which don't control their deployment environment and require cross-platform development.
* There is incredible momentum behind Java.  Most developers are hungering to get on Java projects.  This means that organizations adopting Java are likely to have an easier time finding good developers in the future.

Q: For the novice, what exactly are Enterprise Java Beans? How do they fit in with other Java technologies, like JavaServer Pages and Servlets?

EJB is the cornerstone of server-side Java.  You wouldn't use EJB for embedded devices or desktop applications, you'd use it for the hard-core business logic and data logic required for large-scale multi-user applications.  EJB is tied together with JSP, servlets, and other server-side Java technologies via the Java 2 Platform, Enterprise Edition(J2EE) specification.  You can think of EJB as a subset of J2EE.  The rest of J2EE provides the glue and missing puzzle pieces to built complete websites.

Q: Have you seen successful EJB/J2EE projects?

Absolutely.  My company has helped clients develop and deploy EJB systems used for a variety of tasks.  These include:

* Rating financial bonds
* Performing online procurement
* Coordinating with airplane navigation equipment
* Mapping the human genome
* Performing workflows to process orders
* Managing telephony switches
* Performing banking transactions

Q: What methodology do you recommend companies take to develop successful EJB systems?

We've devised a 4-step procedure to getting EJB projects started on the right foot.  These steps include:

1) Training your staff on the technologies.  By educating your developers in a controlled environment, they can learn in days what would normally take weeks or months.

2) Design work.  This includes analyzing business requirements and mapping those into a reusable EJB architecture.  The Unified Modeling Language (UML) should be used for all diagrams.

3) First-pass development.  I strongly encourage firms to consider aniterative development process, where they divide their design into 'slices'of EJBs, JSPs, and servlets, and build a complete slice first.  Thisre-usable slice is demonstratable to management and/or investors, and can beused to perform scalability testing before the entire application is developed.

4) Selection of an EJB server.  To choose the right application server, first come up with a short list of 2-3 vendors you're choosing from.  Then bring those vendors in-house, and deploy your first-pass into each of those vendors' application servers.  This empowers you to evaluate how they handle your specific needs.

You can find out more about this process athttp://www.middleware-company.com/quickstart.html

Q: What would be the best development tool for an EJB developer to use? Which server do you think stands out from the crowd?

My preferred tool is Visual SlickEdit because its simple and fast.  However,that is not an EJB-specific tool.  There are some newer tools that are emerging that dwarf SlickEdit when it come to EJB functionality, and they include IBM's VisualAge for Java, Inprise's JBuilder, and WebGain Studio.

Q: The complexity of the Java 2 Enterprise Edition platform, and technologies like Enterprise JavaBeans, makes for a steep learning curve. In what way does your book assist developers in understanding and learning EJBs?

My book explains EJB by first explaining the technologies that EJB dependson: RMI, JNDI, RMI-IIOP, and XML.  So you only need to know Java to understand EJB.  You can download a complete electronic copy of the book (in PDF form) from http://www.TheServerSide.com.

Q: Looking to the future now, where do you see Java heading? Is there a particular technology that you've enthusiastic about?

I think the most important technology that the Java community should keep an eye on is the Simple Open Access Protocol (SOAP) along with XML.  In the future, many web sites will be constructed in a piecemeal fashion from other web sites that they subscribe to, and SOAP enables this to happen.

 

________________________________________________________________

DEVELOPER'S CORNER - OPTIMISTIC AND PESSIMISTIC CONCURRENCY IN EJB

To be an effective enterprise architect, you can't really rely on the J2EE API's to hide the complexities of distributed programming for you. A good architect should understand what goes on under the hood of an application server, inorder to make more educated design decisions on projects.

An important and very confusing part of enterprise computing, or rather, transaction processing, is optimistic and pessimistic concurrency.  Optimistic and Pessimistic concurrency are algorithms used to control concurrent access to the same data.  These concepts come from database theory, where databases can use optimistic or pessimistic concurrency to control muliple transactions accessing the same data. In a nutshell, pessimistic concurrency algorithms allow only one transaction at a time to touch a particular source of data (a row in a database, an entity bean, etc). Other transactions that want access to the same data will block (wait) until the first transaction has completed. Optimistic concurrency doesn't enforce any such blocking. In an optimistic concurrency control scenario, multiple transactions can all access the same data concurrently, but if the consistency of the data accessed is compromised, one or more transactions will be rolled back.

Application servers can be said to utilize pessimistic or optimistic concurrency if they choose to control the concurrent access to data (entity beans).  More specifically, an application server can choose to enforce transaction isolation itself, or they can delegate this complex logic to the underlying datastore. An application server that delegates the transaction control to the database is not really using pessimistic or optimistic concurrency, it is simply delegating this task to the database. Application servers typically do this by allowing multiple intstances of entity beans in memory all with *the same primary key*. Now, when n transactions require usage of a particular entity bean, the application server will create n instances of the entity bean to service those n transactions. 

An application server that will block an entity bean from being read by some transaction if some other transaction is currently working with that entity bean is explicitly managing concurrent access to the entity bean (and the data it represents), and can thus be said to use pessimistic concurrency. These types of application servers usually enforce pessimistic concurrency by having only one entity bean in-memory, per primary key. Serializing access to this entity bean then becomes easy.

Why should EJB architects understand the differences between these two algorithms? The answer is that if you don't, you risk writing code that could potentially become destructive when the applications database or application server is changed.

So how does pessimistic and optimistic concurrency affect the behaviour of your EJB's?  Assume two clients both have access to the same entity bean, that is, two clients (in two different transactions) both call findByPrimaryKey(123). If pessimistic concurrency (at the application server or database level) is used, then the first client who called findByPrimaryKey(123) will have exclusive access to work with that entity bean (he will have a lock on the bean, or the row in the database that the bean represents), while the second client will have to wait until the first client's transaction has committed, before he can use the bean.  If Optimistic Concurrency is used (in the database level), then both clients will be able to access the entity bean at the same time.

From this simplistic view, it looks like Optimistic Concurreny is faster, so why don't all application servers just use it? The answer is that Optimistic Concurrency is a double edged sword.  Imagine the following scenario:

1) Client A starts a transaction and reads some data from a Bank Account entity bean with a balance of $10,000.
2) Client B does the same (since the data isn't locked), on the same entity bean.
3) Client A increments the bank balance by $2000
4) Client B does the same. 

The final balance in the entity bean will now be $12,000, not $14,000, because when client B's instance of the Bank Account entity bean executes ejbStore, it will write its new balance of $12,000 overwriting the $12,000 balance previously stored by client A.  In this scenario, the underlying database will rolled back Client B's transaction, when it tried to commit. The application server would throw an exception to the client indicating that the transaction wsa rolled back. This means that EJB Developers would have to write custom logic to deal with this event, inorder to notify the client and ask him to retry his transaction.  If Pessimistic Concurrency were used, Client B would have to wait until Client A finished using that particular Bank Account Entity Bean, and this problem would never have occurred.  The EJB developer using an application server with Pessimistic Concurrency would therefore not have to write the extra exception handling code.

Pessimistic Concurrency is "pessimistic" in that it assumes that these types of transaction "collisions" will occur often, and thus allows lower performance in exchange for stricter, cleaner transaction handling. Optimistic Concurrency is "optimistic" in that read only transactions are assumed to happen more often than update transactions, and thus chooses to support better performance for the majority of cases, the trade off being more complicated design and code on the part of the EJB Developer, inorder to deal with collisions.

Almost every application server relies on the database's concurrency strategy (and allows multiple entity bean instances per primary key) (Inrpise, Oracle, Powertier, Gemstone, etc), but there are notable exceptions like BEA Weblogic, which uses Pessimistic Concurrency by default (and enforces one entity bean per primary key). 
 
In order to truly write portable code, it is important for EJB architects/developers to understand the difference between Pessimistic and Optimistic Concurrency, and know which application server/database combination use which algorithm.  In many cases, code that assumed pessimistic concurrency will not be portable to application servers that use Optimistic Concurrency.  A good example is the Entity Bean Primary Key Generator Pattern that I posted in TheServerSide.com patterns section (http://theserverside.com/patterns/thread.tss?thread_id=220). The pattern assumed that an application server will only keep one instance of a particular entity bean in memory at a time. And that all access will be serialized. The pattern was written and tested on Weblogic, and I simply didn't know that other application server/databases handled entity beans in such a fundamentally different way.

So which algorithm is better? That is a very tough call, since each has its own advantages. My own opinion is that Optimistic Concurrency is a better choice, due to the performance enhancements. What about the extra code you will have to write? Any serious eCommerce application will have to have "staleness checks" embedded in your entity beans anyway, since your entity beans will need to know when they are being updated by a user who is performing the update based on "stale data". This is also known as the dirty read problem. Therefore, since most EJB projects will need "dirty read" handling code anyway, then the potential performance bottlenecks of Pessimistic Concurrency no longer seem justified. 


by Floyd Marinescu
Senior Architect, The Middleware Company.

 

________________________________________________________________

FUTURE TRENDS IN EJB - JAVA DATA OBJECTS VS. ENTITY BEANS


It seems to me that Java Data Objects are what Entity Beans should have been like. Consider the purpose of entity beans:

1) Provide a standard way to persist your domain model
Before entity beans, people had to write their own persistence frameworks or rely on proprietary relational mappers.

2) Encapsulate the persistence mechanism
BMP or CMP? Persistence mechanism should be hidden behind the entity beans.

3) Be distributed objects, callable from anywhere
IMHO, this feature was a big mistake. Entity Beans should not be accessed remotely. To wrap entity beans with session beans is a common design pattern.

4) Be transaction aware objects
Since entity beans should be wrapped by session beans, it is not necessary to set transaction settings on entity bean methods since the transaction settings will be determined by the calling session bean.

Entity Beans do a great job at #1 and #2 above, but because the mistakes made by EJB designers in providing #3 and #4 above, entity beans are wasteful because they use distributed network calls, even though most people wrap them with session beans, and they add transactional overhead and require transactional deployment descriptor settings, again even though most people wrap them with session beans. Entity Beans also require a lot of extra coding to make them worthwile, such as implementing details objects.

Java Data Objects seem to be what Entity Beans should have been. Simple, plain java classes that provide benefits #1 and #2 in a much simpler and better way than entity beans do, and don't even try to offer #3 or #4, thus using java data objects will be dead simple. Imagine, no more long deployment descriptors, no more JNDI lookups to find a simple domain model class, no more brainless gets and sets to for details objects, etc etc.


Learn more and add your opinion to the discussion:

http://theserverside.com/discussion/thread.tss?thread_id=771

 


________________________________________________________________

NEW ARTICLE ON THESERVERSIDE.COM - Job Scheduling in J2EE Applications

Scheduling tasks in J2EE applications is a common need. There is more to job scheduling than running backups at 3 o'clock in the morning. Customer relationship management (CRM) applications, for example, need to contact customers periodically during the sales cycle. File transfer applications need to transmit and receives files on a regular basis, except on holidays. Administrative applications need to send reminder emails to notify employees and customers about important events. All these enterprise applications can benefit from job scheduling.


Read this excellent article by David Sims here:

http://theserverside.com/resources/jobj2ee.jsp?newsletter

 

 


________________________________________________________________

LATEST HEADLINES IN THE J2EE INDUSTRY


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Final Messaging Services Spec Due From ebXML
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The ebXML initiative is set to finalize and release the Messaging Services Specification at its next meeting in Tokyo Nov. 6. SOAP is not expected to be used as the underlying transport for ebXML messages.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tomcat 4.0 release milestone 1 is out
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Tomcat is a reference implementation of the Java Servlet and JavaServer Pages Specifications which can run standalone as well as integrated into the Apache Web Server. The much awaited Tomcat 4.0 release supports Servlet 2.3 and JSP 1.2 API's.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sun, Microsoft Square Off for Enterprise Offerings
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Microsoft and Sun next week will try to convince the world that their respective offerings should be the standard for future enterprise deployments. On Tuesday, Steve Ballmer will announce availability of Windows 2000 Data Center Edition, SQL Server 2000, and BizTalk Server 2000 among others. A day later Sun will address many of the same issues at its Net Effects event in New York.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IBM Patterns for e-business webcast on Sept. 27
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On September 27, 2000 from 2 - 3:30 pm (Central time) there will be a live webcast followed by a question and answer session about how to use the IBM Patterns for e-business. The patterns for e-business are architectural and design navigational best practises, based IBM's vast professional services experience.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
EJB 2.0 chat with Linda DeMichiel and Umit Yalcinalp available
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The transcript of the java live chat with EJB 2.0 designers Linda DeMichiel and Umit Yalcinalp are available. Topics covered include future directions of the spec, JDO vs. Entity Beans, threading, EJB QL, etc.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Learn about EJB 2.0 Container Managed Persistence
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The EJB 2.0 specification has defined a standard approach to persisting both objects and their associations, and it has introduced a standard approach to searching for objects that isn't coupled to their underlying data schema. Learn about EJB 2.0 CMP in an excellent new article written by Scott Ambler.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Java Technology in the Real World
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kiko.com provides resources and tools for an online learning community of parents, teachers and kids. We're using leading-edge technology - EJB, servlets, JSP, XML, etc. - to deliver a scalable, flexible and high performance solution. Take the Kiko Technology 101 lesson and see how we support an online learning community using J2EE technology!

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Togethersoft Ships Together Control Center 4.1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TogetherSoft Corporation, today announced the immediate availability of Together Control Center 4.1. Together Control Center 4.1 includes: New XML structure editor, Expanded EJB Deployment Expert, Servlet patterns,Improved compile/make/run/debug, Improved forward and reverse engineering of database schemas, and more.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sun releases new JDBC 3.0 specification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sun Microsystems today released public draft of the JDBC 3.0 specification. The new specification aligns JDBC 3.0 with the Java2 Enterprise Edition Connector Architecture.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KaanBaan announces first J2EE-based XML transaction server
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KaanBaan Technologies has released XML-Broker, an XML transaction server based on 100% Java J2EE technology. The product accepts and parses XML messages, invoking user written Session EJBs with the pre-parsed XML classes. XML-Broker can "plugin" to existing app. servers, or be used as its own stand alone application server.

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ATG Dynamo 5 achieves J2EE certification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Art Technology Group (ATG) has announced the availability of the ATG Dynamo 5 Platform with full J2EE certification! ATG is now the 4th company to announce certification, after IPlanet, BEA, and Sybase. What makes ATG Dynamo unique is its focus on customer relationship management (CRM) features like "scenario-based personalization".

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
EAI and J2EE, which is more important?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This article describes how Enterprise application integration (EAI) and workflow will become the new core technical component in enterprise level systems. It describes a reference technical architecture for such systems. It also describes how IBM and BEA fare at delivering this sort of system.

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

 

________________________________________________________________

A WORD FROM THE MIDDLEWARE COMPANY

How would you like a job where you can work with industry experts, where your companies mandate is to help you become an expert yourself?  How would you like to write magazine articles, speak at conferences, and truly master EJB? The demand for J2EE training and consulting is exploding, and The Middleware Company needs your help to meet this demand.  We now have job openings for ambitious, adaptable professionals interested in training and consulting with todays cutting edge technologies including Java, J2EE, XML and EJB.

For more information, visit:
http://www.middleware-company.com/jobs.html?newsletter

 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

To unsubscribe from TheServerSide.com's biweekly newsletter go to:
http://www.theserverside.com/home/newsletter.jsp

TheServerSide.com J2EE community is brought to you by The Middleware Company. The Middleware Company is an advanced training and consulting company dedicated to server-side Java. The Middleware Company offers onsite training courses in Java 2, Enterprise JavaBeans (EJB), the Java 2 Platform, Enterprise Edition (J2EE), and the Extensible Markup Language (XML). They also aid in the design, development, and deployment of middleware solutions. Visit The Middleware Company at:
http://www.middleware-company.com/index.html?newsletter


© 2000 The Middleware Company.
Published on: