<?xml version="1.0"?>
<rss version="2.0">

<channel>
	<title>The SOA Magazine Contributions by John deVadoss</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-2010, SOA Systems Inc.</copyright> 
	<item>
		<title>Understanding Service Composition, Part III: Dealing With Data</title>
		<link>http://www.soamag.com/I40/0610-3.php</link>
		<description>
To their detriment many service-oriented architecture efforts tend to prioritize and focus on the technology connectivity (such as SOAP, HTTP, and WS-*), between and across services, over the business connectivity (such as, the task of exchanging and communicating business concepts and entities and their semantics). The ability to harmonize business entities and concepts across multiple services is critical to successful service composition. How does this manifest itself? Let us once again consider the self-service application scenario; but this time, let us consider a customer scenario in a large bank. The customer service representatives require a single view of the customer in order to enable superior customer service, to enable better decision making and to enhance the relationship with the customer, both to retain existing customers as well as to acquire new ones. The challenge with building a service-oriented architecture to support these requirements is that often there is no single store of customer data in the bank; and, the customer data is fragmented across multiple legacy business systems. In the real world there is often no single identifier for the customer data - the bank may have built some applications in-house, such as it may have acquired some other applications off-the-shelf and some services have been brought on-board as part of recent mergers with other smaller banks. Combining data to provide a single view of the customer is hard enough, but without a common identifier it is that much harder... 

		</description>
		<category>SOA</category>
		<guid>http://www.soamag.com/contributors/bio-jdevadoss.php#When:04.01.</guid>
	</item>
<item>
		<title>Understanding Service Composition, 
Part II: Dealing With Identity </title>
		<link>http://www.soamag.com/I39/0510-2.php</link>
		<description>
Services often enforce a trust boundary. A service typically does not trust another external service and will do its own due diligence with respect to granting access and execution privileges to service requests. Incoming messages will be inspected; fields will be validated; identity will be authenticated, and entitlements will be validated prior to allowing incoming service requests to be processed. There is typically a workflow of tasks that is prescribed prior to fulfilling external service requests, comprised of authentication (validating the identity of the incoming service request), authorization (validating the right to access resources and business functions), and auditing (recording and tracking who did what and when). In this context, dealing with trust and identity across multiple services is essential and commonly a pre-requisite to enabling service composition in the real world. A lack of a first-class emphasis on dealing with identity across multiple services leads to identity and access management becoming a challenge and often a hurdle for realizing service-oriented architectures... 

		</description>
		<category>SOA</category>
		<guid>http://www.soamag.com/contributors/bio-jdevadoss.php#When:04.01.</guid>
	</item>
	<item>
		<title>Understanding Service Composition, 
Part I: Dealing With Workflow Across Services </title>
		<link>http://www.soamag.com/I38/0410-2.php</link>
		<description>
Whenever a service composes another service, meaning that one service uses the capabilities of another service or services to perform its own tasks, usually by means of workflow technologies, autonomy will be affected. In other words, when your service directly depends on one or more services the level of freedom and control you have in developing the service will be limited. The level of control over different runtime characteristics may also be affected. If you make synchronous calls to another service you will affect the control over runtime resources, such as threads. If you need to wait for the response of another service before you can return a response from your service, you depend on that other service in terms of response times. That translates into reduced predictability of how your service performs. To make matters more challenging, response times are often regulated by SLAs... 

		</description>
		<category>SOA</category>
		<guid>http://www.soamag.com/contributors/bio-jdevadoss.php#When:04.01.</guid>
	</item>
	
</channel>
</rss>

