<?xml version="1.0"?>
<rss version="2.0">

<channel>
	<title>The SOA Magazine Contributions by Ronald Murphy </title>
	<link>http://www.soamag.com</link>
	<description>
The SOA Magazine is a monthly online publication provided by SOA Systems Inc. and Prentice Hall/PearsonPTR and is officially associated with the "Prentice Hall Service-Oriented Computing Series from Thomas Erl."
	</description>
	<category>SOA</category>
	<language>en-us</language>
	<copyright>Copyright 2006-2009, SOA Systems Inc.</copyright> 

	
	<item>
		<title>Service Error Content Patterns (Part II)  </title>
		<link>http://www.soamag.com/I31/0809-3.asp</link>
		<description>
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... 
		</description>
		<category>SOA</category>
		<guid>http://www.soamag.com/I31/0809-3.asp#When:31.08.09</guid>
	</item>	
	
	
	<item>
		<title>Service Error Content Patterns (Part I)  </title>
		<link>http://www.soamag.com/I30/0709-2.asp</link>
		<description>
Exceptions are a necessary evil in the world of service development and one that must be controlled and planned for. Allowing exceptions just to happen can have numerous negative consequences, especially when relying upon some of the more common fault handling options made available to us with current Web-based technologies. In this two-part article series we'll explore several successful techniques for controlling runtime error conditions and ensuring that their occurrence does not unnecessarily (or chaotically) disrupt the business process flow. The techniques form actual development patterns that can be applied to different types of services based on different types of service technologies. The biggest strength of exceptions can also be their biggest weakness, one which is well known to anyone who has worked with them: Exceptions fundamentally change the processing flow.
		</description>
		<category>SOA</category>
		<guid>http://www.soamag.com/I30/0709-2.asp#When:30.07.09</guid>
	</item>

	<item>
		<title>SOA and the XML Factor: Designing Service-Oriented Solutions with Extreme XML Compatibility  </title>
		<link>http://www.soamag.com/I29/0509-1.asp</link>
		<description>
Interfaces of all kinds are subject to change. When we make a change to the operations or data offered by a service contract, this change will have an impact the consumers of the interface. In the world of SOA and service-orientation, attention to interface - or service contract - versioning is paramount because the average service-oriented enterprise ends up establishing many more dependencies on a published technical interface than traditional, silo-based application environments. One change can therefore have a ripple effect by impact numerous service consumers, each of which may have been composing the service for a different purpose. This article explores common service contract versioning challenges and proposes different approaches with an emphasis on helping you achieve "extreme" XML compatibility. 
		</description>
		<category>SOA</category>
		<guid>http://www.soamag.com/I29/0509-1.asp#When:30.05.09</guid>
	</item>	
	
</channel>
</rss>
