Service normalization pattern - Revision history

BD2412: /* Rationale */clean up spacing around commas and other punctuation fixes, replaced: ,M → , M

2024-01-18T20:00:56Z

Rationale: clean up spacing around commas and other punctuation fixes, replaced: ,M → , M

← Previous revision		Revision as of 20:00, 18 January 2024
Line 4:		Line 4:
	When different teams are delivering multiple services as part of automating various business processes, there is a possibility that some of these services might end up having duplicate functionality. For example, the automation of two different business processes, by two different teams, which need to exchange messages with the same legacy system may end up in two different versions of a wrapper service that are created to enable exchange of messages with the services. This overlap in functionality can lead to other problems including which service to be advertised as the official service for the provision of a particular functionality and maintenance of redundant services as they can easily get out of alignment.		When different teams are delivering multiple services as part of automating various business processes, there is a possibility that some of these services might end up having duplicate functionality. For example, the automation of two different business processes, by two different teams, which need to exchange messages with the same legacy system may end up in two different versions of a wrapper service that are created to enable exchange of messages with the services. This overlap in functionality can lead to other problems including which service to be advertised as the official service for the provision of a particular functionality and maintenance of redundant services as they can easily get out of alignment.

	In order to deliver services, as part of the same service inventory, that are free of any duplicate functionality, the functional boundary of each service needs to be carefully established so that it is not in conflict with any other service. The Service Normalization<ref name='IIT'>Thomas Erl, Herbjörn Wilhelmsen.[http://www.informit.com/articles/article.aspx?p=1328796 Service Normalization design pattern][Online]. Date accessed: 6 April 2010.</ref> design pattern provides guidelines for creating service inventories that contain streamlined services without any functional duplication.<ref name='SOAMag'>Thomas Erl.[http://soa.sys-con.com/node/645271?page=0,1 Introducing SOA Design Pattern][Online]. Date accessed: 6 April 2010.</ref> By creating normalized services, the purpose of the service also becomes clearer to its potential consumers.<ref name='Yefim V. Natis,Massimo Pezzini'>Yefim V. Natis, Massimo Pezzini.[http://www.btmg.biz/EA_Kitty3/Documents/Gartner/Gartner1.pdf Twelve Common SOA Mistakes and How to Avoid Them][Online].Date accessed: 25 April 2010.</ref>		In order to deliver services, as part of the same service inventory, that are free of any duplicate functionality, the functional boundary of each service needs to be carefully established so that it is not in conflict with any other service. The Service Normalization<ref name='IIT'>Thomas Erl, Herbjörn Wilhelmsen.[http://www.informit.com/articles/article.aspx?p=1328796 Service Normalization design pattern][Online]. Date accessed: 6 April 2010.</ref> design pattern provides guidelines for creating service inventories that contain streamlined services without any functional duplication.<ref name='SOAMag'>Thomas Erl.[http://soa.sys-con.com/node/645271?page=0,1 Introducing SOA Design Pattern][Online]. Date accessed: 6 April 2010.</ref> By creating normalized services, the purpose of the service also becomes clearer to its potential consumers.<ref name='Yefim V. Natis, Massimo Pezzini'>Yefim V. Natis, Massimo Pezzini.[http://www.btmg.biz/EA_Kitty3/Documents/Gartner/Gartner1.pdf Twelve Common SOA Mistakes and How to Avoid Them][Online].Date accessed: 25 April 2010.</ref>

	==Usage==		==Usage==

Jarble: link design pattern using Find link

2021-05-14T15:26:07Z

link design pattern using Find link

← Previous revision		Revision as of 15:26, 14 May 2021
Line 1:		Line 1:
	'''Service normalization''' is a [[~~Design pattern (computer science)\|~~design pattern]], applied within the [[service-orientation]] [[design paradigm]], whose application ensures that services<ref name='Svc'>[http://www.whatissoa.com/p11.php Services]</ref> that are part of the same service inventory<ref name='serviceinventory1'>[http://www.whatissoa.com/p13.php service inventory]</ref> do not contain any redundant functionality.<ref name='Kanu Tripathi'>Kanu Tripathi.[http://www.soamag.com/I26/0209-3.php Service Transaction Handling Without WS-AtomicTransaction][Online].Date accessed: 25 April 2010.</ref> This design pattern emphasizes on creating [[Database normalization\|normalized services]], much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.		'''Service normalization''' is a [[design pattern]], applied within the [[service-orientation]] [[design paradigm]], whose application ensures that services<ref name='Svc'>[http://www.whatissoa.com/p11.php Services]</ref> that are part of the same service inventory<ref name='serviceinventory1'>[http://www.whatissoa.com/p13.php service inventory]</ref> do not contain any redundant functionality.<ref name='Kanu Tripathi'>Kanu Tripathi.[http://www.soamag.com/I26/0209-3.php Service Transaction Handling Without WS-AtomicTransaction][Online].Date accessed: 25 April 2010.</ref> This design pattern emphasizes on creating [[Database normalization\|normalized services]], much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.

	==Rationale==		==Rationale==

InternetArchiveBot: Rescuing 1 sources and tagging 0 as dead. #IABot (v1.6.5)

2018-05-12T04:39:39Z

Rescuing 1 sources and tagging 0 as dead. #IABot (v1.6.5)

← Previous revision		Revision as of 04:39, 12 May 2018
Line 20:		Line 20:

	==Considerations==		==Considerations==
	The application of this design pattern requires following a top–down service delivery<ref name='top-down service delivery'>[http://www.soamethodology.com/p9.php Top-down service delivery process]</ref> process, which requires considerable upfront analysis before any actual services are delivered. This requires extra resources both in terms of [[man-hour]]s as well as time. This could be addressed by the adoption of meet-in-the-middle<ref name='meet-in-the-middle'>[http://www.soamethodology.com/p13.php meet-in-the-middle service delivery]</ref> service delivery process where the service delivery process can start once sufficient services have been modeled without waiting to create a full service inventory<ref name='serviceinventory2'>[http://www.whatissoa.com/p13.php Service Inventory]</ref> blueprint.		The application of this design pattern requires following a top–down service delivery<ref name='top-down service delivery'>[http://www.soamethodology.com/p9.php Top-down service delivery process] {{webarchive\|url=https://web.archive.org/web/20100509061217/http://www.soamethodology.com/p9.php \|date=9 May 2010 }}</ref> process, which requires considerable upfront analysis before any actual services are delivered. This requires extra resources both in terms of [[man-hour]]s as well as time. This could be addressed by the adoption of meet-in-the-middle<ref name='meet-in-the-middle'>[http://www.soamethodology.com/p13.php meet-in-the-middle service delivery]</ref> service delivery process where the service delivery process can start once sufficient services have been modeled without waiting to create a full service inventory<ref name='serviceinventory2'>[http://www.whatissoa.com/p13.php Service Inventory]</ref> blueprint.

	An ongoing governance of existing normalized services is required as more and more business processes are automated. This is because the automation of new business processes might result in adding functionality to the existing normalized services and to make sure that these services remain normalized, rest of the services need to be analyzed.		An ongoing governance of existing normalized services is required as more and more business processes are automated. This is because the automation of new business processes might result in adding functionality to the existing normalized services and to make sure that these services remain normalized, rest of the services need to be analyzed.

Tony1: Script-assisted fixes: per MOS:NUM, MOS:CAPS, MOS:LINK

2017-10-10T11:31:58Z

Script-assisted fixes: per MOS:NUM, MOS:CAPS, MOS:LINK

← Previous revision		Revision as of 11:31, 10 October 2017
Line 1:		Line 1:
	'''Service ~~Normalization~~''' is a [[Design pattern (computer science)\|design pattern]], applied within the [[service-orientation]] [[design paradigm]], whose application ensures that services<ref name='Svc'>[http://www.whatissoa.com/p11.php Services]</ref> that are part of the same service inventory<ref name='serviceinventory1'>[http://www.whatissoa.com/p13.php service inventory]</ref> do not contain any redundant functionality.<ref name='Kanu Tripathi'>Kanu Tripathi.[http://www.soamag.com/I26/0209-3.php Service Transaction Handling Without WS-AtomicTransaction][Online].Date accessed: 25 April 2010.</ref> This design pattern emphasizes on creating [[Database normalization\|normalized services]], much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.		'''Service normalization''' is a [[Design pattern (computer science)\|design pattern]], applied within the [[service-orientation]] [[design paradigm]], whose application ensures that services<ref name='Svc'>[http://www.whatissoa.com/p11.php Services]</ref> that are part of the same service inventory<ref name='serviceinventory1'>[http://www.whatissoa.com/p13.php service inventory]</ref> do not contain any redundant functionality.<ref name='Kanu Tripathi'>Kanu Tripathi.[http://www.soamag.com/I26/0209-3.php Service Transaction Handling Without WS-AtomicTransaction][Online].Date accessed: 25 April 2010.</ref> This design pattern emphasizes on creating [[Database normalization\|normalized services]], much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.

	==Rationale==		==Rationale==
Line 17:		Line 17:
	The same process needs to be applied to each business process that falls within the boundaries of the service inventory.		The same process needs to be applied to each business process that falls within the boundaries of the service inventory.

	By following the guidelines of the ~~Service~~ ~~Normalization~~ design pattern, the total number of services within the service inventory would also decrease. This is because the development of redundant services is avoided, which further helps in decreasing the [[SOA Governance\|governance]] overhead of the service inventory. The application of this design pattern further supports the application of the [[Logic Centralization Pattern\|~~Logic~~ ~~Centralization~~]] and the [[~~Service~~ ~~Refactoring~~]] design patterns. This is because the services do not contain any redundant functionality and hence it is easy to retain logic that does not relate to a particular business process in a single service and to evolve a service without breaking any dependencies.		By following the guidelines of the service normalization design pattern, the total number of services within the service inventory would also decrease. This is because the development of redundant services is avoided, which further helps in decreasing the [[SOA Governance\|governance]] overhead of the service inventory. The application of this design pattern further supports the application of the [[Logic Centralization Pattern\|logic centralization]] and the [[service refactoring]] design patterns. This is because the services do not contain any redundant functionality and hence it is easy to retain logic that does not relate to a particular business process in a single service and to evolve a service without breaking any dependencies.

	==Considerations==		==Considerations==
	The application of this design pattern requires following a ~~top-down~~ service delivery<ref name='top-down service delivery'>[http://www.soamethodology.com/p9.php Top-down service delivery process]</ref> process, which requires considerable upfront analysis before any actual services are delivered. This requires extra resources both in terms of [[man-hour]]s as well as time. This could be addressed by the adoption of meet-in-the-middle<ref name='meet-in-the-middle'>[http://www.soamethodology.com/p13.php meet-in-the-middle service delivery]</ref> service delivery process where the service delivery process can start once sufficient services have been modeled without waiting to create a full service inventory<ref name='serviceinventory2'>[http://www.whatissoa.com/p13.php Service Inventory]</ref> blueprint.		The application of this design pattern requires following a top–down service delivery<ref name='top-down service delivery'>[http://www.soamethodology.com/p9.php Top-down service delivery process]</ref> process, which requires considerable upfront analysis before any actual services are delivered. This requires extra resources both in terms of [[man-hour]]s as well as time. This could be addressed by the adoption of meet-in-the-middle<ref name='meet-in-the-middle'>[http://www.soamethodology.com/p13.php meet-in-the-middle service delivery]</ref> service delivery process where the service delivery process can start once sufficient services have been modeled without waiting to create a full service inventory<ref name='serviceinventory2'>[http://www.whatissoa.com/p13.php Service Inventory]</ref> blueprint.

	An ongoing governance of existing normalized services is required as more and more business processes are automated. This is because the automation of new business processes might result in adding functionality to the existing normalized services and to make sure that these services remain normalized, rest of the services need to be analyzed.		An ongoing governance of existing normalized services is required as more and more business processes are automated. This is because the automation of new business processes might result in adding functionality to the existing normalized services and to make sure that these services remain normalized, rest of the services need to be analyzed.
Line 29:		Line 29:
	==Further reading==		==Further reading==
	* [[Thomas Erl\|Erl]] et al.,(2009).[https://www.amazon.com/dp/0136135161 SOA Design Patterns]. [[Prentice Hall]]. {{ISBN\|0-13-613516-1}}		* [[Thomas Erl\|Erl]] et al.,(2009).[https://www.amazon.com/dp/0136135161 SOA Design Patterns]. [[Prentice Hall]]. {{ISBN\|0-13-613516-1}}
	* Mauro. et al. [http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 Service Oriented Device Integration - An Analysis of SOA Design Patterns.] [Online], pp. 1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 4 April 2010.		* Mauro. et al. [http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 Service Oriented Device Integration – An Analysis of SOA Design Patterns.] [Online], pp. 1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 4 April 2010.
	* Matthew Dailey.[http://www.cs.ait.ac.th/~mdailey/courseware/index.php?action=getlecture&course_id=37&lecture_id=6 Software Architecture Design Service Oriented Architectures (Part II)][Online].Date accessed: 22 April 2010.		* Matthew Dailey.[http://www.cs.ait.ac.th/~mdailey/courseware/index.php?action=getlecture&course_id=37&lecture_id=6 Software Architecture Design Service Oriented Architectures (Part II)][Online].Date accessed: 22 April 2010.

Line 36:		Line 36:
	* [http://www.soaglossary.com/ SOA Terms Glossary]		* [http://www.soaglossary.com/ SOA Terms Glossary]
	* [http://www.soapatterns.org SOA Design Patterns]		* [http://www.soapatterns.org SOA Design Patterns]
	{{Use dmy dates\|date=~~August~~ ~~2010~~}}		{{Use dmy dates\|date=October 2017}}

	[[Category:Service-oriented (business computing)]]		[[Category:Service-oriented (business computing)]]

Tony1: Tony1 moved page Service Normalization Pattern to Service normalization pattern

2017-10-10T11:31:04Z

Tony1 moved page Service Normalization Pattern to Service normalization pattern

← Previous revision	Revision as of 11:31, 10 October 2017
(No difference)

Johnaldis at 10:37, 18 September 2017

2017-09-18T10:37:20Z

← Previous revision		Revision as of 10:37, 18 September 2017
Line 1:		Line 1:
	'''Service Normalization''' is a [[Design pattern (computer science)\|design pattern]], applied within the [[service-orientation]] [[design paradigm]], whose application ensures that services<ref name='Svc'>[http://www.whatissoa.com/p11.php Services]</ref> that are part of the same service inventory<ref name='~~serviceinventory~~'>[http://www.whatissoa.com/p13.php service inventory]</ref> do not contain any redundant functionality.<ref name='Kanu Tripathi'>Kanu Tripathi.[http://www.soamag.com/I26/0209-3.php Service Transaction Handling Without WS-AtomicTransaction][Online].Date accessed: 25 April 2010.</ref> This design pattern emphasizes on creating [[Database normalization\|normalized services]], much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.		'''Service Normalization''' is a [[Design pattern (computer science)\|design pattern]], applied within the [[service-orientation]] [[design paradigm]], whose application ensures that services<ref name='Svc'>[http://www.whatissoa.com/p11.php Services]</ref> that are part of the same service inventory<ref name='serviceinventory1'>[http://www.whatissoa.com/p13.php service inventory]</ref> do not contain any redundant functionality.<ref name='Kanu Tripathi'>Kanu Tripathi.[http://www.soamag.com/I26/0209-3.php Service Transaction Handling Without WS-AtomicTransaction][Online].Date accessed: 25 April 2010.</ref> This design pattern emphasizes on creating [[Database normalization\|normalized services]], much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.

	==Rationale==		==Rationale==
Line 20:		Line 20:

	==Considerations==		==Considerations==
	The application of this design pattern requires following a top-down service delivery<ref name='top-down service delivery'>[http://www.soamethodology.com/p9.php Top-down service delivery process]</ref> process, which requires considerable upfront analysis before any actual services are delivered. This requires extra resources both in terms of [[man-hour]]s as well as time. This could be addressed by the adoption of meet-in-the-middle<ref name='meet-in-the-middle'>[http://www.soamethodology.com/p13.php meet-in-the-middle service delivery]</ref> service delivery process where the service delivery process can start once sufficient services have been modeled without waiting to create a full service inventory<ref name='~~serviceinventory~~'>[http://www.whatissoa.com/p13.php Service Inventory]</ref> blueprint.		The application of this design pattern requires following a top-down service delivery<ref name='top-down service delivery'>[http://www.soamethodology.com/p9.php Top-down service delivery process]</ref> process, which requires considerable upfront analysis before any actual services are delivered. This requires extra resources both in terms of [[man-hour]]s as well as time. This could be addressed by the adoption of meet-in-the-middle<ref name='meet-in-the-middle'>[http://www.soamethodology.com/p13.php meet-in-the-middle service delivery]</ref> service delivery process where the service delivery process can start once sufficient services have been modeled without waiting to create a full service inventory<ref name='serviceinventory2'>[http://www.whatissoa.com/p13.php Service Inventory]</ref> blueprint.

	An ongoing governance of existing normalized services is required as more and more business processes are automated. This is because the automation of new business processes might result in adding functionality to the existing normalized services and to make sure that these services remain normalized, rest of the services need to be analyzed.		An ongoing governance of existing normalized services is required as more and more business processes are automated. This is because the automation of new business processes might result in adding functionality to the existing normalized services and to make sure that these services remain normalized, rest of the services need to be analyzed.

KolbertBot: Bot: HTTP→HTTPS

2017-09-11T16:31:44Z

Bot: HTTP→HTTPS

← Previous revision		Revision as of 16:31, 11 September 2017
Line 28:		Line 28:

	==Further reading==		==Further reading==
	* [[Thomas Erl\|Erl]] et al.,(2009).[~~http~~://www.amazon.com/dp/0136135161 SOA Design Patterns]. [[Prentice Hall]]. {{ISBN\|0-13-613516-1}}		* [[Thomas Erl\|Erl]] et al.,(2009).[https://www.amazon.com/dp/0136135161 SOA Design Patterns]. [[Prentice Hall]]. {{ISBN\|0-13-613516-1}}
	* Mauro. et al. [http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 Service Oriented Device Integration - An Analysis of SOA Design Patterns.] [Online], pp. 1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 4 April 2010.		* Mauro. et al. [http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 Service Oriented Device Integration - An Analysis of SOA Design Patterns.] [Online], pp. 1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 4 April 2010.
	* Matthew Dailey.[http://www.cs.ait.ac.th/~mdailey/courseware/index.php?action=getlecture&course_id=37&lecture_id=6 Software Architecture Design Service Oriented Architectures (Part II)][Online].Date accessed: 22 April 2010.		* Matthew Dailey.[http://www.cs.ait.ac.th/~mdailey/courseware/index.php?action=getlecture&course_id=37&lecture_id=6 Software Architecture Design Service Oriented Architectures (Part II)][Online].Date accessed: 22 April 2010.

Magic links bot: Replace magic links with templates per local RfC and MediaWiki RfC

2017-06-30T01:41:29Z

Replace magic links with templates per local RfC and MediaWiki RfC

← Previous revision		Revision as of 01:41, 30 June 2017
Line 28:		Line 28:

	==Further reading==		==Further reading==
	* [[Thomas Erl\|Erl]] et al.,(2009).[http://www.amazon.com/dp/0136135161 SOA Design Patterns]. [[Prentice Hall]]. ISBN 0-13-613516-1		* [[Thomas Erl\|Erl]] et al.,(2009).[http://www.amazon.com/dp/0136135161 SOA Design Patterns]. [[Prentice Hall]]. {{ISBN\|0-13-613516-1}}
	* Mauro. et al. [http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 Service Oriented Device Integration - An Analysis of SOA Design Patterns.] [Online], pp. 1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 4 April 2010.		* Mauro. et al. [http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 Service Oriented Device Integration - An Analysis of SOA Design Patterns.] [Online], pp. 1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 4 April 2010.
	* Matthew Dailey.[http://www.cs.ait.ac.th/~mdailey/courseware/index.php?action=getlecture&course_id=37&lecture_id=6 Software Architecture Design Service Oriented Architectures (Part II)][Online].Date accessed: 22 April 2010.		* Matthew Dailey.[http://www.cs.ait.ac.th/~mdailey/courseware/index.php?action=getlecture&course_id=37&lecture_id=6 Software Architecture Design Service Oriented Architectures (Part II)][Online].Date accessed: 22 April 2010.

Rahaeli: cleanup issues appear to be more-or-less dealt with

2014-05-28T03:36:15Z

cleanup issues appear to be more-or-less dealt with

← Previous revision		Revision as of 03:36, 28 May 2014
Line 1:		Line 1:
	{{Multiple issues\|
	{{external links\|date=April 2010}}
	{{refimprove\|date=April 2010}}
	{{more footnotes\|date=April 2010}}
	}}

	'''Service Normalization''' is a [[Design pattern (computer science)\|design pattern]], applied within the [[service-orientation]] [[design paradigm]], whose application ensures that services<ref name='Svc'>[http://www.whatissoa.com/p11.php Services]</ref> that are part of the same service inventory<ref name='serviceinventory'>[http://www.whatissoa.com/p13.php service inventory]</ref> do not contain any redundant functionality.<ref name='Kanu Tripathi'>Kanu Tripathi.[http://www.soamag.com/I26/0209-3.php Service Transaction Handling Without WS-AtomicTransaction][Online].Date accessed: 25 April 2010.</ref> This design pattern emphasizes on creating [[Database normalization\|normalized services]], much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.		'''Service Normalization''' is a [[Design pattern (computer science)\|design pattern]], applied within the [[service-orientation]] [[design paradigm]], whose application ensures that services<ref name='Svc'>[http://www.whatissoa.com/p11.php Services]</ref> that are part of the same service inventory<ref name='serviceinventory'>[http://www.whatissoa.com/p13.php service inventory]</ref> do not contain any redundant functionality.<ref name='Kanu Tripathi'>Kanu Tripathi.[http://www.soamag.com/I26/0209-3.php Service Transaction Handling Without WS-AtomicTransaction][Online].Date accessed: 25 April 2010.</ref> This design pattern emphasizes on creating [[Database normalization\|normalized services]], much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.

Addbot: Bot: Removing {{Orphan}} (Report Errors)

2013-02-15T10:51:08Z

Bot: Removing {{Orphan}} (Report Errors)

← Previous revision		Revision as of 10:51, 15 February 2013
Line 1:		Line 1:
	{{Multiple issues		{{Multiple issues\|
	\|~~orphan~~=April 2010		{{external links\|date=April 2010}}
	\|~~external links~~=April 2010		{{refimprove\|date=April 2010}}
	\|~~refimprove~~=April 2010		{{more footnotes\|date=April 2010}}
			}}
	\|more footnotes = April 2010}}

	'''Service Normalization''' is a [[Design pattern (computer science)\|design pattern]], applied within the [[service-orientation]] [[design paradigm]], whose application ensures that services<ref name='Svc'>[http://www.whatissoa.com/p11.php Services]</ref> that are part of the same service inventory<ref name='serviceinventory'>[http://www.whatissoa.com/p13.php service inventory]</ref> do not contain any redundant functionality.<ref name='Kanu Tripathi'>Kanu Tripathi.[http://www.soamag.com/I26/0209-3.php Service Transaction Handling Without WS-AtomicTransaction][Online].Date accessed: 25 April 2010.</ref> This design pattern emphasizes on creating [[Database normalization\|normalized services]], much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.		'''Service Normalization''' is a [[Design pattern (computer science)\|design pattern]], applied within the [[service-orientation]] [[design paradigm]], whose application ensures that services<ref name='Svc'>[http://www.whatissoa.com/p11.php Services]</ref> that are part of the same service inventory<ref name='serviceinventory'>[http://www.whatissoa.com/p13.php service inventory]</ref> do not contain any redundant functionality.<ref name='Kanu Tripathi'>Kanu Tripathi.[http://www.soamag.com/I26/0209-3.php Service Transaction Handling Without WS-AtomicTransaction][Online].Date accessed: 25 April 2010.</ref> This design pattern emphasizes on creating [[Database normalization\|normalized services]], much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.
Line 38:		Line 38:
	* Matthew Dailey.[http://www.cs.ait.ac.th/~mdailey/courseware/index.php?action=getlecture&course_id=37&lecture_id=6 Software Architecture Design Service Oriented Architectures (Part II)][Online].Date accessed: 22 April 2010.		* Matthew Dailey.[http://www.cs.ait.ac.th/~mdailey/courseware/index.php?action=getlecture&course_id=37&lecture_id=6 Software Architecture Design Service Oriented Architectures (Part II)][Online].Date accessed: 22 April 2010.

	== External links ==		==External links==
	* [http://www.whatissoa.com/ SOA Concepts]		* [http://www.whatissoa.com/ SOA Concepts]
	* [http://www.soaglossary.com/ SOA Terms Glossary]		* [http://www.soaglossary.com/ SOA Terms Glossary]

← Previous revision		Revision as of 03:36, 28 May 2014
Line 1:		Line 1:
	{{Multiple issues\|
	{{external links\|date=April 2010}}
	{{refimprove\|date=April 2010}}
	{{more footnotes\|date=April 2010}}
	}}

	'''Service Normalization''' is a [[Design pattern (computer science)\|design pattern]], applied within the [[service-orientation]] [[design paradigm]], whose application ensures that services<ref name='Svc'>[http://www.whatissoa.com/p11.php Services]</ref> that are part of the same service inventory<ref name='serviceinventory'>[http://www.whatissoa.com/p13.php service inventory]</ref> do not contain any redundant functionality.<ref name='Kanu Tripathi'>Kanu Tripathi.[http://www.soamag.com/I26/0209-3.php Service Transaction Handling Without WS-AtomicTransaction][Online].Date accessed: 25 April 2010.</ref> This design pattern emphasizes on creating [[Database normalization\|normalized services]], much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.		'''Service Normalization''' is a [[Design pattern (computer science)\|design pattern]], applied within the [[service-orientation]] [[design paradigm]], whose application ensures that services<ref name='Svc'>[http://www.whatissoa.com/p11.php Services]</ref> that are part of the same service inventory<ref name='serviceinventory'>[http://www.whatissoa.com/p13.php service inventory]</ref> do not contain any redundant functionality.<ref name='Kanu Tripathi'>Kanu Tripathi.[http://www.soamag.com/I26/0209-3.php Service Transaction Handling Without WS-AtomicTransaction][Online].Date accessed: 25 April 2010.</ref> This design pattern emphasizes on creating [[Database normalization\|normalized services]], much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.