<?xml version="1.0"?>
<rss version="2.0">

<channel>
	<title>The SOA Magazine</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 2010, SOA Systems Inc.</copyright> 

	<item>
		<title>The SOA Magazine Issue XL, June 2010 (Editor, Thomas Erl)</title>
		<link>http://www.soamag.com</link>
		<description>

I'd like to encourage those of you in the social media space to visit the Official Facebook Group for the Prentice Hall Service-Oriented Computing Series. As most of you know, the original site mysteriously disappeared a few weeks ago, along with a rather large membership. The newly rebuilt site is being supported by Prentice Hall and SOA School with regular book and SOACP self-study kit giveaway contests. 

I'd also like to congratulate Brian Loesgen, John deVadoss and Christoph Schittko for a successful launch of the "SOA with .NET &amp; Windows Azure" book at last week's TechEd conference in New Orleans (he TechEd bookstore reported that the title remained on their top-seller list during the event). The next book planned for release is "SOA Governance", set to be launched at the upcoming 3rd International SOA Symposium. 

		</description>
		<category>SOA</category>
		<guid>http://www.soamag.com/default.php#When:10.03.10</guid>
	</item>


	<item>
		<title>SOA Scorecard</title>
		<link>http://soamag.com/I40/0610-1.php</link>
		<description>

Measuring the performance of any initiative is imperative for its success. "If you don't measure it, you won't improve it" is something that we've found to continually be true. In the past few years, the Service Oriented Architecture (SOA) has become an accepted architectural paradigm, but SOA metrics have not kept up. While, some organizations have had success utilizing SOA, this has typically been in spite of lack of SOA metrics, not because of it. Organizations often struggle in translating technology value of an initiative into business value that the business organization can really understand. Though SOA is supposed to help in technology connecting with the business, there is very minimal prescriptive literature and framework that can guide us in terms of aligning the business and IT. This article looks at utilizing a strategic performance management tool. A "Balanced Scorecard" is a concept that has been around for some time, used for measuring the overall impact of an initiative or department (for example, an "IT Balanced Scorecard"). Extending this concept to SOA makes sense and will be useful for measuring the performance of SOA. Instead of looking at which specific business initiatives SOA can support to drive the revenue numbers, this article looks at SOA itself as a business and should help you to initiate the creation of a Balanced Scorecard for SOA... 
		

 		</description>
		<category>SOA</category>
		<guid>http://soamag.com/I40/0610-1.php#When:10.03.10</guid>
	</item>
	
		<item>
		<title>Understanding SOA Governance</title>
		<link>http://soamag.com/I40/0610-2.php</link>
		<description>

Effective governance is a critical element in fostering a successful SOA initiative. SOA promises to deliver a number of important business benefits, including faster time-to-market, lower costs, better consistency, and increased agility. But with great benefits come high risks. SOA requires fundamental changes to the planning, development, and operation of application systems, and it requires new levels of collaboration among project teams within the IT department and across lines of business. In fact, current IT practices, which typically focus on individual projects, time-to-market, and cost containment, frequently discourage SOA adoption. SOA governance helps the organization succeed with SOA by mitigating these risks through established rules, processes, and decision-making authority. A SOA governance program helps people do things according to the organization's goals and best practices. An effective governance program empowers people to handle ambiguity, balance short- and long-range goals, and reduce conflict within the organization. This following article (an excerpt from the upcoming book "SOA Governance" as part of the Prentice Hall Service-Oriented Computing Series from Thomas Erl) provides an introduction to governance, explains how it works, and differentiates it from management. You will find this content useful if you have not been involved in establishing a governance program before or if you would like to gain another perspective on the mechanics of governance... 
 		</description>
		<category>SOA</category>
		<guid>http://soamag.com/I40/0610-2.php#When:10.03.10</guid>
	</item>		
	
	
		<item>
		<title>Understanding Service Composition, Part III: Dealing With Data</title>
		<link>http://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://soamag.com/I40/0610-3.php#When:10.03.10</guid>
	</item>

	
	

	<item>
		<title>Effective Top-down SOA Management in an Efficient Bottom-up Agile World (Part 1)</title>
		<link>http://soamag.com/I38/0410-1.php</link>
		<description>
As with politics and religion, information technology has its armies that fight for great truths in the name of half-truths. And one great half truth is that Agile and SOA are incompatible. On the face of it, that seems true. Service-oriented architecture must be top-down in conception and execution for it to be effective. Agile is a bottom-up systems development methodology that emerges from self-organizing collectives. SOA and Agile have both demonstrated their value and have firmly established themselves in the marketplace. And yet the experience of more than a decade at many hundreds of firms has exposed flaws in how SOA and Agile are practiced in the real world where vast resources are at stake. The purpose of this article is to reconcile these two paradigms into a complementary partnership... 


 		</description>
		<category>SOA</category>
		<guid>http://soamag.com/I38/0410-1.php#When:10.03.10</guid>
	</item>
	
		<item>
		<title>Understanding Service Composition, 
Part I: Dealing With Workflow Across Services</title>
		<link>http://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://soamag.com/I38/0410-2.php#When:10.03.10</guid>
	</item>		
	
	
		<item>
		<title>XML Appliances for Service-Oriented Architectures</title>
		<link>http://soamag.com/I38/0410-3.php</link>
		<description>

		XML appliances are a type of SOA intermediary that typically comes in hardware form factor and addresses the security threats associated with modern XML architectures. They are primarily geared towards security enforcement, monitoring and transformation. More recently, XML appliances also made inroads into the area of SOA management and governance. XML appliances contain hardened chips that can process XML in specialized circuits, at "wire-speeds". This yields high throughput and low latency, which are relevant criteria for deployment at the network perimeter. Many SOA security issues and XML-specific threats can be detected very efficiently by XML appliances. They allow turn-key deployment because of the hardware form factor... 

		
		
 		</description>
		<category>SOA</category>
		<guid>http://soamag.com/I38/0410-3.php#When:10.03.10</guid>
	</item>
	

	<item>
		<title>Leveraging the Next Generation SOA Ideals
for Service Oriented Enterprises (SOEs)</title>
		<link>http://soamag.com/I39/0510-1.php</link>
		<description>
The mantra of every customer-facing business in this planet is to do more with less. This notion has drawn considerable attention these days due to the pervasive economic slump. Worldwide enterprises down with sluggish economy are hence keenly looking out for trend-setting inventions, innovations and non-linear methods in order to be competitively ahead in their service and solution offerings. Executives are seeking out novel and nimbler business, pricing and delivery models. Technical managers and architects are on their toes in order to unearth unconventional development approaches for faster software realization, integration, and modernization. Professionals and pundits are coming out with cutting-edge technologies, simplifying patterns, enabling architectures, and facilitating frameworks... 
 		</description>
		<category>SOA</category>
		<guid>http://soamag.com/I39/0510-1.php#When:10.03.10</guid>
	</item>
	
		<item>
		<title>Understanding Service Composition,
Part II: Dealing With Identity </title>
		<link>http://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... 

 		</description>
		<category>SOA</category>
		<guid>http://soamag.com/I39/0510-2.php#When:10.03.10</guid>
	</item>		
	
	
		<item>
		<title>Effective Top-Down SOA Management 
In An Efficient Bottom-Up Agile World (Part 2) </title>
		<link>http://soamag.com/I39/0510-3.php</link>
		<description>
System building is a search for truth, and SOAG is no exception. We must establish SOAG on a foundation of sound epistemology. SOAG must be above all a rational process, a process that binds us to principles of empirical adequacy and rational coherency without respect to what I believe or to what the team believes. Empirical adequacy requires that the concept under question be amendable to empirical verification and asks the question: does it meet the evidence? Rational coherency requires that the concept should be consistent with other concepts that were arrived at rationally. It asks the question: is it consistent within itself? SOAG asks us to think for ourselves. But, in contrast to Agile, SOAG makes the radical claim that we should not think for ourselves. "It is a profoundly erroneous truism, repeated by all copybooks and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing," writes Alfred North Whitehead. "The precise opposite is the case. Civilization advances by extending the number of important operations that we can perform without thinking about them. Operations of thought are like cavalry charges in a battle-they are strictly limited in number, they require fresh horses and must only be made at decisive moments."... 
		
 		</description>
		<category>SOA</category>
		<guid>http://soamag.com/I39/0510-3.php#When:10.03.10</guid>
	</item>
	

	
	
</channel>
</rss>









