Database Reference
In-Depth Information
As performance is declared to be one of the primary objectives, always demand for direct
access to the resources you need. A direct DB access or
Remote Method Invocation
(
RMI
) is much faster than the hub-and-spoke integration approach. At the same time, do
not let anyone access your internal resources, as it potentially could affect the third char-
acteristic declared prime, that is, reliability. On second thoughts, it would be good to hide
all your implementation details and keep them hidden from everyone. It will prevent any
unauthorized access into your backend resources.
Strengthening security is a positive side effect of this isolation. The obvious fact that all
technical details and data structures are already exposed via your autogenerated
Web Ser-
vices Description Languages
(
WSDLs
) are just
Web Services
(
WS
) collaterals and must
be handled again by EAI. This is because we follow a common principle of
separation of
concerns
by delegating security operations to the middleware. By helping middleware
handle error situations, you could provide a full-stack trace from your entire web-based
API, leaving the standard
SOAP Fault
message by default. The EAI team will have to
find all the necessary details and handle them according to their understanding of business
logic, as we will keep our internal logic secluded for the reasons explained previously (se-
curity and resource protection).
As you already have direct connections to the resources in other systems, you could po-
tentially implement some extra logic on your side in order to speed up the external pro-
cesses and get the necessary results without waiting. Why not? We are endorsing distrib-
uted computing! You can go even further; you can include your public API's capabilities
from other systems, as you already have access to them. So, it's a mashup, isn't it? For the
sake of clarity, you just inform the EAI team that these new capabilities are foreign and
not covered by your original SLA, as you cannot guarantee that the design of other sys-
tems would be good; however, you welcome everyone to use them. Speaking of SLA,
quite soon you will spot that the autogenerated XSDs are a bit elaborate, causing some
latency on the API side and extra processing overhead on the EAI platform. As an archi-
tect, you would propose quite a simple workaround (remember that performance is the es-
sence): switch off the XSD validation at the EAI platform's end. It certainly helped a bit,
but not enough. Later, you will discover the original cause, that is, the standard JAXB lib-
rary responsible for message marshaling/demarshaling is way too slow.
The implementation of custom marshaling would certainly be helpful not only for your
application, but also for others' as well. Why not help other teams by supplying them with
a more robust and reliable XDK? In parallel, you can make some improvements to the
XML structure, presenting custom elements within the message body for parsing accelera-
tion. For instance, if you have several addresses in the message (billing, postal, and cor-
Search WWH ::
Custom Search