ServiceTechMag.com > Archive > Issue XXXI: August 2009

Issue XXXI August 2009

Viral Data in SOA: An Enterprise Pandemic

Neal Fishman

Neal Fishman

A services-based IT solution such as "A Single View of the Customer", is typically deployed for use as an enterprise-wide business application. The general intent is that any corporate application (such as an order entry system or billing) requiring the use of customer information can interact through a services layer to the single view in order to obtain de facto information for any particular customer. Should any information within the single view prove to be incorrect, all subscribing applications would have had access to the same incorrect data at the same time. Further, should a service that writes or manipulates data in the single view contain a bug, any element that is touched could be compromised. In this way, data can be viewed as having viral properties. In an SOA environment, the effect can be akin to a pandemic-an enterprise pandemic. This article has been adapted from the book "Viral Data in SOA: An Enterprise Pandemic." In the book of Genesis, Adam and Eve consume fruit from the tree of the knowledge of good and evil. Although the type of fruit is not explicitly mentioned, the apple has survived as a popular hypothesis. In the centuries that followed the death of Jesus Christ, the Old and New Testaments were translated into Latin. In Latin, the word for evil (as in the tree of the knowledge of good and evil) is malum. As a Latin word, malum is a homonym. An alternative meaning is apple. To venture into understanding meanings in communication or to delve into linguistics is to study...


Mitigating Service-Orientation Risks with RUP

Rizwan Ahmed

Rizwan Ahmed

With the exponential growth of the Web, REST as an architectural style [REF-1] has found its niche in the modern services landscape with its popularity poised to grow even further. JAX-RS is a new JCP specification [REF-2] that provides a Java API for RESTful Web services over the HTTP protocol. JAX-RS uses annotations on POJOs (Plain Old Java Objects) to map to the RESTful architectural style of presentation and facilitates lookup of distributed enterprise resources via Uniform Resource Identifiers (URIs). In this article I demonstrate a RESTful service-oriented architecture created to wrapper similar functionality as detailed in [REF-3] to enable a client application render an Adobe form and process form submissions abstracted away into Adobe Form Server Module (FSM) factory objects. Corollary to Service Endpoint implementations in JAX-WS, here we have JAX-RS annotated Web Resource classes (the RESTful term for a service) instantiated per each HTTP request that encapsulate the service functionality and Providers that transform the resource parameters and result content into runtime representations in a variety of media types. In an earlier article [REF-3], I had described the solution for a simple JAX-WS service fa├žade for Adobe LiveCycle Forms functionality, callable from any external application. The objective of doing so was to hide away details of how the form rendering and form processing occurs into the service implementation and all clients (including various enterprise applications) that need access to the functionality can easily lookup and consume the provided services via published contracts (WSDL definitions)...


Service Error Content Patterns - Part II

Ronald Murphy

Ronald Murphy

In the previous article of the two-part "Service Error Content Patterns" article series, we established some of the common problems and challenges when working with standard exceptions in messaging environments (Web services and SOAP messaging in particular). In this second series installment of the introduce a set of proposed solutions and techniques for addressing these issues. Specifically, we introduce the Response-Resident Error Pattern, Merged Format Pattern, and the Mixed Usage Pattern. Each of these patterns addresses a different exception problem and scenario. By applying proven design techniques, such as those documented in these three patterns, we can take full control of exception conditions. This leads to a much more sophisticated and flexible enterprise solution design. Furthermore, as patterns, these design techniques are repeatable in that they can be applied to a variety of solution architectures and message exchange frameworks and scenarios. The response-resident error pattern works around the limitations of using faults, by providing for all error information to be modeled as part of your standard operation response messages. Although this does send error modeling somewhat underground from a WSDL standpoint, they can address many of the limitations we identified with fault-based modeling for a given Web service or group of services that you are designing, you can define a bigger "lowest common denominator". You can standardize on a richer error structure to use for all your errors. You can still occasionally extend this structure with optional information used by some services or operations...


2017 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006