Intelligent Information Sharing

Ted McLaughlan

Subscribe to Ted McLaughlan: eMailAlertsEmail Alerts
Get Ted McLaughlan: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: SOA Best Practices Digest, IBM Journal, SOA & WOA Magazine, Java Developer Magazine

Article

Providing Extensible and Scalable SOA Infrastructure

XC10 and XI50 Integration

What Is ReST?
ReST stand for Representational State Transfer, which essentially a design pattern for implementing networked systems. ReST essentially uses HTTP as transport to interact with the networked system, in this context it is XC10 appliance.

HTTP provides simple set of operations such as “GET, POST, PUT and DELETE”, and these operations provide CRUD ( Create, Remove. Update, and Delete) capability.

So for instance, when a client or a browser references a URL, a Representation of resource is returned ( e.g. a HTML document). This Representation places a client in a new state. When a client invokes any of the HTML operations ( such as GET, POST, PUT and DELETE), this action places the client application/browser into another state. This is where “Transfer” comes in, the client application transfer state with each resource representation.

ReST is a design pattern and uses HTTP as a transport, and XML,HTML,GIF, JPEG, etc as Resource Representation. While ReST is not a standard, but it does promote the use of standard.

Figure 4: ReST - Representation places a client in a new state

Figure 5: ReST – ReST client/server Interaction

XC10-XI50 Integration:
The idea behind the integration is to enable faster lookup of cache data and reduced processing at backend tiers, with use of XC10 as a general purpose caching appliance. The processing steps will include ( but not limited to)

  1. The XI50 will identify an inbound request based on the local name of the root XML element, extract a customizable set of key/value pairs from the message, and
  2. Check the XC10 for a cached response.
  3. If no cached response is found, the request will be forwarded to the server for normal processing, and the response will then be added to the cache using the key/value pairs from the request.
  4. If a cached response is found on the XC10, then the cached response will be passed through a customizable transformation.

Figure 6: Use of XC10 collectives as a SOA Data Grid. Use with XI50 which is IBM SOA Appliance

Example
XSL Proxy - Specific to XI50 (The XSL Proxy validates and transforms incoming or outgoing XML documents. An XSL Proxy would proxy a remote service, applying all the necessary schema validation and transformations to the incoming document before the message reaches the remote service) -- It  will be this component that will intercept the requests/response and go to XC10 for side cache.

Technical Details

  1. The XC10 provides a REST gateway for accessing data grids hosted by XC10s. This REST gateway is useful when one needs to access data from non-Java environment such as XML documents and perhaps a .NET application.
  2. XC10 REST Gateway is different from WXS REST data service (which was designed for MS ADO.NET data service)
  3. XSL Proxy - Specific to XI50 (The XSL Proxy validates and transforms incoming or outgoing XML documents. An XSL Proxy would proxy a remote service, applying all the necessary schema validation and transformations to the incoming document before the message reaches the remote service) -- It will be this component that will intercept the requests/response and go to XC10 for side cache.
  4. Validation (Not XML validation) but validation of Use cases i.e. either any XML document storage or just security tokens in XC10. Also use case for which XC10-XI50 combo is best suited for.
  5. XC10's HTTP REST interface makes use of the existing Data Power HTTP primitives to store/retrieve, so you can access the appliance directly using primitives already present in the DP XSLT.
  6. With regard to XI50, with our new REST interface (coming in the pending 1.0.0.3 refresh), the XI50 can directly store and retrieve XML documents as long as it has a key for that document.

Business Value

  1. Address Scalability Challenge - core of XC10 business value.
  2. By off-loading the storage/look-up and retrieval of XML documents in XC10, we are also offloading the processing to a  tier parallel to XI50/XS40, this does two things:
    -Speeds up the response -- hence improves performance.
    -Prevents requests going to back end 'middleware' tiers -- addressing scalability.
  3. XC10 can be scaled as need for data grows - classic WXS/XC10 (collective) feature for Scalability proposition.
  4. The idea behind the XI50-XC10 integration is to enable faster lookup of cached data and reduced processing at backend tiers, with use of XC10 as a general purpose caching appliance

Conclusion
The XC10 and XI50 Integration is compelling. The idea behind the XI50-XC10 integration is to enable faster lookup of cached data and reduced processing at backend tiers, with use of XC10 as a general purpose caching appliance. The XI50-XC10 integration has opened up many possibilities to economize on infrastructure costs and further leverage XC10s caching mechanism to speed up XI50 Authentication process. In simplest terms this integration amalgamates the better of two breeds of appliances. This integration speeds the lookup and processing done by XI50, by extensible and scalable cache enabled by XC10.

Acknowledgements
IBM team that made it all possible:

  • Thomas R Gissel - XC10 Team
  • Andrew Grohman - Datapower Team
  • Brian K Martin - XC10 Team
  • Ryan T Claussen - Datapower Team
  • John P Cammarata - XC10 Team
  • Thomas G Watson - Datapower Team

More Stories By Nitin Gaur

Nitin Gaur, is currently working in capacity of Senior WebSphere Consulting IT Specialist with IBMs S&D Organization. Prior to teaming with IBM S&D organization, Nitin spend several years with WebSphere OEM team, a SWG entity and AIX support – ITS/IGS entity. In his 11 years with IBM he has achieved various industry recognized certifications and enriched his career by doing more than required by the defined job responsibilities. Prior to beginning his career with IBM, he was graduate student at University of Maryland University College. Apart from excelling in his normal job responsibilities, Nitin has been involved with many on going projects at IBM Austin. To name a few, Nitin has been an active member of Austin TVC – Technical Vitality Council, an IBM Academy affiliate since 2002.

As a technical leader Nitin has been involved in various technical paper presentations in various conferences at IBM and outside. The range of the topics presented by him span from software architectures to improvement of management processes. Nitin, has been focused on staying close to customer and always attuned to their needs and problems. One of his primary job responsibilities includes positioning WebSphere infrastructure products and providing technical solution and support to field sales teams. He is relentless in researching skills and presenting the industry best practices of IT Infrastructure. Performing advance technical research and providing IBM clients with strategic solutions on WebSphere offerings is one his forte.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.