8.  "Better make sure you set aside some time and money to build the proper security infrastructure if you really want to use this thing."
When you implement an EII solution, the main security challenge will be moving from an environment where you have distributed security management, i.e., each data source maintaining its own list of users, roles, and privileges, to one where all of that is centrally managed. Since you are now providing centralized access to all of these distributed sources, the security needs to be managed at this central point as well. Providing centralized security management is not a problem unto itself - it's actually a good thing. What will be difficult is trying to provide this centralized management while each data source that you're tapping into still maintains its own security model. Chances are you're not going to be able to change the source systems to follow this new centralized security model. What this means is that you will need the tools and infrastructure to map multiple security models from the source systems to the centralized model. This issue is not specific to EII solutions: any large-scale integration project will have to deal with this. The problem is that not all EII products come with the type of security infrastructure that is needed to adequately handle these issues. Most of the EII products out there come with the security infrastructures that are typical of most databases and app servers - you set up user profiles, roles, and privileges that specify what objects can be accessed and so forth. Some of them will even let you tap into third-party user profile stores such as LDAP, but none of this allows you to effectively mediate from the separate security models of the source systems to the central model of the EII solution. It's most likely that this will be left up to your developers with "plug-ins." Of course there are many products from the security vendors that handle these types of things with single sign-on, federated identity management, and SAML, but you will have to integrate them into your EII solution and that is not a trivial task.

9.  "Say goodbye to the concurrent access behavior that you've been used to."
Transaction isolation levels on databases allow you to control the level of locking when the database is being concurrently accessed. The four isolation levels defined by the ANSI SQL92 standard (see the References section), in ascending order of restrictiveness, are:

• READ UNCOMMITTED: The transaction can read uncommitted data, i.e., data being changed by another transaction concurrently.
• READ COMMITTED: This level results in the prevention of a transaction from reading uncommitted changes in other concurrent transactions.
• REPEATABLE READ: In addition to the prevention associated with READ COMMITTED, this level ensures that reading the same data multiple times will receive the same value even if another transaction modifies the data.
• SERIALIZABLE: The transaction has exclusive read and update privileges to data by locking it; other transactions can neither write nor read the same data. It is the most restrictive transaction isolation level and it ensures that if a query retrieves a result set based on a predicate condition and another transaction inserts data that satisfy the predicate condition, reexecution of the query will return the same result set.

Because not all data sources support a standard range of transaction isolation levels, things can get tricky when you try to integrate them together with an EII solution. For example, suppose you've defined a composite view of an entity that spans across two data sources. On the EII layer, you set an isolation level of REPEATABLE READ for accessing this entity so this level has to be propagated to the two sources. However, suppose one of the data sources only supports two isolation levels, READ COMMITTED and SERIALIZABLE. In most cases, to ensure data integrity the EII product will map to the next highest level, which in this case will be SERIALIZABLE, meaning that you now have a more restrictive locking level. So now when you thought you would be getting an isolation level of REPEATABLE READ, you are actually getting an isolation level of SERIALIZABLE. The risk with this is that at higher, more restrictive isolation levels, deadlocks are more likely. If you had coded your application expecting an isolation level of REPEATABLE READ, but you are instead getting an isolation level of SERIALIZABLE, your code could deadlock and you would have a heck of time trying to figure out why. Therefore when you're evaluating EII products, make sure you ask the vendors what kind of isolation levels their product supports and how they map to those of the underlying data sources.

10.  "Unlike ETL products, we offer a federated approach that doesn't store any data, sort of..."
The main difference between an EII product versus an ETL (extract, transform, load) product is that the EII product does not actually store data and instead directly accesses the source systems for reads or writes. One of the big advantages of this federated approach is that you don't need to maintain a central store that needs to be synchronized with the source systems - a common issue with ETL. In a high throughput environment, getting the synchronizations perfectly timed is very difficult, which can lead to data integrity problems. Thus, a lot of the EII vendors will tell you that using their product will get rid of the data integrity issues that are common to ETL approaches. However, sometimes there is a fine line between an EII product and an ETL product. For performance reasons, a lot of EII products will use what's known as materialized views or persistent caches, which means they will actually store the data in a local database or file system. If they're storing some data locally, you could potentially have the same data synchronization issues that plague ETL solutions. The concept of a federated approach is nice, but it's not always practical from a performance perspective, as the EII vendors are beginning to see. So if you're thinking about using an EII solution because you have data synchronization problems with your current ETL setup and you have strict performance requirements, you'd better think twice.

Summary
The concept of an enterprise data access layer with an EII product that allows a single point of access to distributed data sources is very attractive. If you are considering implementing an EII solution, the thing to keep in mind is that it is very likely that your enterprise will suffer from one or more of the problems described here and it will complicate your implementation of such a solution. Therefore it's important for you to have a detailed understanding of your current data environment, i.e., quality of the data and infrastructure, as well as a well-thought-out plan for how your existing and new applications will use this solution. This will help you to better understand what kind of features you'll need from the EII product, which will help you do a better product evaluation, or even decide that such a solution is not feasible. Finally, one last point, to be fair: not all of the complexities described here exist in everyone's environment, and some of the products out there do have some features that allow you to handle some of these complexities quite well.

References

• Baksi, Dibyendu. "J2EE Transaction Frameworks: Distributed Transaction Primer." May 23, 2001. www.onjava.com/pub/a/onjava/2001/05/23/j2ee.html?page=1