https://training-course-material.com/index.php?action=history&feed=atom&title=ServiceService - Revision history2026-04-14T23:41:41ZRevision history for this page on the wikiMediaWiki 1.45.1https://training-course-material.com/index.php?title=Service&diff=7244&oldid=prevIzabela Szlachta at 18:44, 8 November 20122012-11-08T18:44:07Z<p></p>
<p><b>New page</b></p><div>{{Cat|SOA|20}}<br />
{{Soa Links}}<br />
<br />
''The OASIS SOA Reference Model states:''<br />
<br />
The noun “service” is defined in dictionaries as “The performance of work (a function) by one for another.”<br />
<br />
<br />
== Service in SoaML ==<br />
A Service represents a feature of a Participant that is the offer of a service by one participant to others using well defined terms, conditions and interfaces.<br />
<br />
[[File:Soa-service-soaml.jpg|320px]]<br />
<br />
<br />
== Contract ==<br />
*The complete description of a service from a consumer’s point of view (signature and semantics) is called a “well-defined interface” or “contract.” <br />
*A contract is agreed individually between a certain provider, and a certain consumer, and usually includes nonfunctional aspects such as SLAs.<br />
<br />
<br />
== SLA ==<br />
*ABA (Abandonment Rate): Percentage of calls abandoned while waiting to be answered<br />
*ASA (Average Speed to Answer): Average time (usually in seconds) it takes for a call to be answered by the service desk.<br />
*TSF (Time Service Factor): Percentage of calls answered within a definite timeframe, e.g. 80% in 20 seconds.<br />
*FCR (First Call Resolution): Percentage of incoming calls that can be resolved without the use of a callback, or without having the caller call back the helpdesk to finish resolving the case.<br />
*TAT (Turn Around Time): Time taken to complete a certain task.<br />
*Uptime<br />
<br />
<br />
== ServiceContract in SoaML ==<br />
[[File:Soa-servicecontract.png|300px]]<br />
<br />
*A ServiceContract is the formalization of a binding exchange of information, goods, or obligations between parties defining a service.<br />
*A ServiceContract is the specification of the agreement between providers and consumers of a service as to what information, products, assets, value and obligations will flow between the providers and consumers of that service – it specifies the service without regard for realization, capabilities or implementation.<br />
<br />
<br />
==Services and Business Functionality==<br />
*Services Represent Business Functionality<br />
*SOA is focused on business processes<br />
*“natural” step of business functionality<br />
*self-contained (explained later)<br />
*business people should be able to understand what a service does <br />
<br />
<br />
==Interfaces and Contracts==<br />
*Service is an interface for messages that return information and/or change the state of an associated entity (backend)<br />
*“interface-oriented architecture.”<br />
<br />
<br />
==Interfaces in SoaML==<br />
*Provides the definition of a service. <br />
*Defines the specification of a service interaction as the type of a «Service» or «Request» port.<br />
<br />
[[File:Soa-interfaces-soaml.png]]<br />
<br />
<br />
==Business vs Technically Driven Interfaces==<br />
'''Technically Driven Interfaces'''<br />
customerOP(action, // "create", "read", "change", "delete"<br />
id, // customer id or null<br />
name, // new customer name or null<br />
address, // new customer address or null<br />
account) // new customer bank account or null<br />
<br />
<br />
'''Business Driven Interface'''<br />
createCustomer(name, // new customer name<br />
address, // customer address<br />
account) // customer bank account<br />
readCustomer(id) // customer id<br />
changeCustomerAccount(id, // customer id<br />
account) // new customer bank account<br />
changeCustomerAddress(id, // customer id<br />
address, // new customer address<br />
check, // true: verify address<br />
modify) // true: fix address if possible<br />
deleteCustomer(id) // customer id<br />
<br />
<br />
==Service Attributes==<br />
*Do services have to be stateless?<br />
*Do they have to be implemented as Web Services?<br />
*Should they be coarse-grained and/or composable?<br />
<br />
<br />
==Coarse-Grained==<br />
*Services are abstractions that hide implementation details from the consumers<br />
*The price for the abstraction is performance<br />
*There is no clear definition of “coarse-grained” service<br />
<br />
<br />
==Visible/Discoverable==<br />
*Services must be searchable<br />
*Usually there is some kind of catalogue and taxonomy (see UDDI) <br />
<br />
<br />
==Stateless==<br />
There is always some state involved<br />
*Technical state<br />
*Business state<br />
<br />
<br />
==Idempotent==<br />
*Whether we can call the service many times (for example in case of no response) without risking doing the thing twice<br />
*Idempotency is the ability to redo an operation if you are not sure whether it was completed<br />
*Changing status function may be ideponent<br />
*SwitchStatus() versus setActive()<br />
<br />
<br />
==Reusable==<br />
*Avoiding redundancy is a general goal of software development<br />
*Ideally each functionality should be implemented only once<br />
*It may cause performance issue<br />
*As a result, reusability may be a goal, but not a rule<br />
<br />
<br />
==Composable==<br />
*Services can use/call other services<br />
*Discussed further in BPM section<br />
<br />
<br />
==Other attributes==<br />
*Technical (reusing the infrastructure)<br />
*QoS- and SLA-Capable<br />
*Pre- and Post-Conditions<br />
*Vendor-Diverse<br />
*Interoperable<br />
<br />
<br />
==Questions==<br />
*What does the “well-defined interface” or “contract” contain?<br />
*What does a typical SLA contain?<br />
*What does it mean composable?<br />
*What does it mean idempotent?</div>Izabela Szlachta