Det finnes ingen problemer -bare løsninger

Service Orientert Arkitektur (SOA)

En serviceorientert arkitektur (SOA) er en stil med programvareutforming hvor tjenester leveres til de andre komponentene av applikasjonen, gjennom en kommunikasjonsprotokoll over et nettverk. De grunnleggende prinsippene for serviceorientert arkitektur er uavhengige av leverandører, produkter og teknologier. En tjeneste er en diskret funksjonalitet som kan nås eksternt og handles på og oppdateres uavhengig, for eksempel å hente et kredittkortoppsett online. En tjeneste har fire egenskaper i henhold til en av mange definisjoner av SOA: Den representerer logisk en forretningsaktivitet med et bestemt utfall. Det er selvstendig. Det er en svart boks for sine forbrukere. Det kan bestå av andre underliggende tjenester. Ulike tjenester kan brukes sammen for å gi funksjonaliteten til et stort program. Så langt kan definisjonen være en definisjon av modulær programmering på 1970-tallet. Serviceorientert arkitektur er mindre om hvordan man modulerer en applikasjon, og mer om hvordan man komponerer et program ved å integrere distribuerte, separat vedlikeholdte og distribuerte programvarekomponenter. Den aktiveres av teknologier og standarder som gjør det enklere for komponentene å kommunisere og samarbeide over et nettverk, spesielt et IP-nettverk.

Wikipedia

Lær Mer

I Felagi bruker vi SOA-prinsipper for all vår programvareutvikling!

Siden vår informasjon her er hentet direkte fra Wikipedia.org unlater vi å ovesette dette til norsk.

SOA Principles

There are no industry standards relating to the exact composition of a service-oriented architecture, although many industry sources have published their own principles. Some of these include the following:

Services adhere to a standard communications agreements, as defined collectively by one or more service-description documents within a given set of services.

The relationship between services is minimized to the level that they are only aware of their existence.

Services can be called from anywhere within the network that it is located no matter where it is present.

Services should be designed to be long lived. Where possible services should avoid forcing consumers to change if they do not require new features, if you call a service today you should be able to call the same service tomorrow.

The services act as black boxes, that is their inner logic is hidden from the consumers.

Services are independent and control the functionality they encapsulate, from a Design-time and a run-time perspective.

Services are stateless, that is either return the requested value or give an exception hence minimizing resource use.

A principle to ensure services have an adequate size and scope. The functionality provided by the service to the user must be relevant.

Services are decomposed or consolidated (normalized) to minimize redundancy. In some, this may not be done, These are the cases where performance optimization, access, and aggregation are required.

Services can be used to compose other services.

Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.

Logic is divided into various services, to promote reuse of code.

Many services which were not initially planned under SOA, may get encapsulated or become a part of SOA.

Learn More