24 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
Performance
It is obvious that your architecture, when finally designed and implemented, must
perform fast. Consider that by introducing additional logical layers, or even
physical tiers, you have a very real possibility of impacting any service level
agreement (SLA). Be watchful for Yet Another Decoupling Layer (YADL), and be
mindful of the blame-game when performance suffers and response time SLAs
are not met.
Suggestion: Consider adding time stamps to your logical layers and physical
tiers. For example, if your EIS system service performs poorly, is the problem
caused by bad connection pooling with too many concurrent service requests,
or is the problem occurring on the WAN, perhaps within the request and
response handling in the interaction layer of the service end-point?
Alternately, maybe the problem is caused by a back-end system routine that is
running very slowly.
The ability to have this type of information available will greatly assist you
when you re-factor for performance or when you enter the inevitable
blame-game in a critical situation (critsit) meeting over poor performance. Try
to design and build this capability into your solution from the beginning. Do not
attempt to re-factor your EIS integration solution after construction.
You must at least have time stamps for:
???? The total time of the EIS system process
???? Total time spent in the service end-point interaction layer
???? Total time spent in the service end-point processing layer
The EIS service end-point processing layer is the EIS system process.
???? Total time spent in the EIS component
???? Total time to create a back-end request byte buffer
???? Total time to execute a J2C javax.resource.cci.Interaction
Usually you can view this time as the time spent in the network (LAN or
WAN) plus the execution time of the back-end transaction. If, for example,
the back-end systems team says that the back-end transaction execution
time was 500ms but this time indicates 3000ms, then you can assert that
the other 2500ms was either the network (likely) or the J2C connector (less
likely).
???? Total time to parse a back-end response byte buffer
If you have these time stamps available, you can focus on the layers or
components that are causing bad responses when you have these type of
issues with your back-end integration architecture.
Chapter 2. Architecture 25
Error handling and reporting
Because Web services are not immune from errors, you must decide how to
throw or otherwise handle exceptions or errors that occur. You need to address
such issues as whether to throw service-specific exceptions or whether to let the
underlying system throw system-specific exceptions. You must also formulate a
plan for recovering from exceptions in those situations that require recovery. Just
like any Java or J2EE application, an EIS service may encounter an error
condition while processing a client request. The EIS service needs to properly
catch any exceptions thrown by an error condition and propagate these
exceptions.
With a J2EE or Java application that is not a Web service or BPEL process, you
can propagate exceptions up the call stack until reaching a method with an
exception handler that handles the type of exception thrown. You can continue to
throw exceptions up the entire stack trace. You can also write exceptions that
extend or inherit other exceptions. However, the EIS service and BPEL process
have additional constraints that impact the design of the EIS system service.
Consider the following when designing your error reporting and exception
handlers:
???? Wrap application-specific errors and exceptions into meaningful
service-specific exceptions and throw these service-specific exceptions to the
clients.
???? Exception inheritances are lost when you throw a service-specific exception.
???? The exception stack trace is not passed to the client.
???? The EIS system process must have an exception handler to log system and
application specific errors and to return a meaningful fault to consuming
business processes and applications.
26 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
Management
Once we get to runtime, then we need to manage the EIS services. You need to
consider:
???? Runtime service management
–Access
– Billing
???? Monitoring the EIS service
–SLA
–Consumers
???? Provide feedback mechanism
–SLA compliance
– Performance
– Availability
Suggestion: Consider adding a stack trace property for all of your system
exceptions to help you in finding problems.
try {
...
} catch (SomeException e) {
// get the stack trace
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter(sw);
e.printStackTrace(pw);
// create service fault
MyComponentException fault = new MyComponentException(e.getMessage());
fault.set_stackTrace(sw.getBuffer().toString());
// throw the service fault
throw fault;
}
Having the actual stack trace available where the system exception occurred
in a multi layered architecture will help you to immediately focus exactly where
the problem happened. You must be able to identify which component, which
BPEL activity, or which service caused the system problem.
This capability probably is not required for your business exceptions, like a
FundsNotAvailable exception.
Chapter 2. Architecture 27
Figure 2-5 illustrates the service management concept.
Figure 2-5 EIS service management
Security
Security is a major consideration for multi-tier deployments. In integrating with
back-end systems, J2EE components might use different security mechanisms
and operate in different protection domains than the resources they access. In
these cases, the calling container can be configured to manage the
authentication to the resource for the calling component. This form of
authentication is called container-managed resource manager sign on.
The J2EE architecture also recognizes that some components require an ability
to manage the specification of caller identity and the production of a suitable
authenticator directly. For these applications, the J2EE architecture provides a
means for an application component to engage in what is called
application-managed resource manager sign on. Application-managed resource
manager sign on is used when the ability to manipulate the authentication details
is a fundamental aspect of the component’s functionality.
You should ensure that access to any component that encapsulates or is
provided by its container with a capability to sign on to another resource is
secured by appropriate authorization rules.
Need to manage relationship of
consumers to Web Services
Need to manage relationship of
EIS Service to implementation(s)
Consuming
Application or
Business Process
Service
Implementation
EIS
Service
28 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
In a distributed computing system, a significant amount of information is
transmitted through networks in the form of messages. Message content is
subject to three main types of attacks. Messages might be:
???? Intercepted and modified for the purpose of changing the affects they have on
their recipients.
???? Captured and reused one or more times for the benefit of another party.
???? Monitored by an eavesdropper in an effort to capture information that would
not otherwise be available.
You can minimize such attacks by using integrity and confidentiality
mechanisms.
Domain objects
Every application has data items that logically belong and typically are used
together. It is programmatically convenient and, with enterprise beans,
performance enhancing to treat this logical group of data items as a separate
object. These type of objects are also commonly known as value objects, and
some texts even refer to it as data transfer objects. If Java had a structure
construct, such as C/C++ and many other languages do, a domain object would
be a structure.
Using domain objects is useful for communication across the layers of your
architecture, and it is a well known and documented pattern. The real importance
here is that you are creating an enterprise back-end integration service that uses
enterprise components for back-end system integration.
Refer to 2.1.1, “Levels of EIS integration” on page 12 for an illustration and
discussion that details the different levels of back-end system integration levels.
When you create domain objects you must ideally have an enterprise data model
that describes your enterprise. If you work for an organization that has many
different business units, chances are good that every business unit has a
different view of their customers and products.
A customer of the home loans business unit could potentially be described
differently than the customer of the vehicle and asset finance business unit. For
example, let’s say you have a schema describing your customer. Is it really
Note: Message Driven Beans do not receive the security identity of the
producer who sends the message, because there is no standard way to stick
security information into a Java Message Service (JMS) message. Therefore,
you cannot perform Enterprise JavaBeans (EJB) security operations with
Message Driven Beans.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.