Hello,
I have been working on full WCF (not limited to moonlight coverage)
these days and I cooked up an updated status text to replace existing
one on our wiki [*1]. Actually the obsoleted page will be temporarily
just moved as "old" page. It is obsoleted, and I don't find spending
time on listing up "not supported" things worthy of doing it (I'd
rather spend time on writing code instead).
If anyone has specific questions about status, or request for other
kinds of status information, please let me know.
WCF hacking fellows are also welcome ;-)
[*1] http://mono-project.com/WCF
Atsushi Eno
* WCF/WCS tasks and status (as of May 2009)
Here I first describe the plans, then status.
* Development Plans
WCF is huge, so I have split them into a couple of "profiles" that
we will support. The development plan is based on the profiles and
only a few of them are actually to go.
** Profiles
- Core profile: Silverlight runtime compatibility level.
deliverables: get WCF-dependent silverlight apps working.
status: done
- Basic profile: Core stack + Silverlight SDK equivalents +
corresponding server side stuff + net.tcp and P2P channels.
deliverables: get Duplex client ChatApplication working.
http://msdn.microsoft.com/en-us/library/bb690929.aspx
- Simple extension profile: 3.0 IdentityModel and 3.5 REST
stack. Actually 3.5 stack is already done in major parts.
deliverables: get devdefined OAuth working.
http://code.google.com/p/devdefined-tools/wiki/OAuth
- Minimum WS-Security stack: System.ServiceModel.Security*
stack as long as the simplest cardspace client needs.
deliverables: get one infocard client example working.
- Extended WS-Security stack: up to complete the full
security stack.
deliverables: (TBD)
- Full 3.0 stack: every 3.0 things except unsupported stack.
deliverables: (TBD)
** Not supported stack
- ComIntegration.
- Data stack: support for ADO.NET Data Services.
We don't have entities, which is the primary target
for this area.
- WorkflowServices: we don't have WF anyways.
** Decoration factors
They do not consist of the profiles above, but might be implemented
independently and randomly.
- configuration support: Silverlight does not support
configuration stack. Neither do I love them.
- Service description (WSDL) support. It matters only
when you expose WSDL at run-time, or import WSDL
into contract. Basic contract generation works through
our svcutil, but not further to support complex ones.
- MSMQ stack: Msmq bindings and MsmqIntegration.
- Federation (I'm not sure what it is supposed to do.)
- many other additional BindingElements such as transaction,
reliability.
** API completion targets
Since it looks easier to fill everything in some assemblies except
for System.ServiceModel, I might want to work on filling API
including almost-in-no-use stuff, so that I can ignore some
assemblies in later stages.
For example I am mostly done with System.Xml namespace in
System.Runtime.Serialization.dll. MTOM support is done just for that.
* Status
** Profiles
Silverlight runtime compatibility stack should be feature complete.
Now I am on implementing "Basic" profile things, especially on
TCP transport and Duplex client support.
** everything but System.ServiceModel.dll
*** System.Xml (S.R.Serialization.dll)
Only a few minor things are left unimplemented.
[contribute] Fill the gap to completion.
*** System.Runtime.Serialization (S.R.Serialization.dll)
DataContractSerializer should work (as it is working in Moonlight),
including array and reference support in 3.5 SP1.
NetDataContractSerializer is not implemented.
[contribute] Implement NetDataContractSerializer.
*** System.Runtime.Serialization.Configuration (S.R.Serialization.dll)
Not implemented.
[contribute] The entire stack (should not be hard).
*** System.IdentityModel.Claims (S.IdentityModel.dll)
Should be mostly implemented, except for Windows-only stuff.
[contribute] Fill the gap to completion.
*** System.IdentityModel.Policy (S.IdentityModel.dll)
Implemented but not known to work.
[contribute] write tests and/or find its usage somewhere.
*** System.IdentityModel.Selectors (S.IdentityModel.dll)
Some token authenticators and providers are implemented.
[contribute] implement remaining stuff.
*** System.IdentityModel.Tokens (S.IdentityModel.dll)
The basic framework should be usable for SecurityBindingElement.
SAML implementation is incomplete, and not implemented as
SecurityToken.
[contribute] same as Selectors. Complete SAML support.
*** System.IdentityModel.Selectors (S.IM.Selectors.dll)
On Win32 it should work. The actual implementation is in
Mono.IdentityModel.Selectors.dll which P/Invokes cardspaceapi.dll.
On Linux and/or Mac, the entire UI must be implemented.
[contribute] write card manager UI (in any form; Gtk#, WinForms or
even CUI). It could be done as part of mono-tools (especially if
it depends on Gtk#) or mcs/tools.
*** System.ServiceModel.Web.dll
Not fully implemented, but WebHttpBinding should work.
New AtomPub support in 3.5 SP1 is also implemented.
[contribute] Complete UriTemplate. Implement OutgoingWebRequestContext.
Support WebContentFormat.Raw. Support ArraySegment.
Support WebScriptEnablingBehavior.
*** System.Data.Services.dll
Not implemented. We don't have Entity Framework. (Theoretically it
is still possible to implement it for other queryable data though.)
[contribute] everything.
** System.ServiceModel.dll
*** Binding Elements
Bindings should be regarded as explained here too, as they are
almost mere collection of binding elements.
**** Message encodings
All message encoding binding elements are implemented, except for
some details. For example, ArraySegment supportis not implemented.
Message buffering is not always considered.
**** Transports
HTTP is implemented. TCP is on the way. For others, it depends.
**** Everything else
are explained at corresponding sections (for example, no point of
explaining TransactionFlowBoindingElement beyond Transaction section).
*** Communication objects
Every basic parts should work: CommunicationObject, ChannelBase,
ChannelManagerBase, ChannelFactoryBase, ChannelListenerBase, etc.
Basic functionality in client factory and service host should
work: ClientBase<T>, ChannelFactory<T> and ClientRuntime, and
ServiceHost(Base), ChannelDispatcher(Base) and DispatchRuntime.
Client side would work better since they are actually
used heavily in Moonlight.
Session support is *not* done in any types of the channels yet.
(In Moonlight compatibility layer, there is no binding element
that supports sessions.)
*** Security stack
Incomplete work. WS-Trust authenticator hash was not clear at
the development a few years ago (This might have changed by
Windows Open Protocols).
*** Not supported
- transactions
- reliable messaging
- federation
- privacy notice (WSDL support is incomplete anyways)
- SSL stream.
** Old Milestones and status (for reference)
(We originally started the development plans along with Infocard
achievement. Since the WCF usage situation has changed, we have
sort of redrawn the entire strategy and it is somewhat obsoleted.
Here I update the status along with the old plans anyways, but
it does not mean we are going along with it anymore.)
1. Basic connection establishment
- Basic ServiceHost side logic : done
- Connect via HTTP and process messages : done
- Support message from/to service method invocation : done
- Support client native method invocation proxy : done
- Optionally configuration support : done
From here, 2, 3 and 4 are not necessary to be sequential
2. Web Service support
- System.Runtime.Serialization xsd support : won't work, outdated
- WSDL support : WsdlImporter and WsdlExporter won't work, outdated
- svcutil.exe : it exists, but the above premise are not filled.
- .svc IHttpHandler : it exists, hence the request will be processed.
It won't work for WSDLs as the same as above.
3. WS-Security and all relevant stuff
+ MessageProperty support (HttpRequest-, Security- etc): partly
o MessageBuffer implementation for its internal use: done
o xmlenc/xmldsig support for WSS: done, based on Sys.Security.dll
o basic X509SecurityToken based communication: done
o basic WSSecurityTokenSerializer support: done
o support asymmetric binding elements: done
o support symmetric binding elements: done
o Timestamp support: done
+ token authentication: only at recipient (though it would be
enough so far)
o handle supporting tokens: done
- retrieve correct tokens and use correct parameters
- DetectReplays support
o key derivation support: done
- WS-SecureConversation support: it includes
- SecureConversationSecurityTokenParameters
+ SecurityContextSecurityToken : largely done.
- SslSecurityTokenParameters: it includes
+ connection-based token retrieval: largely done
+ SSL token processing : largely done
- Binary XmlDictionary reader/writer for dnse:Cookie
- SAML implementation
- IssuedSecurityTokenProvider : it includes
- analysis on its behavior: largely done
- WS-Trust request processing (especially at service side)
- ServiceAuthorizationManager implementation
4. Infocard implementation
- infocard selector/manager GUI
- System.IdentityModel.Selectors.dll to invoke infocard.exe.
- sts.exe
5. everything else
- overall messaging and communications
- XmlSerializer in Messages : supposed to work
- Duplex channels and client base. : ongoing
- Sessions
- behaviors : should be applicable; for each class it depends
- Extensions : not likely to work
- Service controllers:
- some of Filter and FilterTables
- InstanceContext : not working parts (if any) should be fixed
- Transports:
- NetTcpBinding : ongoing
- NetPeerTcpBinding : ongoing
- NetNamedPipeBinding
- WSDLs:
- Policy[Import|Export]Extension implementation
- MetadataResolver
- Misc:
- P2P : no service implementation yet
- Transactions
- SAML support : partly implemented, not verified
6. Not on the list
- Msmq support
- ComContract support
_______________________________________________
Mono-list maillist - [email protected]
http://lists.ximian.com/mailman/listinfo/mono-list
