Webcenter portal - architecture question

Question

in our webcenter portal application, we are following this 3 tier architecture.
1. presentation - webcenter portal
2. middleware - soa services
3. source systems
data from source systems is retrieved by multiple mechanism depending on data.
some times it's as simple as select query directly on database
some times it's api provided by source systems
some times it's procedure, batch/script program call
now for portal, what we said is that all communication with source systems will be via soa services.
however i was thinking when it's select query on db type situation, should i escape soa services and use database control (entity, view etc) in my application itself and get required data? i feel it'll improve performance, however not consistent design.
if we go with consistent design (all communication via soa), soa service will execute that query, build data objects, and return to portal...
what's your opinion?
thanks.

Answer 1

This a typical discussion you get with enterprise architects.
In a pure SOA environment they will say you always have to go through the service bus and WebCenter is just a consumer of those service without any exception.
A service need to be a separate, independent deployment module. That's their concept to base the discussion on but when you plug this in WebCenter by using business component, you violate that concept so you need to go through the bus.
That said... I don't really like the idea for WebCenter to go through the service bus if you are controlling the DB itself. If a 3th party is controlling the data or you don't own the data than it might be better to go through the service bus so other applications can profit from the work.
If the data is only used in Webcenter just use business components directly. If later on, another app wants to use the data as well it should be fairly straight forward to refactor BC to SDO and use those in webcenter.
I believe there is a specific ADF BC adapter for SOA that uses RMI instead of regular XML for DB operations which should make everything a lot faster so when it comes to performance I don't think you will have to consider one or another.
You just have to consider whether or not you want for a true service oriented architecture and not just use the ESB as an integration layer.
That said, it's my personal opinion and will probably not reflect Oracle's opinion per se :p