Enterprise Media Beans

Content management systems, for instance, are highly complex and heavyweight middleware with proprietary data stores and proprietary interfaces for storing, retrieving, and managing digital content. Streaming solutions, as another example, are non-standardized software products using proprietary protocols to transfer and render content such as audio and video on the end user's workstation. They mainly work with proprietary, formatted content stored in plain files.

The key players within this quickly emerging market are companies such as Real Networks^TM, Microsoft^TM, and Apple^TM. This has serious impacts on enterprise customers who are interested in incorporating rich media data into their core business because, for example, the use of proprietary APIs creates dependencies on the architecture of the products used, making it hard to migrate from those products later.

The integration of standard business applications with products exposing proprietary data formats, APIs, and protocols is very hard to achieve. The missing integration with mission-critical enterprise data that resides in the customer's relational databases violates referential integrity. Back-ups are not consistent, because the rich media part of the enterprise data is handled by proprietary database systems. Caching or replication of media data throughout customer intranets is either not handled at all or based on proprietary solutions or stream server providers. Also, there is no unified mechanism for authorization and transactional behavior when it comes to combining structured and rich media data.

What enterprise customers want instead is a standardized, uniform view on rich media data from the back end throughout their infrastructure and a possibility of maintaining it using their standard database administration. In other words, they want to see rich media data as just another data type that is handled similarly to the existing ones on the application layer. Enterprise Media Beans are intended to deliver this scenario within the J2EE application model.

• New EJBs, MetaDataEntityLocal, are introduced for Meta-Data. Meta-Data is supported as an XML document. Content can be stored, searched, and retrieved. No detailed manipulation of internal elements and nodes is currently supported through EMB, although other standard tools can certainly be used. Multiple query languages can be supported (similar to JSR 170) but are not mandated.
• All EJBs (MediaEntity and MetaDataEntity) now have local interfaces (rather than remote) in order to promote more efficient implementations. Remote access for operations involving the Media and Meta-Data EJBs can be provided with a Session Bean wrapper.
• The Location field is now either Container-Managed or Client-managed, but it is no longer guaranteed to be unique. The internal location is generated and managed by the EJB implementation. The client need not be concerned with the location until the media is exported or published. The location can be manually set on the EJB; this is intended to allow reference of media that is externally hosted by a third party. The specification does not mandate that all features are still functional when the location is manually set.
• The Media Listeners are no longer EJBs; they are now Serializable Dependent Java Classes.