Service orientation principles

[Former Member]

Hi

Can anyone please elaborate on the following principles of SOA:

Services are autonomous.

SOA is standards based

Services share schema and contract and not class

Thank you

[gajendra_bhakuni · Accepted solution]

Hi Abhay,

Services are autonomous:

This implies that services are independent. The implementation of one service does not depends upon implementation of other services (because as per the third principle 'Services share schema and contract and not class', service implementation can change any time.

SOA is standard based:

Service-oriented architecture can be implemented with any service-enabling technology like CORBA, DCOM or EJB.

The target of Web Service standards like WSDL, XML, SOAP and UDDI is to enable services from different systems to communicate with each other.

Definition of web service is published as WSDL document in UDDI. When calling web services, XML messages are exchanged via SOAP typically using

HTTP for transportation.

Services share schema and contract and not class:

This implies to the loose coupling between service and its users (consumers).

Consumers should communicate to the service with message.

The service consumer goes to the UDDI and searches the desired service in the form of WSDL document. The WSDL document defines the web service - protocol bindings and message formats required to interact with the selected Web Services as well as the additional metadata needed for service consumption.

This is independent of the implementation of the web service. Hence by sharing schema and not implementation classes, the Service implementation can be changed over time without impacting its clients.

Hope this helps.

Regards,

Gajendra.

[Former Member]

hi abhay,

it's intersting that you state these principles with this wording. I work and read a lot with/about SOA and haven't come across this phrasing.

ad 1) probably better known as the principle of loose coupling; latter means, that if you consume a service you don't have to expect some environment set or some other conditions to be fulfilled first; you just enter the input parameters and get an output accordingly; or said differently, from the perspective of a certain service you don't have to call any other service before or after(of course you have to keep a certain order from the perspective of a proper process);

if you know ABAP, there's one prominent example violating this loose coupling principle: BAPIs. AFAIK every BAPI call requires a follow-up call to a commit BAPI.

ad 2) technically this is just a subordinate requirement for SOA; it is to be standards based to make it sucesful/useful though. only if the description of services as well as the consumation mechanism is based on standards, some automatisms like central service publication, detection, data type specification can be put in place effectively

ad 3) services do not <b>share</b> anything. They expose their functionality as standardized schemas (e.g. WSDL). Schemas contain simple and complex data types, operations and 'administrational data'(service endpoint, transport type, ..). Implementation specific functionality is not exposed.

May I ask where you took your phrasings from?

regards,

anton