Granularity and Performance in SOA

Developed from the CSC Subject Matter Expert White paper from David Tullett 5th October 2005 on Web services Best practice.

The aim of this paper is to summarize the key aspects of service granularity and the choice impact on performance.

Definition of web service

[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"> <v:stroke joinstyle="miter"></v:stroke> <v:formulas> <v:f eqn="if lineDrawn pixelLineWidth 0"></v:f> <v:f eqn="sum @0 1 0"></v:f> <v:f eqn="sum 0 0 @1"></v:f> <v:f eqn="prod @2 1 2"></v:f> <v:f eqn="prod @3 21600 pixelWidth"></v:f> <v:f eqn="prod @3 21600 pixelHeight"></v:f> <v:f eqn="sum @0 0 1"></v:f> <v:f eqn="prod @6 1 2"></v:f> <v:f eqn="prod @7 21600 pixelWidth"></v:f> <v:f eqn="sum @8 21600 0"></v:f> <v:f eqn="prod @7 21600 pixelHeight"></v:f> <v:f eqn="sum @10 21600 0"></v:f> </v:formulas> <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"></v:path> <o:lock v:ext="edit" aspectratio="t"></o:lock> </v:shapetype><v:shape id="_x0000_s1026" type="#_x0000_t75" style='position:absolute; margin-left:0;margin-top:6.35pt;width:158pt;height:202pt;z-index:251657728'> <v:imagedata src="file:///C:/Users/MARKSK~1/AppData/Local/Temp/msohtmlclip1/01/clip_image001.jpg" o:title="SOAP Message Structure"></v:imagedata> <w:wrap type="square" side="left"></w:wrap> </v:shape><![endif][if !vml][endif]

The definition of the XML, WSDL and SOAP methods follows a similar taxonomy of header and body syntax. The object orientation enables entity classes and their methods to be defined as operations on those entities.

The definition of a interface class and message e.g. manage Purchase Order can contain a number of operations that will be called using the WSDL definition. The choice and rationalization of the method operations and the content size have a direct affect on the performance of the message.

SOAP Message semantics

The big picture

Context of web services and how they fit the solution overall – the business suitability

The conditions for suitability of the web services message pattern….

Performance and size

Combine < 5 milisec operations e.g. CreatePO compared to Call PO, add PO line etc.

Split .5 milisec operations as these can limit the amount of concurrent usage if the operations take too long to run individually.

Size of message e.g. 1 MB is the current performance size, above this then may affect performance (Needs TBC with scalable strategies and network specialist)

Safe Operations

Read only operations are useful e.g. HTTP GET. These are also cachable.

These can be ran in cache mode.

Indempotency operations – can be re-run without affecting the ultimate state.

e.g. read/write operations. Can run it more than once without harm. E.g. write the name of the account compared to increase an account by £500. Running the latter more than once will affect the end state.

Transactionality and state

Avoid services that require transient state between operations (is this not state management – this is the difference between stateless and stateful message management.)

Affects performance as to have persistence and also affects the failure recovery process.

Hence – every operation should be self contained.

Aim for data change done in one operation. This make recovery easier.

But also avoid putting too much into one operation. E.g. create PO’s as this limits concurrency of linked operations (operations dependent on one state to another). If one PO failed could then have all subsequent Pos rejected.

Message content, structure and size.

Two main types of business process:

[if !supportLists]· [endif]Specific business process – known data and operations.

[if !supportLists]· [endif]Business process subject to change – data may need to be processed differently

XML encapsulates structure and content than enables reuse.

Use XSD to get semantics of XML message.

Security

[if !supportLists]· [endif]Boundary model

[if !supportLists]· [endif]Message and transport systems

[if !supportLists]· [endif]Infrastructure security features

Boundary model (SSO, IAM) versus interwoven through and by the message and systems (Transport SSL/ HTTP; message – XML encryption, digital signatures.

+ Infrastructure security features e.g. J2EE has inbuilt authentication and authorization features JAAS added to Version 1.4 of J2SE.

Fault Handling

SOAP faults – used for fatal / technical faults outside the business process context.

Error specific XML elements within the payload should be used to communicate the faults that have occurred during execution of the web service implementation – and relate to the business process.

#WebServices #SOA #SOAPerformance #Granularity