SCA Capabilities

mrowley writes (as I understand him) that Security characteristics (authentication, authorization, confidentiality) are one of SCA's responsibilities.

That diverges from my view, where security is something you *compose* by developing/composing SCA components, as distinct from something that SCA *provides*. The latter requires BEA to get it right, whereas in my view, there is no "right" in a broad enterprise like DOD that lacks a consensus (a standard) for what "security" really means. You're stuck with building adapters (like Objective Gateway) as distinct from letting BEA do it for you.

This goes back to why I might seem obsessed with escaping whatever requirements there might be for WSDL-based type-checked components in favor of untyped (by WSDL) components, which really means the component does type checking on whatever comes its way.

This is the same old static- vs. dynamic argument from the Ada vs. Smalltalk wars. That ultimately boiled down to...the real world demands both. In our case, you really need WSDL-specified typing of SOA services as a whole (because the standard says so). But not for the JBI components you compose those services from. They must be defined as xsd:any so that they can be stored away and resassembled later to accept whatever SOA service/SOAP message you're doing that day.

Just as in my simple auditing example, which really applies to every security component (authentication, authorization, confidentiality, integrity, nonreputiation, ....), and arguably every JBI component that aspires to broad reuse.

Especially including BCs...I just hope the Sun soapBC gotchas haven't spread to the others.