• SOA services are black boxes. In SOA services hide there inner complexities. They only interact using messages and send services depending on those messages. By visualizing services as black boxes services become more loosely coupled.
• SOA service should be self defined: - SOA services should be able to define themselves.
• SOA Services are maintained in a listing: - SOA services are maintained in a central repository. Applications can search the services in the central repository and use them accordingly.
• SOA components can be orchestrated and linked to achieve a particular functionality. SOA services can be used/orchestrated in a plug and play manner. For instance figure ‘Orchestration’ shows two services ‘Security service’ and ‘Order processing service’. You can achieve two types of orchestrations from it one you can check the user first and then process order or vice-versa. Yes you guessed right using SOA we can manage work flow between services in a loosely coupled fashion.
-------------------------------------------
Standardized service contract – Services adhere to a communications agreement, as defined collectively by one or more service-description documents.
Service Loose Coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
Service Abstraction – Beyond descriptions in the service contract, services hide logic from the outside world.
Service reusability – Logic is divided into services with the intention of promoting reuse.
Service autonomy – Services have control over the logic they encapsulate.
Service granularity – A design consideration to provide optimal scope and right granular level of the business functionality in a service operation.
Service statelessness - Services minimize resource consumption by deferring the management of state information when necessary
Service discoverability – Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
Service composability – Services are effective composition participants, regardless of the size and complexity of the composition.
Some authors also include the following principles:
Service normalization – Services are decomposed and/or consolidated to a level of normal form to minimize redundancy. In some cases, services are denormalized for specific purposes, such as performance optimization, access, and aggregation.[9]
Service optimization – All else equal, high-quality services are generally preferable to low-quality ones.
Service relevance – Functionality is presented at a granularity recognized by the user as a meaningful service.
Service encapsulation – Many services are consolidated for use under the SOA. Often such services were not planned to be under SOA.
Service location transparency – This refers to the ability of a service consumer to invoke a service regardless of its actual location in the network. This also recognizes the discoverability property (one of the core principle of SOA) and the right of a consumer to access the service. Often, the idea of service virtualization also relates to location transparency. This is where the consumer simply calls a logical service while a suitable SOA-enabling runtime infrastructure component, commonly a service bus, maps this logical service call to a physical service.
-----------------------------------------------------------------------------
The roadmap to SOA involves:
Understanding the industry specific end state for the first iteration
Gather the current state of business process maintenance, applications, integrations, security, master data and governance
Reducing the SOA readiness gap between various entities
The various entities would be in one of the SOA readiness states.
Business process maintenance
Ad-hoc: processes are defined as and when needed
Documented: business steps are documented in disparate documents
Structured: process management tools used albeit disconnected
Services: processes designed as services through standardized process management tool
Integration
Point to point: applications directly interface with required parties
Loosely coupled: some applications use an intermediary that abstracts the interface
Static services: services available but bound to other Static Applications
Dynamic binding: static services bound in a dynamic way through Pub-Sub
Dynamic services: services that can dynamically sense when they are required and respond
appropriately.
Applications
Standalone: applications requiring large interface efforts
Service-wrapped: application(s) wrapped as a service
Exposed APIs: applications have service based API's
Exposed services: this makes the applications reusable
Dynamic discovery: applications can be discovered by other applications
Security
Application level authentication and authorization: every application is accessed in its own silo[which?]
Loose authentication control: some applications are on LDAP
Tight directory-controlled authentication: SSO-enabled across most applications
Centrally controlled identity and access management
Master data
Application-controlled: all applications control their master data
Partial sharing: some applications share master data but not all masterdata
Centralized master-data maintenance: most master data is shared and maintained through some MDM implementation
Reference:
http://www.codeproject.com/Articles/28583/SOA-Interview-questions-Part-1
No comments:
Post a Comment