<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Architectual Styles &#8211; Part Four : Layering</title>
	<atom:link href="http://www.brianlegros.com/blog/2007/10/07/architectual-styles-part-four-layering/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.brianlegros.com/blog/2007/10/07/architectual-styles-part-four-layering/</link>
	<description>eat, program, and be merry</description>
	<lastBuildDate>Tue, 23 Feb 2010 05:56:46 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Brian LeGros</title>
		<link>http://www.brianlegros.com/blog/2007/10/07/architectual-styles-part-four-layering/comment-page-1/#comment-189</link>
		<dc:creator>Brian LeGros</dc:creator>
		<pubDate>Thu, 11 Oct 2007 01:23:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.brianlegros.com/blog/2007/10/07/architectual-styles-part-four-layering/#comment-189</guid>
		<description>@Max - This is a great point regarding the Process layer.  I can see a definite need for this layer with respect to the SOA architecture we&#039;re trying to implement at work.  I see this as a definite place for the domain-specific canonical data model and potentially some type of service discovery related to the ESB.  

As a note though to readers, the Process layer is more of a concern as it come to shared services that don&#039;t share a memory space.  There seems to be a trend of developers creating service APIs that have a 1:1 relationship with their front-end application.  Adding a Process layer for these types of service APIs may be overkill especially since the purpose of these APIs is to expose stateless services for simplicity rather than for re-usability.</description>
		<content:encoded><![CDATA[<p>@Max &#8211; This is a great point regarding the Process layer.  I can see a definite need for this layer with respect to the SOA architecture we&#8217;re trying to implement at work.  I see this as a definite place for the domain-specific canonical data model and potentially some type of service discovery related to the ESB.  </p>
<p>As a note though to readers, the Process layer is more of a concern as it come to shared services that don&#8217;t share a memory space.  There seems to be a trend of developers creating service APIs that have a 1:1 relationship with their front-end application.  Adding a Process layer for these types of service APIs may be overkill especially since the purpose of these APIs is to expose stateless services for simplicity rather than for re-usability.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Maxim Porges</title>
		<link>http://www.brianlegros.com/blog/2007/10/07/architectual-styles-part-four-layering/comment-page-1/#comment-185</link>
		<dc:creator>Maxim Porges</dc:creator>
		<pubDate>Wed, 10 Oct 2007 04:38:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.brianlegros.com/blog/2007/10/07/architectual-styles-part-four-layering/#comment-185</guid>
		<description>I used to look at everything in terms of Service =&gt; Business =&gt; Data/Integration layers, but recently I have added the notion of a Process layer on top of the Service layer.

The need for a Process layer IMO stems from the fact that in an SOA, Services are combined in various ways to form differing business processes, which in themselves are often reusable across different applications. For example, an Order Processing Service may interact with Inventory Service, Payment Service, Customer Management Service, and Fulfillment Service, but be exposed as both a ReST API for B2B interaction and a GUI application for interfacing with human operators. By creating an Order Processing Service in the Process layer, we can reuse the logic without having to replicate anything between applications.

Of course, integration takes place at the Process layer too, because I need to integrate multiple Processes with multiple client systems/services. I see us doing this at CFI through the ESB. Although in reality, all the Services might be exposed to the ESB (most likely grouped on to the same bus by domain) so the distinction of the Process layer is largely a logical separation rather than a physical separation from the bus. I&#039;m hypothesizing here because we don&#039;t have any ESB solutions in place yet.

I&#039;m interested in seeing how BPEL plugs in to this way of thinking. Supposedly, BPEL opens up the ability to model processes against reusable Services, but I haven&#039;t looked at it closely enough to see where it provides benefits. It might just be another standard that promotes the sale of vendor tools rather than solving meaningful problems, or it might be a cleaner way of doing what we&#039;re planning on doing at the process level (however we end up implementing it, Process layer or not).</description>
		<content:encoded><![CDATA[<p>I used to look at everything in terms of Service =&gt; Business =&gt; Data/Integration layers, but recently I have added the notion of a Process layer on top of the Service layer.</p>
<p>The need for a Process layer IMO stems from the fact that in an SOA, Services are combined in various ways to form differing business processes, which in themselves are often reusable across different applications. For example, an Order Processing Service may interact with Inventory Service, Payment Service, Customer Management Service, and Fulfillment Service, but be exposed as both a ReST API for B2B interaction and a GUI application for interfacing with human operators. By creating an Order Processing Service in the Process layer, we can reuse the logic without having to replicate anything between applications.</p>
<p>Of course, integration takes place at the Process layer too, because I need to integrate multiple Processes with multiple client systems/services. I see us doing this at CFI through the ESB. Although in reality, all the Services might be exposed to the ESB (most likely grouped on to the same bus by domain) so the distinction of the Process layer is largely a logical separation rather than a physical separation from the bus. I&#8217;m hypothesizing here because we don&#8217;t have any ESB solutions in place yet.</p>
<p>I&#8217;m interested in seeing how BPEL plugs in to this way of thinking. Supposedly, BPEL opens up the ability to model processes against reusable Services, but I haven&#8217;t looked at it closely enough to see where it provides benefits. It might just be another standard that promotes the sale of vendor tools rather than solving meaningful problems, or it might be a cleaner way of doing what we&#8217;re planning on doing at the process level (however we end up implementing it, Process layer or not).</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.221 seconds -->
