How to start with mono/WCF development contribution

185 views
Skip to first unread message

yarlenvas

unread,
Jul 9, 2009, 12:52:30 PM7/9/09
to Mono Olive - developing.NET 3.0, 3.5 and later versions
Hello, I am from Colombia (South America).

I am working as .net developer in a variety of .net WCF projects, but
i am interest in make my contribution to the mono/wcf project, can
anyone help me get started? because I can not find information about
how to join to this specific project as developer.

thanks.

Atsushi Eno

unread,
Jul 9, 2009, 10:38:05 PM7/9/09
to mono-...@googlegroups.com
Welcome :) The WCF development is the same as development in other
mono class libraries (they are almost mere class libraries). So
start from http://mono-project.com/Contributing .

I have written the status and milestones a few months ago to
mono-devel-list, and left it as is. I made a quick updates on it.
There is a handful of [contribute] sections in each feature targets.

I (for now the only WCF developer) have been lately struggling
with NetTcp and NetPeer bindings and duplex channels.

Atsushi Eno
wcf-status-200907.txt

Yarlen Mailler

unread,
Jul 10, 2009, 8:20:44 PM7/10/09
to mono-...@googlegroups.com
Thanks for the information, this weekend y will install suse linux in my computer.
Can I do some questions to you later?

2009/7/9 Atsushi Eno <atsus...@veritas-vos-liberabit.com>
* WCF/WCS tasks and status (as of mid-July 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.

       - One-way binding and things that depends on it; reliable messaging
         and composite duplex. channel pool.

       - 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.
       There is Mono.IdentityModel.Selectors.dll that holds implementation
       for win32.

*** 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. HTTPS is not.
       TCP duplex is in general implemented. TCP streaming is not.
       NetPeer is ongoing, but may be delayed.
       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 depends on transports, and since only TCP duplex
       channel is implemented so far, some requirements may not be filled
       at service dispatching side.
       (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
       - composite duplex
       - reliable messaging (depends on one-way binding element)
       - 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




Levi Bard

unread,
Jul 11, 2009, 6:21:04 AM7/11/09
to mono-...@googlegroups.com
> MTOM support is done just for that.

Whoa. Is MTOM really functional? Has that made it into a release?

Atsushi Eno

unread,
Jul 12, 2009, 10:25:38 PM7/12/09
to mono-...@googlegroups.com
Sure, but it'd be always better posted here.

Atsushi Eno

Yarlen Mailler wrote:
> Thanks for the information, this weekend y will install suse linux in my
> computer.
> Can I do some questions to you later?
>
> 2009/7/9 Atsushi Eno <atsus...@veritas-vos-liberabit.com
> <mailto:atsus...@veritas-vos-liberabit.com>>
> - Data stack: support for ADO.NET <http://ADO.NET> Data Services.

Atsushi Eno

unread,
Jul 12, 2009, 10:27:23 PM7/12/09
to mono-...@googlegroups.com
I don't know it is really functional. All what I can say is it
works as long as it is tested. Check MtomBlabla sources in
System.Xml directory in System.Runtime.Serialization assembly.

Atsushi Eno
Reply all
Reply to author
Forward
0 new messages