SOA
- Service is a program you
interact via message exchange. Message is any kind of
data that is sent to a Service. Microsoft laid out
following four doctrines (MS says them as tenets):
- Boundaries are
Explicit
- A service's boundary is published by means of WSDL and may include assertions dictating the expectations of a given service. So every thing should be declared explicitly in WSDL instead of relying on some implicit behaviors.
- Services have explicit
boundaries and are assumed to be expensive to traverse in order to make it more
understandable and expressive.
- Location, Security and Execution factors define the service boundary. Changing location may change the network configuration and suddenly consumers can experience performance degradation without they changing anything.
- Similarly changing security setting may breach any existing contract as systems are complex. Marshaling and casting of data could change by changing boundaries.
- Services are
Autonomous:
- Application or any other
consumer should not influence the way service is implemented. Complete
de-coupling.
- Service may gradually
enhance its implementation, but it doesn't affect consumers by any means.
- Services are not to be confused with application
workflow or business process. Those might incorporate multiple services, but a
service operates independently from other services.
- Each service should be constructed to be able to stand alone with no external dependencies on other services.
- Services share schema
and contract, not class:
- Information is passed by
value. Not like pass objects and let them work in service boundary and control
it from application (RPC Style).
- To know what service you need to consume, you just need to know it's schema not the way it does.
- Service compatibility
is determined based on policy
General (Not specific to Microsoft def) Web Services Principles:
- Object Oriented , Service Oriented, Component base development - All based on the principle of "separation of concern" , This theory is based on the notion that it is beneficial to break down a large problem into a series of smaller, individual problems or concerns. This allows the logic required to solve the larger problem is now decomposed into a collection of smaller, related pieces. Each piece of logic addresses a specific concern. It's just that Service Oriented architecture implement this in a different way.
- The most recent results establish the following eight principles:
- services share a formal contract [CORE] - Boundaries are explicit.
- services are loosely coupled [CORE] - Share contract not class.
- services abstract underlying logic [CORE] - Policy
- services are autonomous [CORE] - Autonomous.
- services are reusable
- services are discoverable
- services are composable
- services are stateless
- Core principles directly enable the realization of the remaining principles.
- 1.Service Contracts: Service description document.
- In web services there are two technical description document which solves this purpose: WSDL definition and XSD Schema.Third type of document is also required that is Policy document.
- Service description documents can be collectively viewed as establishing a service contract – a set of terms and conditions that must be met and accepted by a potential service requestor in order to enable successful communication and interaction. (Note that a service contract can also refer to additional non-technical documents or legal agreements, such as SLAs.) Within SOA, service contracts provide a formal definition of:
- the service endpoint
- each service operation
- every input and output message supported by each operation
- the data representation model of each message's contents
- rules and characteristics of the service and its operations
- Because this contract is shared amongst services, its design is extremely important. Service requestors that agree to this contract can become dependent on its definition. Therefore, contracts need to be carefully maintained and versioned after their initial release
- This enables other principle such as abstraction, composability, discoverability and loose coupling.
- 2.Loose coupling:
- Being able to ultimately respond to unforeseen changes in Business or workflows in an efficient manner is a key goal of applying service-orientation. Realizing this form of agility is directly supported by establishing a loosely coupled relationship between services and between service and requestor.
- Distributed architecture models are based on the fact that Small logics/concern can be composed together to automate a business task. One of the characteristics that distinguishes SOA from its predecessors is how these units of logic are required to relate to each other. Ideally they should not relate to each other and it called decoupled or loosely coupled and it is accomplished by limiting the dependencies between a service and its requestors by the information expressed in the service contract – and –designing the service contract in such a way that it is not necessarily specific to any one service requestor.
- When creating multiple services in pursuit of establishing a service-oriented enterprise, these services can be categorized into specific service models. This allows them to become specialized in the type of logic they encapsulate. One increasingly important service model is the business service, which limits the logic a service represents to the accurate expression of a specific business context. Or there are Infrastructure services.
- 3.Abstraction:
- it is this principle that encourages us to establish services as black boxes, intentionally hiding their underlying details from potential consumers.There is no limit to the amount of logic a service can represent. Services abstract not only lot of business logic but also specific vendor interfaces or lot of connectivity.
- This puts a great deal of emphasis on the design of the service contract. The more that is expressed in the service contract, the less details we end up abstracting. The more generic we make the service contract, the less process or consumer-specific the service becomes. This then determines the reuse potential of what we choose to expose (to not abstract) through the service contract.
- 4.Service Autonomous:
- Since service are reusable components, over a period of time, the same service will need to facilitate the automation of different business processes or tasks and may become part of numerous service compositions. This eventuality translates into high usage volumes, unpredictable usage scenarios and a runtime condition such as concurrency. Service Autonomy and Stateless are design consideration which allow us to handle these scenarios.
- Autonomy is each service should be a building block in the enterprise service inventory. So that each service can be part of one or many business automation process. i.e. any service can be moved to different business process stack without requiring to move many dependent services.
- By increasing the amount of control a service has over its own execution environment, we reduce dependencies it may otherwise require on shared resources within the enterprise. Even though we cannot always provide a service with exclusive ownership of the logic it encapsulates, our primary concern is that it attains a reasonable level of control over whatever logic it represents at the time of its execution.
- Service-level autonomy – Service boundaries are distinct from each other, but the service may still share underlying resources. For example, a wrapper service that encapsulates a legacy environment that also is used independently from the service has service-level autonomy. It governs the legacy system, but also shares resources with other legacy clients.
- Pure autonomy – The underlying logic is under complete control and ownership of the service. This is typically the case when the logic is built from the ground up in support of the service. (COSTLY).
- 5.Reusability:
- Service-orientation encourages reuse in all services, regardless of whether immediate requirements for reuse exist. This fundamental principle forces us to pay extra attention to each delivered unit of automation logic we want to call a "service."
- It reduces response time and cost of organization to any specific changes.
- The emphasis on far reaching reuse also highlights the suitability of Web services as an implementation option for services. By making each service available via an industry standard communications framework (as available as wcf or dll or windows services), reuse potential can broaden dramatically because the logic encapsulated by a service now becomes accessible to service requestors built with different underlying technologies.
- It is the content of this contract that determines what is and is not abstracted. It is through the design of this content that we can determine how generic and reusable the non-abstracted parts actually are. This raises the need to truly view the design of a service as an investment. Building service-oriented solution logic is almost always more expensive and more time consuming because considerations need to be taken into account that go beyond immediate tactical requirements.
- 6.Service discoverability
- Even the most reusable service is not useful if it cannot be found by those responsible for creating potential consumers. Furthermore, even the most loosely coupled services will have limited reuse potential if they cannot be assembled into effective compositions. This is where the principles of service discoverability and service composition come into play.
- The characteristic of discoverability essentially helps avoid the accidental creation of redundant services or services that implement redundant logic.
- There are two aspect of this, one is the technology which provide discover-ability such as Service Registry or Directory Other is service itself should be as discoverable as possible, regardless of weather a discoverability product exists in surrounding or not.
- 7.Service Composition
- Composability is simply another form of reuse and therefore operations need to be designed in a standardized manner (and with an appropriate level of granularity) to maximize composition opportunities.
- 8.Service statelessness:
- This principle states that services should minimize the amount of state information they manage, as well as the duration for which they remain stateful. In a service-oriented solution, state information usually represents data specific to a current service activity. While a service is processing a message, for example, it is temporarily stateful (Figure 2). If a service is responsible for retaining state for longer periods of time, its ability to remain available to other concurrent consumers will be impeded.
- As with autonomy, statelessness is a preferred condition for services and one that promotes reusability and scalability.
- Two main type of application in any enterprise:
- Business Applications: Core business applications - generally developed inside.
- Infrastructure Applications - These are generally 3rd party applications like outlook, word doc, timesheets..
- Because SOA opens up the possibility of utilizing a packaged unit of functionality (service) in a location-independent way, the potential and push for having an “extended enterprise” are obvious.
- Topographically, services can be either deployed on-premise or accessed from a remote source. Various models exist to categorize remotely accessible services, including
- Software as a Service (SaaS),
- Cloud Computing, Cloudware,
- Platform as a Service (PaaS), and
- Web-oriented architecture (WOA).
- Each of these can serve a somewhat different concern, but the common thread remains that none of them is deployed and managed by the service-consumer organization. Infrastructure availability, resource provisioning, and quality of the service become the service provider’s concerns
- DSB addresses
cross-enterprise service-collaboration scenarios. Organizations that attempt to
implement such scenarios with a traditional Web services composition/enterprise
service bus (ESB) approach are facing tremendous challenges when it comes to
spanning business-process workflows across the enterprise boundaries.
Firewalls, network-deployment DMZ zones, and software-product boundaries are
some of the many obstacles that enterprise architects must overcome.
General:
