I was quite thrilled to hear about BEA’s AquaLogic product lines in the last couple of weeks.  AquaLogic is a “bet” the company thing for BEA – it is closely related to Nexaweb’s “project tornado”. In general, BEA’s AquaLogic, SAP’s NetWeaver and Oracle Fusion are all similar to some degree– they are all trying to answer the following question:

1. In a service oriented environment, how to assemble an application or a business process from disparate data sources and distributed services? 

This is a $90Billion question as phrased by BEA.  Obviously you need software tools (“composer”) to assemble the application or business process, you need software runtime environments to run the assembled app or process, and you need software tools to monitor and manage the assembled application or process.

BEA’s answer has been the AquaLogic product family:

1. AquaLogic Messaging:  an Enterprise Service Bus product combined with Web Service Management that can talk to anything including .NET;
2. AquaLogic Service Registry: a UDDI registry OEM’d from Systinet (great job, Roman and the crew);
3. AquaLogic Data Service Platform (formerly LiquidData): unified data access to any data;
4. AquaLogic Security: re-branded from WebLogic Security.

Layering on top of the above available products, the followings are future products:

1.       AquaLogic Composer: an Application Composition Environment for building apps without the need to write Java code;

2.       AquaLogic Portal: the presentation layer for service –based apps;

3.       AquaLogic Process: a business process management environment.

BEA’s roadmap is many months out with a lot of holes (SAP NetWeaver is targeting at something very similar with similar holes). Some of these holes are:

1. Visually composing applications without coding? Sounds good, but how?

In a service-oriented environment, you can assume that there are services available to provide business functions. It is natural to assume that one can assembling these services into “composite service” without doing a lot of coding, especially with support and capabilities provided by standards like BPEL and UML.

OK, so we have covered how to deal with some server side issues (such as how to connect to services and how to assemble services into a workflow) – but these are not enough for building an application. What about the issues on the client side and network layer? For example:

1. How about UI? How would UI be created? How would data be mapped to UI?
2. How about UI event processing, client side business logic, client side data?
3. How about non-linear workflow from a user perspective?
4. How would UI, client data and logic be distributed and deployed?
5. How would one overcome typical application challenges in an enterprise computing scenario such as large amount of data, real-time requirements, network connection reliability, client platform heterogeneity, etc?

2. Using AquaLogic Portal for application presentation? Are you sure the Portal is the way to go?

Portal has great value for content aggregation – however, is BEA aware that Portal is severely limited to what it can do for customers?

In the context of enterprise computing, for business critical applications that are frequently used (such as a few hours per day) that have the following requirements:

a.       Lots of data or real-time data push to user screen

                                                               i.      How would Portal support lots of data on user screen? Would the user page an HTML table 100 times to see 2000 rows of data?

                                                             ii.      How would Portal support real-time updates? Would the user refresh the screen once every second to see the latest information?

b.       Non-linear workflow for a user perspective

                                                               i.      How would HTML support non-linear workflow?

c.       Business processing on the client side

                                                               i.      How would Portal support client side processing? Would the developer need to write 10000 lines of JavaScript? How would it be managed and maintained?

Take a look at applications such as claim processing in an insurance company, portfolio management in a financial service company, currency exchange for bank customers, enterprise network management, performance management, real-time monitoring, etc. – Are these applications going to be Portal applications? Can you imagine the severe performance and functionality pains if these were Portal applications?

3. AquaLogic Process: how does business process relate to user interaction?

Ok, you can assemble a business process – but what if the business process needs user interaction? How?