180 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
proxy. External services are imported into the Gateway and made available
internally to the enterprise as proxy services . Likewise, internal services are
imported into the Gateway and made available as proxy services externally.
These services are also published to the relevant UDDI directories where
required.
7.5 Quality of service for Web services
Quality of service (QOS) refers to the capability of a platform to provide a better
service to a selected application.
It is a challenge to build systems that deliver extremely high levels of service
because many variables need to be considered. The success of an application
depends on scalability, performance, availability, security, and manageability,
among other things, and all these are critical considerations if you are to avoid
failure.
In terms of Web Services, QOS covers a range of techniques that match the
needs of service requestors with those of the service provider's that are based on
the network resources that are available.
This section describes some considerations about QOS in a Web service
context. It does not discuss the scalability and availability topics, because these
issues are inherent to the underlaying middleware platform that hosts the Web
services. For details of these topics as related to the WebSphere platform see
the references in 7.6, “Further information” on page 195.
7.5.1 Performance
Often non-functional requirements are overlooked. It can happen that a project
manager faces the performance issue only in a production environment when the
performance challenge should be considered from the design phase of the
project.
One of the major drawbacks of the Web services technology is the performance
issue. The great interoperability of Web services is often paid for in terms of the
increased time for processing the message. XML parsing is always a heavy job,
even as parsers are becoming smarter.
The service designer should consider that service granularity has a significant
impact on the response time of Web services and decide on the level of
granularity of the functions to be exposed as Web services to avoid unnecessary
message exchanges across the Internet.
Chapter 7. Using Web services 181
As a performance rule, the service designer should strive to publish coarse
grained services that accept all necessary parameters and information, thereby
allowing the service provider to accomplish as much as possible on behalf of the
consuming application. The goal is to minimize the number of requests that a
consumer makes in order to accomplish a set of business tasks. A minimum
number of requests ensures minimal effects due to network latency, system I/O,
and thread or process wait states that when aggregated with multiple requests
can result in significant delays.
For example, in case of a purchase order service, it is a good idea to allow the
consumer to specify product SKU numbers, quantities, credit or debit card
information, billing and shipping address information, and discount coupons all
within a single request. The request itself may initiate multiple atomic
transactions (credit card authorization, submission of charges, inventory query
and update, and order fulfillment) at the service provider that can each be
undone or reversed if needed while supporting the overall business process.
WebSphere Application Server V5.1 has introduced many enhancements on the
performance side for the Web services so that migration to the latest release can
improve performance with a factor that can vary from two to four. It has also
added a cache capability for Web services called the
WebSphere dynamic cache
service
. For those cases where it is applicable, Web services performance using
the dynamic cache is greatly augmented.
The cache mechanism needs a unique identifier to recognize which service
requests can be served by the same reply. The tools let the user specify this
identifier from Web services specific component, s including:
???? SOAP Action
???? SOAP Envelope
???? Servlet path (in the JSR 109 case, this refers to a port-component)
???? SOAP operation (requires parsing of the SOAP message)
???? SOAP operation parameters (requires parsing of SOAP message)
An essential tool is Tivoli® Performance Monitor that is packaged with
WebSphere Application Server. This tool receives performance data from the
application server and plots performance graphics at run-time (see Figure 7-7 on
page 182).
182 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
Figure 7-7 Tivoli Performance Monitor showing a Web service report
You can choose from the deployed Web services and filter the performance data
for a particular Web service. The Performance Advisor, which is a new
autonomic computing feature, can be used to give some tuning
recommendations based on the collected data.
Cache at work
The use of the dynamic cache service can be a bit tricky. For this reason, this
section describes some simple steps to help you use this feature.
The first step is to enable the dynamic cache service for the instance of
application server where your service is running. To do this, in the WebSphere
Chapter 7. Using Web services 183
Administrative Console, select Servers
→ Application Servers → server →
Dynamic Cache Service (where server is the name of your server instance).
The Web services cache is related to the servlet cache, so you also need to
enable the servlet cache by following these steps:
1. Open the WebSphere Administrative Console.
2. Select Servers
→ Application Servers in the console navigation tree.
3. Choose the server where your Web services are deployed.
4. Click Web Container.
5. Select Enable servlet caching in the Configuration tab.
6. Click Apply or OK.
7. Restart WebSphere Application Server.
The dynamic cache service parses the cachespec.xml file on startup and
extracts from each <cache-entry> element a set of configuration parameters.
You have to add cachefile.xml in the WEB-INF directory of the Web project
where the Web services are deployed. If you use WebSphere Studio Application
Developer (or the Integration Edition), it is helpful to copy the schema file,
cachescec.dtd, into the WEB-INF directory to have the automatic XML validation
and content assist. You can find the file in the properties directory under the
WebSphere installation directory.
Every time a new servlet or other cacheable object initializes, the cache attempts
to match each of the different cache-entry elements, to find configuration
information for that object. Different cacheable objects have different <class>
elements. You can define a cache policy using the <name> element to identify
uniquely the object you want to cache.
It can be useful take a look at the WSDL of your service to find the information
that you need to compile the cachespec.xml file. In the case of Web service, you
have to specify webservice for the class element and the port for name element.
The cache-id section collects the information that uniquely identifies a service
request. Thus, two service requests with the same cache-id can be served by the
same reply.
184 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
Example 7-1 shows how to implement simple cache logic.
Example 7-1 Cachefile.xml used in our proof of concepts
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cache SYSTEM "cachespec.dtd" >
<cache>
<cache-entry>
<class>webservice</class>
<name>/services/StockAnalysisBPStockAnalysisHTTPServicePort</name>
<cache-id>
<component id="" type="serviceOperation">
<value>http://processes.itso.ibm.com/StockAnalysis:getAnalysis</value>
<required>true</required>
</component>
<component id="stockName" type="serviceOperationParameter" />
<timeout>60</timeout>
</cache-id>
</cache-entry>
</cache>
A request is identified uniquely by the operation name and the parameter value.
The cachespec.xml file allows you to add logic to invalidate the cache.
7.5.2 Security
Security is a challenging topic because there are a lot of implications to consider.
This section discusses those security aspects that are related to our scenario of
EIS integration and simple partner communication.
The majority of the aspects related with the Web services security are defined in
Security in a Web Services World: A Proposed Architecture and Roadmap, a
joint white paper from IBM and Microsoft. You can find this white paper at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/
html/securitywhitepaper.asp
In our scenario, we want to achieve a the following goals:
???? To internally expose the EIS and avoid unauthorized use.
???? To establish a point-to-point private communication between two well known
and trusted partners that follows a traditional agreement.
Tip: The cachefile.xml file refers to the operation name using the namespace
prefix.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.