The best and most optimized way to return a filestream from a .NET WCF SOAP service

Here is the basic difference between the two -

1 File Format/Extension :

i) ASP.net service - '.asmx'

ii) WCF service - '.svc'

2 Hosting :

i) ASP.net service - Can be hosted in IIS also can be hosted in a Windows Service.

ii) WCF service - Very flexible, can be hosted in IIS, Windows Activation Services(WAS), Managed Windows Services and It also supports Self-Hosting.

3 Transport Protocols/Binding :

i) ASP.net service - It supports HTTP & TCP protocols along with custom binding.

ii) WCF service - supports HTTP, WS-HTTP, TCP, Custom, Named Pipes, MSMQ & P2P(Point to Point) etc.

4 Data Transformation :

i) ASP.net service - XML serializer for Data Transformation.

ii) WCF service - DataContractSerializer for Data Transformation.

5 Serialization NameSpace :

i) ASP.net service - System.XML.Serialization

ii) WCF service - System.RunTime.Serialization

6 Supported Operations :

i) ASP.net service - only One-Way and Request-Response type.

ii) WCF service - Includes One-Way, Request-Response and Duplex.

7 Encoding :

i) ASP.net service - It uses following encoding mechanisms - XML1.0, MTOM (Message Transmission Optimization Mechanism), DIME (Direct Internet Message Encapsulation)

ii) WCF service - It uses following encoding mechanisms - XML1.0, MTOM, Binary

Read more differences - http://www.csharptutorial.in/2012/01/cnet-difference-between-web-service-and.html

Does it make sense for each module to have their own version of an inventory item that is designed to suit the needs of that module? In that case, the Financial module would have to perform its own lookup of the inventory items when handling the GoodsReceivedEvent. Where do I draw the line between modularity and the need to share information?

You will always have to accept trade-offs. That's all there's to say to your questions really. It has been a good practice to keep the entities in a separate assembly, so many applications keep them in a shared library. But that means that there're no (physical) business-logical boundries. Performing your own lookups means a lot of redundant code which I'd only implement if you have special requirements in both the modules. Of course, looking at it from an architectural point of view, your Financial Module and your Inventory Module have to share a dependency anyway. The Financial Module is most likely dependent on the Inventory Module. If requirements permit you to let one module depend on another module, then I'd say it's ok to encapsulate the entities within the modules they belong to the most. You'll need to find a good balance between physical distinction (shared dependencies) and maintenance. Too many shared dependencies could cause a maintenance nightmare of versions. Also, with an ORM there'll be troubles if you want to map new relations to existing entities or extend them from modules which depend on the module containing the entity.

If you don't use ORM then keep in mind all your modules probably share the same database anyway, as that's often the case. You could use that as a common ground.

You could also keep the data plain (in terms of CSV/resultsets e.g.) and use a central messaging service to notify modules that registered to it about new data with along with some meta information. That means no real dependencies, but sacrifices type safty and contracts and there can be troubles with malformed data. I guess that's how many big ERP systems do it.

So in short, you'll have to decide which kind of interface you want. More modularity leads to less contracts and vice versa.

Id'probably use a shared library for my data objects and a central messaging service with a publish subscibe pattern, that seems the best solution to me.