Axis implementation summary

Here is a summary of Axis' current implementation status with respect to the SOAP 1.2 implementation list [1].  It was a bit tricky to deal with some of these, since Axis is designed to be extremely flexible and extensible.  Therefore, a bunch of these features are "implicitly" supported in that nothing in the code prevents a user from building a component which implements them.  However, no direct toolkit support is provided for these things, which are marked "implicit" below.  We're in the midst of implementation, so this list is subject to rapid change.

Comment : In general, many of these items are confusing and extremely difficult to interpret.  If we want an accurate accounting of implementations, we should strive to make it easy to understand what is being asked...

[1] http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html

------------

61 - don't understand this

62 - media type

Plan

1 - Support transmit,receive,process,relay messages

Yes (no explicit relay/intermediary support, but possible for users)

2 - support one or more SOAP roles

Yes

3 - routing over multiple hops

Implicitly (can do if the user writes it)

4 - Supports targeted headers

Yes

5 - Special role (next, etc)

Partially - don't handle all roles yet.

6 - MustUnderstand

Yes

63 - Nodes may use any envelope info when processing

Yes - entire message is available to all processing components

64 - Headers can change processing order

Implicit - no direct support, but easy to do with custom Handlers.

65 - Headers may be processed before, during, or after body

Implicit - handlers may be invoked arbitrarily

66 - Header/MEP may cause forwarding

Implicit

7 - Intermediaries

Implicit

67 - Intermediaries doing stuff not explicitly triggered by headers

Implicit

8 - Multiple envelope versions

Yes

9 - Validation of envelope infoset

Yes

10 - Support character data?

Don't quite understand this one...

11 - Whitespace allowed

Yes

68 - May ignore whitespace when forwarding

Depends on handler writers (yes)

12 - Envelope support

Yes

13 - EncodingStyle support

Yes

14 - Scoping of encodingStyle

Yes / Plan

15 - Header support

Yes

16 - Header block support

Yes

17 - Role and MustUnderstand support

Yes, but mustunderstand only explicitly supported on 1st level header blocks

18 - Support role

Yes (isn't this redundant with 17?)

69 - May discard role info for ultimateReceiver

Implicit (components may edit message)

19 - Support mustUnderstand

Yes (isn't this redundant with 17?)

70 - true/1 false/0, default is false

Plan

20 - Supports SOAP:Body

Yes

21 - Supports Body children

Yes

22 - Representa app-defined data, incl. non-XML

Yes

23 - Multiple serialized graph-based representations

?? What's this?

24 - Supports encoding based on edge-labelled graph

Yes

25 - Allows inline serialization of multirefs

Plan

26 - Globally and locally scoped namespaces

Yes 

27 - Encoding/decoding of simple and compound types

Yes

28 - Supports itemType

Plan

29 - Multiple encoding schemes

Yes

31 - Req-resp MEP

Yes

32 - SOAP response MEP

Plan

33 - Web Method Feature

Plan 

34 - Media type

Plan (isn't this redundant with 62?)

35 - Support MEPs

Partial (isn't this redundant with 31/32?)

36 - Web Method Feature

Plan (redundant with 33?)

37 - Streaming + deadlock prevention

Where is this in the spec?

38 - State description of req node and status codes

Partial (doesn't support all status codes)

39 - State description of resp node and status codes

Partial (doesn't support all status codes)

40 - Binding uses XML 1.0 serialization

Yes

41 - Supports SOAP:Fault

Plan

42 - Supports Code element

Plan
 
43 - Supports Reason element

Plan

44 - Supports Node element

Plan

45 - Supports Role element

Plan

46 - Supports Detail element

Yes

47 - Supports Upgrade header

Plan

48 - Supports Misunderstood header

Yes

49 - Version interaction faults

Plan

50 - Supports faults (?)

Yes

51 - Supports RPC over multiple bindings

Don't understand this?

52 - Supports RPCs with other MEPs

What?  How can you mandate/test this?

53 - Support struct or array RPC access

Partial - plan

54 - Permits missing parameters

Yes

55 - Permits RPC response as struct or array

Yes

56 - RPC must not have both response and fault

Yes

57 - Supports all encoding styles

Yes (all 1 of them?)

58 - Single child of body is RPC invocation

Plan (do external multirefs right now)

59 - Support header-based meta info about RPC

Yes (implicit)

60 - RPC Fault handling mechanism

Yes

-------------

Thanks,
--Glen

Received on Wednesday, 24 July 2002 14:41:09 UTC