Am I wrong about WCF usage?

Question

I have been experimenting with WCF, on and off, for some time and it 'seems' that 99% of the design effort is around B2B communication with 1% on a self-contained applications.

I say this because the assumption with WCF interface contracts is that the client-side knows nothing about the business model; thus, the operation contract requires explicit declaration of types.

This, from my view, is horrible for uses where a developer is designing a self-contained application.

I have hundreds to thousands of classes where 90%+ only need a two interfaces between client and server when generics are applied. Declaring 500+ classes as known types for a data contract is rediculous. Now - thank goodness - there is the NetDataContract which alleviates this problem nicely.

Why is the NetDataContract not EMPHASIZED for these scenarios? It actually seems that someone - somewhere is purposefully making its use as difficult as possible.

Again, I believe, there are two main categories for interface communications:

1. B2B (Business-to-business)
2. Self-Contained Application (Client to Server)

Of course, these scenarios can and are likely to be mixed, but how many developers have uses that are not B2B? A good B2B example is an application that uses a Credit Reporting service. No way could a company have access to individual and company payment histories, thus, use a web service to connect and retrieve credit reporting data. Okay, this is where all the effort seems to be spent: B2B communications.

Now, what about a client form (Win or Web) connecting to a hosted service for a self-contained application?

99% of the examples are defining services such that a new WCF developer would be led to believe that every class needs to be declared as a separate service. (I.e Customer Service, Invoice Service, Vendor Service, etc, etc)

Then a more experienced developer might create more generic contracts, but may still be led to believe they should declare every class for the interface EXPLICITLY as known types.

This just kills OOP!

Again, with NetDataContract, a few interfaces using .Net 2.0 generics can handle the vast bulk of communication and the types DO NOT have to be declared - in advance - explicitly. A new class implmenting the interface properly will simply work across the channel - using NetDataContract.

This should be the DEFAULT use for scenario 2 (Self-Contained Applications), should it not? Am I all wet?

Is nobody else actually using WCF for self-contained applications? What is up here?

Thanks,

Trevor

 

Answer 1

I've just started working with WCF - I'm developing a distributed client/server application where I'm responsible for both the client and the server - and I'm finding the same thing; a lot of the WCF introductory material seems to be based on

1. Build a service/server
2. Generate your proxy.
3. Write your client code using your auto-generated proxy.

There's a post here about some problems I'm having trying to create a "self-proxying" service - ie. something where you create one class, and don't have to then explicitly create a client proxy for your service - but this is the first I've heard about NetDataContract (and given there's only 8 Google hits for it right now, sounds like I'm not the only one)

But - for what it's worth - you're not the only one trying to use WCF within a self-contained client/server app - and you're not the only one finding it frustrating :)

 

Dylan

 

 

 

Answer 2

Just to be clear, when I refer to known type requirements, I don't refer to using a single declaration of type Object in the interface and then expect to pass any object.

I am refering to passing objects that do implement a specific interface and being able to pass any object of let's say "IMyCustomInterface' across the channel. The NetDataContract attribute 'may' be able to allow any object, but I wasn't referring to that.

If I define IPerson in an interface, then I should be able to pass Customer, Client, Contact or any other class that implements IPerson so long as the classes are serializable. Of course, the client and server needs to have a reference to the type that was passed to serialize/deserialize properly. This is always possible with NetDataContract, generics, and the client having a copy of the business model domain as well as the server.

For example

public interface IMyContract<T> where T: IPerson {
    void Delete(T somePerson)
}

or

public interface IMyContract {
    void Delete(IPerson somePerson)
}

Both of these work with NetDataContract

Trevor

Answer 3

I have to admit, I expected someone to say generic interfaces won't work with WCF!

This is a really, really big deal - in my opinion. There are numerous remoting users who are being led to believe that WCF is the latest, greatest and that they should "upgrade" - ASAP. However, WCF does not address the OO programming model at all because of WSDL constraints, and from my view, there are 40-50 to 1 of developers who are using generics in remoting interfaces versus a need for B2B interfaces and WCF just falls flat on its face (according to publicly accepted usage) with gerneric approaches. Having .Net 3.0 features directly conflict with .Net 2.0 additions is a serious problem.

Please consider: there is a very large group of developers that have intra-application communication needs where it makes perfect sense to have a .dll library on the client and WSDL should not even be involved because auto-generated client proxies are completely unnecessary.

Is it that hard to create a NetGenericAttribute (or some equivelant solution) where the meta-data required to identify the namspace of a .dll can be used to supply what is necessary for generic interfaces to work? It really is as simple as: here I am  - here is where you get the info serialize/deserialize me.

I completely understand the WSDL position for any combination of B2B or B2C scenarios, but most developers I know have a larger need for WCF that's closer to remoting than they have for all that is involved with the much greater separation between client and server in regards to B2B scenarios. Belive me, I very much love just how well WCF works for B2B, but it is severly lacking in a significant area: generics.

Essentially, why can't some attribute (or another solution) identify a namespace location for known types pre-provided in a library and which would allow for generic interfaces to work seamlessly and effieciently. It is seems just plain wrong for an intra-application communication channel to define hundreds to thousands of interfaces for every concrete type when a few generic interfaces should not only suffice, but be the desired solution. In this scenario, WCF is needed for nothing other than having a client gain access from a remote location as though it were "on-site".

 

Am I alone here?  Is it really that hard to achieve? Has anyone else been developing "work-arounds" to address this?

 

Thanks,

Trevor

 

 

 

Answer 4

Trevor,

The puporse of WCF is to enable developers to create distributed systems. Remoting is not going anywere and is still the preffered method for intra process and extra app domain communication.

Thank you

Answer 5

That is not an aswer, is it?

What is your idea of 'Distributed"?

Let's say I have two scenarios:

**
SCENARIO 1:

I represent one of the three companies providing Credit Reports as a service: TransUnion, Experian, or Equifax. Now let's say I want to consider WCF as a means to implement my service.

I am given two primary scenarios:

A) The client of the service is a small company with limited resoources and expects us to create and provide the client application to access the service: the client develops nothing.

B) The client desires to use credit reporting information within their application such as a mortgage company with a custom application for mortgage services. The application needs to have custom logic to parse and use the credit report information within their custom application. Thus, they need access to a service which would accomodate this.

SCENARIO 2:

I am the developer of the software for use by mortgage lenders as I described above and I intend to include access to the Credit Reporting services as well as have the application make smart decisions based on properties/results of individual credit reports. The application will have numerous users in many locations communicating with a centrally hosted service containing the business logic and manages access to several databases.

**

Which scenario would you consider a distributed system?

If your answer is scenario 1 only, then I will restate that far more developers align with something closer to scenario 2, but if all WCF will support (directly) is scenario 1 because intra-appdomain is all it supports or all its designed for, then hmmm?

If you consider scenario 2 to be distributed (which I do), then all that I mentioned in my previous post applies and I consider the answer to be more than lacking because considering distributed syatems to be intra-appdomain is a rediculous definition for distributed - its one category of distribution.

Let's explore #2:

I would have thousands of classes to handle my application, most of the classes define business objects that have different properties, but most employ the exact same actions: such as Save, Delete, Fetch, etc. The client screen I design needs to display the properties, allow a user to change them, and then attempt an action like "Save".

The client screens need to serialize the properties, send them to the host service where business logic will perform tasks such as enforce security (who can do what), test and apply business logic, apply any changes to a database to persist the data, and respond to the client.

This is "distributed" from my view: the client application is installed on numerous PCs, in many locations (btw - Internet Explorer is a distributed client application and I 'could ' use it to access a hosted web service client), or I may need a better UI and choose to design a Winform client application.

The vast majority of communication for most distributed applications involves a communication channel between the client and host service. With WCF, I am required to design a service for every concrete class when all I really should require is an interface defining the actions and tell the proxy which type I am sending.

Your comments really do elude me. Lets say I designed my application with all these interfaces to communicate between client (Web Service and/or Winforms) and the hosted service mananging the business logic. You say this is NOT distributed services  because its not inter-appdomain! I am very suspect that there is a serious case of "groupthink" going inside with the WCF team. Not only would I disagree on the definition distributed systems, I would suggest that you are there to design something competitive and maximize its market potential and the groupthink is chopping-off market share

So, I must say that what you are telling me - and the world - is don't use WCF for anything other than creating services where you have no intent on creating the client or consumer side of the service because we have spent all of our effort on developing tools for the client side of a service to be autogenerated. Never mind that the client will have to be redesigned, rebuilt, and redistributed anyway if any changes would effect client side UI elements and/or client side logic - but hey - it auto-generates proxies from WSDL!

Seriously, WCF offers Sessions management, Concurrency Management, Protocal Configuration and Management, etc, etc - very complex and cool stuff. But what does it mean to a developer if it only can be used for simple services and only for inter-appdomain scenarios? What a waste; especially, when this decision cuts off the majority of the market.

WCF (.Net 3.0) sits on top of .NET 2.0 and does not support the most critical .Net 2.0 enhancement: generics. In fact, it has gone in the opposite direction!

I am absolutely floored when I am told that I should use remoting for intra-application scenarios because WCF is desgned for that.

Someone with business sense needs to understand that the market for WCF would geometrically greater if it supported open generics in interfaces and that remoting would be dead if it did.

 Even more ironic is your point that nobody should need or use WCF except for inter-application scenarios, yet it fails here too - for the same reason. When I speak to developers who are designing services that would "fit-the-bill" you describe (inter-application scenarios), we don't want to build hundreds of interfaces to pass data between us. The same problem exists: a few actions need to be applied to a multitide of objects with differing properties. WCF requiring an interface per concrete object is rediculously poor judgement - in my opinion. Now it is not only limited to inter-appdomain, it also limited to simple services/ designs where te transfer of many different objects is required.

I think its rediculously sad to  have created all these great features and then expressly limit piece-by-piece, those who can use them: I really am shocked!

Okay - I'll use Remoting and since I am required to use remoting for intra-app scenarios, I'll use it for inter-app as well. Who wouldn't? I am not going to design Service Contracts and DataContaracts and learn the huge amount of info related to WCF when you are telling me I have to use remoting anyway.

Holy smokes!

I hope that someone, somewhere breaks this "groupthink" and sets WCF on a better course - quickly!

Sorry, If I pulled no punches, but I believe every word I wrote. If I worked worked on the WCF team, I would worry about my future employment. Look at this forum as an example. there are only a few posts each day which is very significant indicator for how many developers really are moving towards WCF usage: not many. The demand should be so great that a forum should be needed for many sub-elements within WCF and the messages per day should be massive.  I understand why now. Here I am trying to use it, trying to get help, taking the time to express my understanding, and you are loosing me. By the last post: lost me entirely! I am persistent and dedicated and do not give up easily. I really love all the WCF features. If you are loosing me, you are loosing a great number of developers.

It is so simple to suport open generics: create a dictionary of type names and the namesapce to locate the type. The service sends dictionary definition along with the serialized data. The proxy checks its side of the communication and looks for the type defined, it is missing, an exception is thrown, if not, then deserialize based on the now found known type.

IT'S EASY! OMG! Do this and remoting is dead and the market for WCF expands geometrically!

Trevor

 

 

Answer 6

Hi Trevor

We took the plunge to Web Service/ SOA bout 4 yeasr ago when i was a big sceptic  ( I haveiled from remoting /OO )  , i am now a convert.

> Why is the NetDataContract not EMPHASIZED for these scenarios? It actually seems that someone - somewhere is purposefully making its use as difficult as possible.

It is good that it is . You will regret marking your existing classes as Data Contract  ( I did by serializing classes with asmx servcies) . You realy need to redesign the communication and start sending messages with as much data as possible and hence create custom Message Contracts ( They can be data contracts but represent a message not OO ) .  Once you do this you can refactor and evolve your OO with no regard for the clients as you merely change the way the messages are populated.

> Again, I believe, there are two main categories for interface communications:

>1. B2B (Business-to-business)
>2. Self-Contained Application (Client to Server)

You forgot the whole enterprise services model .

3. Shared business logic components.

This is where WCF has evolved from . There were many flaws with the remote OO model we do not have enough experience yet to say if SOA is better but it was deisgned specifically to overcome this.

> This just kills OOP!

 Partially ... . SOA is much close to the older programming models ( have a read of Richard Turners old Blogs) . Note there is nothing to stop you having OO within your client and service components but they are different.

The thing with SOA is  the Business Logic is contained within a shared service - you do not send the logic to each client.   Clients use service to perform actions and get data ( not the Service is data not objects) , this makes your clients thinner.

Remember if you are using OO the client now expresses things from its point of view constructing its object from the Data of the services. This allows superior ( less generic ) but smaller OO  models.  Reuse and shared code is provided by the servcie.

 

Regards,

 

Ben

 

Answer 7

>Please consider: there is a very large group of developers that have intra-application communication needs where it makes perfect sense to have a .dll library on the client and WSDL should not even be involved because auto-generated client proxies are completely unnecessary.

And the versioning and deployment issues of these DLL's was a nighmare for all lot of scenarios, handling new interfaces etc . If you do not need to send the DLL you have decoupled the application this is a good thing even in OOP . 

>Is it that hard to create a NetGenericAttribute (or some equivelant solution) where the meta-data required to identify the namspace of a .dll can be used to supply what is > necessary for generic interfaces to work? It really is as simple as: here I am  - here is where you get the info serialize/deserialize me.

The time to add a custom message layer is minor and it will pay off a thousand fold . Your service logic can change and be refactored without worying about the clients. I have done SOA projects both ways XMLSerializer BL ( with huge inheritance issues) and message contracts . I will not go back to serializing business objects.

>I completely understand the WSDL position for any combination of B2B or B2C scenarios, but most developers I know have a larger need for WCF that's closer to >remoting than they have for all that is involved with the much greater separation between client and server in regards to B2B scenarios. Belive me, I very much love just > > how well WCF works for B2B, but it is severly lacking in a significant area: generics.

There is nothing stopping you have generics in your app it is just dont send your objects as messages . Note .NET is a bit behind here we had to go through the whiole J2EE and Java beans thing first.

>Essentially, why can't some attribute (or another solution) identify a namespace location for known types pre-provided in a library and which would allow for generic >interfaces to work seamlessly and effieciently. 

 

The reason is simple then it would be remoting. WCF is an SOA tool  which is designed to use shared services ( which never worked in OOP for many large firms) . Persisting the same Business logic classes caries the same dependencies to the client , meaning when you change the server you have to change all the clients. SOA is not imune from this pain but they have done everything to make this as painless as can be ( note versioning in Data Contract Messages and Service Contracts) . I have had many services releases without changing the clients this gives me the flexability of creating or changing existing functionality without require the distribution of a new DLL.

 

I>t is seems just plain wrong for an intra-application communication channel to define hundreds to thousands of interfaces >for every concrete type when a few generic >interfaces should not only suffice, but be the desired solution. In this scenario, WCF is needed for nothing other than having a >client gain access from a remote location > as though it were "on-site".

Thats the thing in WCF you send a LOT of data in one message and communicate infrequently but the messages are very complex.  With remote objects  you send smaller  amounts of data frequently .  This is a design mismatch that you are having trouble dealing with . There are a number of people in SOA who start designing the system from the messages that will be send ( COntract first) which is very different from OO.  OO systems that were designed to operate over low bandwidth conditions will have less trouble as they will normally have rather complex objects they send anyway.  A message might contain data for 50 classes hence you dont expose each class.

The good news is you can build a new message layer and hook this into your system it is just a lot more work than marking it with attributes , but IMHO is well worth it. Have a look at teh Services Factory from Patterns and Practices group  this has a converter which helps a bit for converting your messages to your BL.

Appologies for the rushed messages.

Regards,

Ben

 

 

 

 

Answer 8

First, thank you very much for your well-thought out comments. I do appreciate them.

I really like WCF and WF, the design is remarkably solid and combines nearly every feature a developer could desire with one caveat: the transfer of data from a managed client to host service.

There are many design models such as MVP (Model-View-Presenter), MVC (Model-View-Controller), and many others. They all have their advantages and disadvantages. The one core concept I find most important (based on my experience) is to have the client have as few dependencies as possible and they all require object data exchange with a service.

With SOA design, the assumption is that a service is published with as much as detail possible via established and accepted standards (I.e. WSDL and XML) and I have already stated that for true inter-application or B2B type scenarios I agree with this design. I also understand that a huge consideration is that a client consumer of a SOA service should not have dependencies on custom .dlls because of distribution issues. I tend to agree; especially for cross-language scenarios.

However, when I am involved in designing an application, I need a "complete" solution. If WCF is not really designed for sending data in a generic fashion for intra-application client to service host scenarios, then I might end-up mixing communication standards such as using remoting or worse - bloating my design model by over-creating services and their associated contracts. I am not big on remoting because it uses MarshalByRef where there is a pseudo direct connection between client and server objects. Even if this is acceptable, it would mean I would need to accomodate the very different design constraints between WCF and remoting. I quickly start finding some conflicts and duplication of effort such as creating custom sinks to perform what is already built-in to WCF. It really does complicate matters greatly to require another communication channel implementation.

I have found that I can use WCF and accomodate both needs if I take over the serialization process of my intra-application objects prior to sending them in the WCF interface. Thus, if I have a single Interface that is implemented by many objects, and I want the WCF interface to allow any instance of an object  that implments the common interface to be sent (and have access to all properties of the exact object after its sent); all I have to do is send a byte array along with an identifier of the type through the WCF communication channel. The server and client proxies then recognize how to deserialize the byte array back into the correct object. In other words, one interface can be used for transferring  many, many different objects that a have common interface implemented. It is possible now, but not directly and not by using generics via WCF.

Currently, I can eat my cake and have it to - but it could be better.

I would much prefer to have the WCF interface be designed for this in that generics can and should be supported. Would it require that both client and server (both sides of the communication channel) have access to a cusom library that defines the custom types for generics to work: yes, of course!

Thus, I suggested a custom attribute for this scenario. The developer would have to know the added constraints that they are requiring of the client when they implement this "generics" attribute. I agree, this would "not" be a good choice for any typical SOA scenario where a wide variety of third-party clients might not even be able to use a custom .dll. This is specifically for scenarios where the developer is creating and managing both the client and the service. With this support, WCF would now be a complete solution for communication needs rather than supplying part of the solution.

I ask you to consider this: in an intra-application, client to service host scenario, how likely is it that updates or changes would add or change features such that the UI has to be modified and redeployed anyway? If I had an Invoice object with an associated UI and I add new properties to the invoice, I would also have to add these properties as UI elements on the form. Thus, the UI would need to be rebuilt and redeployed anyway. I have no problem requiring that the client application has a requirement to stay current wth the host.

Am I really that nuts? I have to tell you that I still stand-by-my-guns based on many conversations with many other developers considering WCF and WF for their applications. They all have commented on the lack of support for generics and intra-application design. Most developers that I converse with refuse to make the switch because of this very issue. I honestly think that very careful consideration should be given to my comments. I can't rewrite or customize the source code for WCF, but I do know that I can workaround the problem by taking over the serialzation/deserialization process of objects. It is due to this experience that I know that the support of generics is very possible and should not conflict with the existing design at all. It would simply be an added and optional feature - if the decision to support it is taken. If I don't express my view, then I can't possibly expect future support. Nobody has to agree with me, but I suspect many, many developers would appreciate this feature and I believe many would consider it essential.

Thanks,

Trevor

 

 

 

 

 

 

 

Answer 9

Trevor,

Take a look at an article by Aaron Skonnard which shows a custom attribute for the NetDataContractSerializer:  http://pluralsight.com/blogs/aaron/archive/2006/04/21/22284.aspx.  We also have a tightly coupled distributed application based on some legacy code, and the DataContractSerializer didn't meet our needs.  The NDCS, along with this attribute, works great.

Answer 10

Hello Treveor

"First, thank you very much for your well-thought out comments. I do appreciate them."

I find it interesting cause this was my position 4 years ago,,thoguh there was no generics in .NET at the time ( so cant be that important..) , my nice OO design had inheritance , abstraction interfacts etc , all of which causd problems and pain with serialization

I" really like WCF and WF, the design is remarkably solid and combines nearly every feature a developer could desire with one caveat: the transfer of data from a managed client to host service.

There are many design models such as MVP (Model-View-Presenter), MVC (Model-View-Controller), and many others. They all have their advantages and disadvantages. The one core concept I find most important (based on my experience) is to have the client have as few dependencies as possible and they all require object data exchange with a service. "

The thing here is you are used to reducing this with interfaces etc . With SOA you do this via contracts which is the same as an interface.

"With SOA design, the assumption is that a service is published with as much as detail possible via established and accepted standards (I.e. WSDL and XML) and I have already stated that for true inter-application or B2B type scenarios I agree with this design. I also understand that a huge consideration is that a client consumer of a SOA service should not have dependencies on custom .dlls because of distribution issues. I tend to agree; especially for cross-language scenarios. "

"However, when I am involved in designing an application, I need a "complete" solution. If WCF is not really designed for sending data in a generic fashion for intra-application client to service host scenarios, then I might end-up mixing communication standards such as using remoting or worse - bloating my design model by over-creating services and their associated contracts."

Again the problem here it is corrupting your OOP design that you are objecting to... OOP and SOA are different design methodolgies.  You can even use SOA to talk to one module in your app to another  - lets not go not this as its an argument we have here in terms of performance etc.  In my oppinion if you use OOP within each component the objects become more meaningfull  In the context that they are being used resulting in cleared code and better maintenance.  DTO type objects we have used in the past kind of just muddy the water and really are just data ... I have made many compromises in larger systems so diffferent clients get the same thing without adding new methods or having huge objects.

" I am not big on remoting because it uses MarshalByRef where there is a pseudo direct connection between client and server objects. Even if this is acceptable, it would mean I would need to accomodate the very different design constraints between WCF and remoting. I quickly start finding some conflicts and duplication of effort such as creating custom sinks to perform what is already built-in to WCF. It really does complicate matters greatly to require another communication channel implementation."

I would go all remoting or all WCF not both . Using MarshalBy Ref for an interface with DTO removes that Pseudo link . I have used this in the past ... you can see how SOA came about.

"I  have found that I can use WCF and accomodate both needs if I take over the serialization process of my intra-application objects prior to sending them in the WCF interface. Thus, if I have a single Interface that is implemented by many objects, and I want the WCF interface to allow any instance of an object  that implments the common interface to be sent (and have access to all properties of the exact object after its sent); all I have to do is send a byte array along with an identifier of the type through the WCF communication channel. The server and client proxies then recognize how to deserialize the byte array back into the correct object. In other words, one interface can be used for transferring  many, many different objects that a have common interface implemented. It is possible now, but not directly and not by using generics via WCF."

Be very carefull on using byte arrays through html transports you can get a whole lot of <byte>123</byte>  =13-16 bytes for each byte.  I really think you shoudl go remoteing or WCF the cross technology issues will byte you more than any purism of the design. Alsothere is no reuse of byte arrays etc. I have some something similar with CE devices  running over 9600 bause but this was cause i wanted binary serialization . - hence i learned about the html overhead.

"Currently, I can eat my cake and have it to - but it could be better.I would much prefer to have the WCF interface be designed for this i I that generics can and should be supported. Would it require that both client and server (both sides of the communication channel) have access to a cusom library that defines the custom types for generics to work: yes, of course! "

I disagree i think its really import to emphasise the SOA way and relegate OOP to winthin the application. I think developers should really try the SOA apporach and then use remoting for OOP and WCF for SOA. Mingling will cause a lot of grief  and using a transfer message and recreating the generic object is not a lot of work and is easy to maintain .

"Thus, I suggested a custom attribute for this scenario. The developer would have to know the added constraints that they are requiring of the client when they implement this "generics" attribute. I agree, this would "not" be a good choice for any typical SOA scenario where a wide variety of third-party clients might not even be able to use a custom .dll. This is specifically for scenarios where the developer is creating and managing both the client and the service. With this support, WCF would now be a complete solution for communication needs rather than supplying part of the solution."

"I ask you to consider this: in an intra-application, client to service host scenario, how likely is it that updates or changes would add or change features such that the UI has to be modified and redeployed anyway? :"

We get requests every week . They are not done very often in some environments due to the cost -  if you can make changes quicker and cheaper people will request more. TDD and services can really help here,   

"If I had an Invoice object with an associated UI and I add new properties to the invoice, I would also have to add these properties as UI elements on the form. Thus, the UI would need to be rebuilt and redeployed anyway. I have no problem requiring that the client application has a requirement to stay current wth the host."

You are correct when you have 1 server and 1 application. However lets say you have a new requirement that uses some of your functionality , do you use a modfied version of the client ? What do you do then when it changes your back end ?  Do you roll out both applications.  As things grow you always get different versions , fragmentation etc .

All our application comms  are inter application ... One thing i do think though is people have not realised the cost and it is probably not economical for a lot of systems  NOTe with SOA you have multiple service some on the client some on servers. .

"Am I really that nuts? I have to tell you that I still stand-by-my-guns based on many conversations with many other developers considering WCF and WF for their applications. They all have commented on the lack of support for generics and intra-application design."

It shows an OOP view , they will not convert until they try a pure SOA app  ( contract first design preferrably) .. I didnt.  My first 5 services app used a shared DLL for all the  logic ( running in one app domain) as i was very cautious  but it has gone really well and my latest app has 7 services. Its almost the same situation as when OOP developers told procedural progarmmers they have to make the leap... its just OOP remote objects  is in the reverse spot now.  I was fortunate enough to do this in a greenfield implementation.  Again i reiterate OOP within modules is fine it is only the remote object structures that are under attack - this creates smaller  object models.

In OOP we were promised reuse , this is also a promise of SOA , the jury is out to see if it wiill increase reuse better than OOP ( at large organisations)/ ).

It is interesting to contrast with VB developers ( procedural) who just consume the service as a data source and dont have too many issues.

 "Most developers that I converse with refuse to make the switch because of this very issue. I honestly think that very careful consideration should be given to my comments. I can't rewrite or customize the source code for WCF, but I do know that I can workaround the problem by taking over the serialzation/deserialization process of objects. It is due to this experience that I know that the support of generics is very possible and should not conflict with the existing design at all. It would simply be an added and optional feature - if the decision to support it is taken. If I don't express my view, then I can't possibly expect future support. Nobody has to agree with me, but I suspect many, many developers would appreciate this feature and I believe many would consider it essential."

I really think its a abd idea to use WCF /SOA unless you have a major redeign despite the temptaion of the tools .

Regards,

 

Ben

Answer 11

First, THANKS AGAIN!!

Second, I hate the auto-sizing font of the forum - arg!

I am not an SOA expert, as many are not. Many developershave extensive libraries and a full-out upgrade is not a realistic option; especially when there is the reality of a significant learning curve.

As far as the client:

1. I do not ever intend for a single server to host multi-versions - simultaneously - its an internal to a single organization application. Having said that, it will be very likely to access SOA services from the server: the app will not be hosting any of them. Of course, different organizations will be at various states of different versions, but that is not the same as a single service hosting multi-version clients. All the text is localized (external to the .dll) so that is not an upgrade, simple riles (date comparisons, RegEx patterns, etc are all downloaded from the service and are also not upgrades), changing business rules that do not affect the database or UI are only upgrades to the service and are not an upgrade to the client. Thus, the only time a client needs an "upgrade" (new version) is when the UI MUST have properties modified or display logic altered. Thus, there is no scenario where the client would not have to be recompiled and redeployed: SOA or OOP.

2. The client is so thin that I find it hard to believe that it could be more efficient or easier to maintain. Accomodating multiple versions and supporting dynamic connectivity is certainly more expensive to maintain for a client that a single-versin model. The client displays data, offers options, filters the options so that choices that would be rejected are not displayed, and performs simple rules checks (required entry, date checks, RegEx, etc). The rules are loaded from the service when each object type is first loaded and only reloaded if the version for the rules has changed. The "filtering/permission" settings are loaded when a user first logs in and are also only reloaded when the collection of settings for that user has changed.

Again, I am not in a position to argue whether SOA is better than OOP, but my needs are specific and the application is not dependant on third-party communication.

I have many third-party products that I use. One is an ORM which is based on designing classes (objects) and the product handles the persistence to the database. I can switch between SQL Server, MySQL, Firebird, Oracle, or others with one line of code changed. I do not write a single query. The entire process is handled behind the scenes for me. I LOVE RAD development. The objects have no sense of what is valid. So, if I have a screenshot and a list of rules defining the properties for each piece of data, and then I have a flowchart (think WF) describing the business logic, the fully working screen can be built in a single day (UI, simple rules, permissions, communication, security, etc).

I am leary, I am suspicious; however, I am always aware that times change and I must always evaluate and reevaluate what is out there.

You may be right about SOA, but what I have is working, very efficient, and I do not have the time to invest all the time that's necessary  to confirm your opinion. So, what I need is to be able to migrate, ease my way in, and learn as I go. I have figured out how. Clearly, I am moving towards WCF and WF (way too early for WPF). However, Microsoft is making all the learning curve and migration issue for remoting based developers, as you pput it: OOP developers very difficult. I do not understand this decision. I can only say that I meet far too many that would have been swayed had a OOP situation been addressed, in the open, with help, with guidance, and with MUCH support. I suspect that you are correct about your opinion (I wish I had your knowledge and experience) - ahhh - alas - I do not!

I am very happy with my design and I know that I have already converted much that I thought I would not from as little as 2 months ago.

Seriously, if I was in charge at WCF, I would get one of my best remoting programmers to build a reoting demo that nvolves users logging in with username/password validation and using OOP business objects. I would rop out the datbase entirely and would store the data in XML files for the demo to make that as little an element of the demo as possible. Then I would setup many screencasts showing how to convert the remoting demo to a WCF application which is still OOP based. Then I would create screencasts to show how to migrate to full SOA.

In essence, people want to download a private instructor. Would MS loose money on some training: yes. However, I believe, this would drag many, many devlopers deep in WCF dependence and would bring the need for XP or higher clients, much higher, and would expand the spiderweb effect would take off.

Trevor

P.S. I am still reading and reconsidering: Thank you much!

 

Answer 12

Sorry about the delay , had a deadline ..

First, THANKS AGAIN!!

Second, I hate the auto-sizing font of the forum - arg!

- Yep I should work them out.

I am not an SOA expert, as many are not. Many developershave extensive libraries and a full-out upgrade is not a realistic option; especially when there is the reality of a significant learning curve.

- This is the same situation many companied were in when implementing OO and IMHO a very carefull cost benefit analysis needs to be done when changing architecture.

As far as the client:

1. I do not ever intend for a single server to host multi-versions - simultaneously - its an internal to a single organization application. Having said that, it will be very likely to access SOA services from the server: the app will not be hosting any of them. Of course, different organizations will be at various states of different versions, but that is not the same as a single service hosting multi-version clients. All the text is localized (external to the .dll) so that is not an upgrade, simple riles (date comparisons, RegEx patterns, etc are all downloaded from the service and are also not upgrades), changing business rules that do not affect the database or UI are only upgrades to the service and are not an upgrade to the client. Thus, the only time a client needs an "upgrade" (new version) is when the UI MUST have properties modified or display logic altered. Thus, there is no scenario where the client would not have to be recompiled and redeployed: SOA or OOP.

- Say you have a request to highlite some text based on a new field .. at present it is likely to be ditched as too expensive. SOA makes these changes cheaper. Churn in distributed systems is what SOA is good at and is what justifies the extra cost ( allong with much better cross app reusability) - if an application has little churn it can be argued that procedural programmin is superior to OO- the main benefit of OO is maintenance ( reusability is a bit of a myth in most organisation - though yours may be different supporting a single app) . If the application does changes a little than the maintenance benefit becomes small. In a cost benefit analysis you would be better of doing RAD etc.

2. The client is so thin that I find it hard to believe that it could be more efficient or easier to maintain. Accomodating multiple versions and supporting dynamic connectivity is certainly more expensive to maintain for a client that a single-versin model. The client displays data, offers options, filters the options so that choices that would be rejected are not displayed, and performs simple rules checks (required entry, date checks, RegEx, etc). The rules are loaded from the service when each object type is first loaded and only reloaded if the version for the rules has changed. The "filtering/permission" settings are loaded when a user first logs in and are also only reloaded when the collection of settings for that user has changed.

- I think we are going down the wrong track a bit here, the number one reason you need to roll out new clients  is new functionality with SOA some customers can upgrade some do not with remoting all clients MUST be updated if the service changes as the type will be different. Tthough it looks like most SOA clients are a bit fatter - most ( not all) roll out data not screen information.

-As an example if your company were to offer a service like derivatives.com where smaller companies /  investors all over the world can use a single global service ( they provide a service for big firms and a shared service)  ,  could your app architecture handle this new model ?  How do you then roll out new functionality ?

Again, I am not in a position to argue whether SOA is better than OOP, but my needs are specific and the application is not dependant on third-party communication.

I have many third-party products that I use. One is an ORM which is based on designing classes (objects) and the product handles the persistence to the database. I can switch between SQL Server, MySQL, Firebird, Oracle, or others with one line of code changed. I do not write a single query. The entire process is handled behind the scenes for me. I LOVE RAD development. The objects have no sense of what is valid. So, if I have a screenshot and a list of rules defining the properties for each piece of data, and then I have a flowchart (think WF) describing the business logic, the fully working screen can be Built in a single day (UI, simple rules, permissions, communication, security, etc).

I am leary, I am suspicious; however, I am always aware that times change and I must always evaluate and reevaluate what is out there.

You may be right about SOA, but what I have is working, very efficient, and I do not have the time to invest all the time that's necessary  to confirm your opinion. So, what I need is to be able to migrate, ease my way in, and learn as I go. I have figured out how. Clearly, I am moving towards WCF and WF (way too early for WPF).

- Yep

However, Microsoft is making all the learning curve and migration issue for remoting based developers, as you pput it: OOP developers very difficult. I do not understand this decision. I can only say that I meet far too many that would have been swayed had a OOP situation been addressed, in the open, with help, with guidance, and with MUCH support. I suspect that you are correct about your opinion (I wish I had your knowledge and experience) - ahhh - alas - I do not!

- Just like Procedural RAD development is still around with OO ( look at all the VB clients in large banks) so OO will be around with SOA.

I sort of think like this

-Single application quick and dirty - small company - RAD

-Single large app think OO.

-Small user count - quick and dirty . RAD/SQl

-Small user count heavy client - OO

-Large user count single client - single service  OO/ Remoting ( remoting will be there for 10 years)

-Large user count multiple clients / or multiple versions of clients or lots of services  - SOA , clients can be RAD or OO depending on complexity.

-There are many other cases out there, but it is important to remember what OO addresses - maintainablity , SOA Addresses reuses of services.

I am very happy with my design and I know that I have already converted much that I thought I would not from as little as 2 months ago.

Seriously, if I was in charge at WCF, I would get one of my best remoting programmers to build a reoting demo that nvolves users logging in with username/password validation and using OOP business objects. I would rop out the datbase entirely and would store the data in XML files for the demo to make that as little an element of the demo as possible. Then I would setup many screencasts showing how to convert the remoting demo to a WCF application which is still OOP based. Then I would create screencasts to show how to migrate to full SOA.

- The thing is i dont think many remoting apps will change -The first thing with SOA is you should pull your back end apart and have multiple services each with a seperate function for each- and each service could live on a seperate machine and be used by different apps. This will kill performance but you design it via contracts and infrequent messages - this automatically creates a more decouples system. At this point you realise since the client does not talk to the server all the time the client becomes fatter and stores more data locally , even local searches are common. Another difference is if you have a new business requirement you may create a new client ( or better yet a plug in module  via CAB) rather than exteding a single app all the time.

 We have one app under development now which is for small clients these use remoting to talk to a local server  but this server will talk to the back end to an SOA server.  Running SOA at the local client for 1-3 users is just overkill - the benefit of reuse is not there.

In essence, people want to download a private instructor. Would MS loose money on some training: yes. However, I believe, this would drag many, many devlopers deep in WCF dependence and would bring the need for XP or higher clients, much higher, and would expand the spiderweb effect would take off.

- Yes there is a big devide here MS does not have the big consultuing firms pusing like the java/Axis camp. However donwload the Patterns and practices Web service guidance package it tries to send you down the right path. 

Regards,

Ben

Trevor

P.S. I am still reading and reconsidering: Thank you much!

 

Answer 13

A very good thread (and quite a long read). I would like to just join in with MY experiences using WCF (and other SOA platforms).

 

There is a reason why "Share Schema and not Classes" is one of the most basic tenets of SOA. This is not limited to WCF.

 

In my early SOA days, I tried the shared classes methodology. I often suffered pain getting it to work, and then found out exactly how fragile it was.

 

These days I do NOT share ANY classes across process domains [AppDomains within a process are a different story]. The classes (and therefor assemblies) on a "client" are completely isolated from the classes exposed on the "server".

 

While this initiaially seemd to be unnecessary duplication I found it to be of great benefit. I now think ALOT more about what I am exposing to the outside world. In 90%++ of the cases exposing a "Business Object" was NOT the appropriate thing to do. (Bulk, Security, Control, etc...)

 

Now I expose very limited and simple schemas. On the opposite side of the connection I recieve this information into very simply proxies.

 

For the more tightly coupled uses, there will be a re-use of the business objects on both sides, but NOT a transferrance of the Business object over the connection.

 

This has been working well for the last few years, and I have no regrets about taking this approach.

 

Hope this helps.

Answer 14

There is obviously a lot to say about this issue, and I am still struggling with how to make the transition to SOA, or even whether it is appropriate for my situation. However, my primary concern is this: WCF has been described as "the next version of remoting" (https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2274027&SiteID=1). Although MSFT has gone to great pains to tell us that remoting is not going away, and it is still recommended for some niche scenarios (http://blogs.msdn.com/drnick/archive/2007/09/25/when-to-use-remoting.aspx), is it clear that development on remoting has been halted, and all future development work will be in WCF. But as has been pointed out in this thread, the two technologies are very different: they are based on different paradigms, and they take different approaches to solving the problems of distributed applications. So why is it that remoting is essentially being deprecated in favor of WCF? To put it another way, why is MSFT forcing us to use SOA, when, as has been pointed out in this thread, SOA is not always appropriate? I understand that SOA is growing in popularity, and I understand that MSFT had to come out with better technology support for it; but when I am writing small, highly interconnected systems, SOA comes with far too much overhead and provides no significant benefit. Of course I have the option of using remoting instead, but then I am tying myself to a technology which will soon become obsolete. Can someone give me a third option?

Answer 15

 My understanding is:

The Xml format is not the format to "transfer the inheritance". Of course there are Imports etc. but they work badly.

Could we implement inheritance in the Xml? Uhhmm.. partly.

 

There is the "any" element to pass "any" data structure.

IMHO The Xml standard lacks the easy methods to serialize/deserialize "unknown" data.

Most of the questions below could be covered by a case: "The proxy should not care about the transmitted data structure, but the client should".

Give us the "target namespace inheritance rule" (to manage the class inheritance), because the target namespaces are the "type names". Say the Xml document with the target namespace the "http://a.b.c.d/" should be "derived" from the document with the schema the "http://a.b.c/". That means the first had more precise descriptions of the data.

Answer 16

Hello ,

 

A bit late ...

 

Basically microsoft needed an SOA technology ( its part of the WS consortium) , and since SOA can handle 90%-99%  of remoting solutions ( Note the business solution - not the remote object model) im sure they decided to add a few remoting features ( serializing Interfaces via knownType which was not in some of the earlier CTP's)  and only support WCF going forwards.  Also a lot of people used remote objects in larger organisation and this left a bad taste for Binary serialization hence the wpf binary serialization ( which is really an xml binary)  .

 

This is a rational business decision and they are doing the same with WPF and windows forms. Im sure WPF ( and WPF/e) will be the main UI going forward.  By standardising on one solution they can make that solution better.

 

If you have an existing remote object application you will suffer  ( or better yet continue with remoting) , but if you are developing a new app you can base it more around SOA principals and get significant benefits for your clients such as integration into other systems , better tooling , standard security , better reuse/modularisation  ( reuse in OO is very poor)  etc. 

While remoting samples are quick , real life large apps i have seen are often dreadfull , it should be noted in 2001 i ( and many others) were writing remoting apps and it was best practice to not abstract away the network and use interfaces/DTO libraries- these solutions map very nicely into SOA. And it is not hard to swap between  them  ( the server retains the library and the client generates a new library based on aa proxy of the server) - if you are using XML serialization  and use your xsd to generate the DTO's you almost have an SOA system ( and this is how SOA developed)

In my opinion SOA solutions are often MUCH faster than a lot of remote object ones and can be pretty lean ( binary and no security)  , this is basically done by sending the message once and not have conversations , by the time you have 2 calls a single fat call is usually better.  ; Especially if you need security. 

 

Does this impact the design ? Absolutely the message is a first class design decision in SOA it does not try to abstract the network away .

 

In terms of smaller projects WCF bites and will add a lot to the cost .. It is a development time overhead but i often ask should these have been distributed anyway ?  If however you are talking lots of small interconnected systems than SOA is ideal. Each is a completely seperate component with no links (except for maybe a lightweight framework)  , if one is behaving badly and many fixes have failed or bugs keep apearing because it was wirtten by a summer student ,you can regenerate it from an interface , rewrite it , re run your tests , release , point an existing service at the new service and all the other systems are unchanged this is very powerfull and really cuts your testing/release cycles.  To Roll back you just point at the old service.  The same applies for testing.  

 

Looks like the source code for remoting will be released ( with the framework) so im sure some companies will take up  extending remoting in future.

 

Regards,

 

Ben

Answer 17

I think you are making great points but I substantially disagree. Consider that the main purpose of SOA or Remoting is simply to act like the post office and get a package safely and securely transferred from one place to another.

 

With SOA and - specifically - B2B issues we have numerous businesses interacting and the idea was for some common communication to be created where business A can send/receive with business B. Business C can get involved, and then D, etc etc. For this to work a dictionary - so-to-speak - the XML, XSD,XAML, etc defines the specifics of a package. Why do they do this? Well, the idea is that all the information necessary to communicate is publicly published... the reality...

 

Well, the reality is that the only reason to create the pre-determined public information is to be more efficient. Between businesses, it can be more efficient. I carefully say - can be - becuase its often not, even where it should offer benefit.

 

VERY IMPORTANTLY - When you are in control of the client AND the server, and it is not two or more parties involved, then SOA is a BIG, FAT, BLOATED PIG FULL OF NONSENSE!!!

 

Why should a developer create a library, and then create masssive bloat (XSD files, validation libraries, define exception messages all to accomodate some theoretical third party? Why, when there is no third party? The same library they built for the server should simply be used on the client and WCF should just encrypt, compact, send, receive, expand, and decrypt.

 

Sorry, but it is continually suggested that its advantageuos to always apply SOA techniques, its an advantage... because... it will make you compatible with party B, and Party C, etc. Hmmm quadrupling the complexity and delaying development to be compatible with a non-existent 3rd party is rediculous. SOA may be able to handle 90+% of remoting (transfer of data), but it does so at a VERY GREAT COST! Further, experiences teaches that the compatibility of "universability" is highly questionable.

 

Its even worse when 70+% of the users DO NOT NEED SOA!

 

Let us assume for a moment that we do need third parties involved. Have you have had a team build a library and then see the efforts it takes for a 3rd party to use the so-called universally public information as published by SOA standards? Measure the time it takes to add-in all the SOA overhead, then measure the time it takes working out the issues between yourself and party B. MNOw add-in party C with a different skillset (a big point here is the assumption that third parties are actually skilled in SOA and that they actually agree on methodology even when they are). I have found that B is slightly different is how they consume a service compared to C, and D, etc. What it means is that they aren't actually interacting consistently and inconsistency is disastrous in the long run.

 

Now, more importantly - try another test. Drop SOA statndards and build a typical client and your typical service... then simply share your client library with the third parties and WHA-LAH - they are all using the same client which equals consistency.

 

I am deadly serious here. I have worked for some time on a library/framework that uses WCF and its security features. My library is compact, its fast, its flexible, its compatible with click-once, and its much, much easier to build and deploy, and MOST IMPORTANTLY - MUCH EASIER TO MAINTAIN!

 

*** WARNING - KEY TO ENTIRE ISSUE DESCRIBED BELOW **

Compare what I am saying to what is happening in the auto-industry right now. GM lost 10 billion 2 yrs ago and 39 billion last year. Toyota, on the other hand, has earned a 7% profit during the same period: they are blowing GM out of the water. It is fairly well known why. Toyota uses the concept of Kaizen (continuous improvement), they have standardized, modulized, and are simply more efficient. The difference is that they recognize that they must continually seek to ELIMINATE WASTE. My main point is that SOA introduces substantial flat-out waste. It is a waste of time to define XSD files when I control the client and control the server(s)/ services. It is a waste of time! Period!

 

Efficiency matters.

 

Honestly, I truly believe that ignoring SOA design concepts when they are clearly not needed is wise, efficient, smart, intelligent, and results in faster time to market, higher reliability, and, especially, higher customer satisfaction.

 

 

Answer 18

BenK95781 wrote:

Basically microsoft needed an SOA technology ( its part of the WS consortium)...

 

Of course they did, and in fact they took a hit by taking so long to come up with a first-class SOA technology. But in the process, they tossed all other distributed networking concepts out the window, which is what I, Trevor, and many others object to.

 

BenK95781 wrote:

...and since SOA can handle 90%-99%  of remoting solutions

Of course SOA CAN handle most distributed software solutions, just like remoting CAN handle most distributed software solutions. That doesn't mean that either one of them is the BEST solution for an overwhelming majority of situations. Why can't people understand that different environments create different needs which are best handled by different technologies?

 

BenK95781 wrote:

This is a rational business decision and they are doing the same with WPF and windows forms. Im sure WPF ( and WPF/e) will be the main UI going forward.

Actually, WPF suffers from many of the same problems as WCF. Is it "better" than Windows Forms? Arguably, yes. Does it allow for more complex scenarios, and have the potential to improve the look and feel of large complex UIs while reducing development time? Certainly. But what does it do for the developer trying to create small, efficient line-of-business applications quickly? Add overhead and development time, not to mention a massive learning curve, while offering no substantial benefits over Windows Forms. But Windows Forms is being deprecated in much the same way that remoting is, which leaves the Windows Forms developer in a very similar place to the remoting developer: out in the cold.

 

Unfortunately, this signals a trend within the Microsoft developer division, one that I have been discussing lately with a number of MSFTies on blogs and forums: developer solutions will be targeted toward large multi-national corporations with large multi-national needs, and everyone else will just have to make do. I'm sure this is a financially motivated decision, and since Microsoft is a for-profit company, I have a hard time faulting them for it. I do think that they are missing out on the long-term benefits of creating a framework that targets the average developer, rather than the large corporate developer (note: I am a corporate developer, but my needs simply don't scale into the audience currently being targeted by Microsoft), since in the grand scheme of things creating developer buy-in to their framework will be worth more than short term support contracts. But in the end, they will do what they believe is in their own financial best interest. Realizing this has caused me to seriously consider switching to a non-Microsoft development platform, such as D, rather than continue to invest my intellectual capital and my company's future in a framework that is clearly being designed away from us.

 

BenK95781 wrote:

By standardising on one solution they can make that solution better.

I understand the desire for unification and standardization, and it makes a great sound bite. However, in practice, standardization means abstraction, and abstraction means loss of functionality. That is exactly what is happening here. By "standardizing" on an SOA model, all other options are taken away, meaning the developer is being pigeon-holed into a solution that may not be the best for his situation.

 

BenK95781 wrote:

If you have an existing remote object application you will suffer  ( or better yet continue with remoting) , but if you are developing a new app you can base it more around SOA principals and get significant benefits for your clients such as integration into other systems , better tooling , standard security , better reuse/modularisation  ( reuse in OO is very poor)  etc.

Assuming, of course, that you NEED integration into other systems, tooling support, and a standard security model. If you don't, all of that is just wasted air. And since when does SOA give you better reuse or modularization? Reuse in OO is very poor??? Where do you get this from? In my experience, SOA requires you to jump through numerous extra hoops every time you want to reuse something, whereas an object-oriented approach in plug-and-play (you do know that reuse is one of the main reasons OO exists, right?)

 

BenK95781 wrote:

While remoting samples are quick , real life large apps i have seen are often dreadfull

Have you seen any real-life large SOA apps recently? Dreadful doesn't begin to describe them. The fact of the matter is that in the real world, most large scale mulit-team applications end up being patched together, and there is no technology that can improve that. As much as we would like to pretend that any of the dozens of development methodologies we have come up with can make short work of any development project, the fact of the matter is we are all human, and when we bite off more than we can chew, the result just doesn't look very good, even if we can make it work.

 

BenK95781 wrote:

it should be noted in 2001 i ( and many others) were writing remoting apps and it was best practice to not abstract away the network and use interfaces/DTO libraries- these solutions map very nicely into SOA.

It is quite easy to make the network explicit in a remoting solution, and as you say, it is considered best practice in solutions of decent size. But what we are talking about here is reuse of transmittable types in an object-oriented manner, which WCF and SOA, being message-based not object-based, completely disallow, for NO GOOD REASON.

 

BenK95781 wrote:

And it is not hard to swap between  them  ( the server retains the library and the client generates a new library based on aa proxy of the server) - if you are using XML serialization  and use your xsd to generate the DTO's you almost have an SOA system ( and this is how SOA developed)

But how much faster would it be if you didn't have to create an XSD, or generate new DTOs? Which you wouldn't have to do if WCF included support for the remoting paradigm, which is exactly what we are talking about.

 

BenK95781 wrote:

In my opinion SOA solutions are often MUCH faster than a lot of remote object ones and can be pretty lean ( binary and no security)  , this is basically done by sending the message once and not have conversations , by the time you have 2 calls a single fat call is usually better.  ; Especially if you need security.

Well, in my opinion, I have NEVER seen an SOA solution which was faster in practice than a remoting solution, nor do I see any reason from a technological perspective why it should be.

 

BenK95781 wrote:

In terms of smaller projects WCF bites and will add a lot to the cost .. It is a development time overhead but i often ask should these have been distributed anyway ?

So you're saying that there should never be any such thing as a small-scale distributed application? Wow, what have I been doing all these years?

 

BenK95781 wrote:

If however you are talking lots of small interconnected systems than SOA is ideal. Each is a completely seperate component with no links (except for maybe a lightweight framework)  , if one is behaving badly and many fixes have failed or bugs keep apearing because it was wirtten by a summer student ,you can regenerate it from an interface , rewrite it , re run your tests , release , point an existing service at the new service and all the other systems are unchanged this is very powerfull and really cuts your testing/release cycles.  To Roll back you just point at the old service.  The same applies for testing.

 

I can get everything you just described using an object-based remoting solution, PLUS I don't have to worry about regenerating contracts and DTOs for EVERY SINGLE SERVICE that I want to reuse! How does forcing the extra overhead and bloat of redefining contracts for objects which already exist in shared libraries make SOA "ideal"?

 

BenK95781 wrote:

Looks like the source code for remoting will be released ( with the framework) so im sure some companies will take up  extending remoting in future.

 

Actually, I doubt many will. Its simply not worth the time or the risk to develop your own distributed computing solution when there is already one available, even if it does not match your needs and forces you to jump through unnecessary hoops. So what will probably happen is the vast majority of us will continue to use WCF while wishing that Microsoft would give us a better solution.

 

By the way, it would be easy to read all of the above and come to the conclusion that I hate WCF. Nothing could be further from the truth. I love it. I think it brings a lot of functionality to the table that was impossible or very difficult using remoting, I like the relative ease with which various protocols and behaviors can be configured, and I like its declarative nature (although I often wish that the imperative options were easier to use). And for software which is already a good candidate for SOA, I think WCF is ideal. However, what Trevor and I, and numerous other developers I have seen blogging and commenting on this issue want to get across is this:

 

There are many distributed software solutions which are NOT good candidates for SOA.

 

...and for these solutions, WCF is far from ideal. I wish Microsoft would at the very least acknowledge that, and then either give us a better solution for those situations, or at least tell us that they are not going to. Instead, all we hear is "WCF is the perfect solution for all but a few niche distributed software needs", which leaves us with nothing to believe but that they are simply out of touch with a large portion of the developer community, and have left us to fend for ourselves. Which I suppose is exactly what has happened.

 

David

Answer 19

Hi David ,

 

Enjoy these discussions :-)  Though im a bit evangelical - those hard to convert are big champions.

 

BenK95781 wrote:

Basically microsoft needed an SOA technology ( its part of the WS consortium)...

 

Of course they did, and in fact they took a hit by taking so long to come up with a first-class SOA technology. But in the process, they tossed all other distributed networking concepts out the window, which is what I, Trevor, and many others object to.

 

>> Disagree. Web services were a good SOA tech ( as good as anything else which didnt cost 5 figures) and microsoft are probably more advanced than Sun/Java/Axis in adopting newer standards.

 

>> They certainly have not tossed out any thing , it is just  they will not continue new development - I have a few Com+ Systems and these are probably more worthy then remoting . Then there is a strong claim to support Vb6  etc. Remoting comes pretty far down the list.

 

BenK95781 wrote:

...and since SOA can handle 90%-99%  of remoting solutions

Of course SOA CAN handle most distributed software solutions, just like remoting CAN handle most distributed software solutions. That doesn't mean that either one of them is the BEST solution for an overwhelming majority of situations. Why can't people understand that different environments create different needs which are best handled by different technologies?

 

>> I just think people often make judgement without trying an SOA solution . In many cases it will surprise  what is better. When i start questioning these people it turns out they have very little experience actually implementing an SOA solution. SOA matches remoting best practices pretty closely.

 

BenK95781 wrote:

This is a rational business decision and they are doing the same with WPF and windows forms. Im sure WPF ( and WPF/e) will be the main UI going forward.

Actually, WPF suffers from many of the same problems as WCF. Is it "better" than Windows Forms? Arguably, yes. Does it allow for more complex scenarios, and have the potential to improve the look and feel of large complex UIs while reducing development time? Certainly. But what does it do for the developer trying to create small, efficient line-of-business applications quickly?

 

>> The data binding actually works and yes forms is better if you are just putting a grid on  once you get to master detail WPF is better. How many forms line of business apps ended up doing the binding manually  ?  I hate it every time the client asks for something unusual with forms - i actually now have a policy that i wont use binding in forms if the client wants or will want anything unusual.

 

Add overhead and development time, not to mention a massive learning curve, while offering no substantial benefits over Windows Forms. But Windows Forms is being deprecated in much the same way that remoting is, which leaves the Windows Forms developer in a very similar place to the remoting developer: out in the cold.

 

>>True , especially the learning curve .. But i did always hate forms every time i tried something hard like stuffing around with a COmbo box the underlying Com object bit me.

 

Unfortunately, this signals a trend within the Microsoft developer division, one that I have been discussing lately with a number of MSFTies on blogs and forums: developer solutions will be targeted toward large multi-national corporations with large multi-national needs, and everyone else will just have to make do. I'm sure this is a financially motivated decision, and since Microsoft is a for-profit company, I have a hard time faulting them for it. I do think that they are missing out on the long-term benefits of creating a framework that targets the average developer, rather than the large corporate developer (note: I am a corporate developer, but my needs simply don't scale into the audience currently being targeted by Microsoft), since in the grand scheme of things creating developer buy-in to their framework will be worth more than short term support contracts. But in the end, they will do what they believe is in their own financial best interest.

 

>> Again true. MS success in development has come from the legion of VB developers corporate and looking after them . The academics /purists have alway scoffed at MS solutions . At least MS have been loyal to their core devs ( except for forcing .NET on them ) . It is also worth noting Borland has completely left its developers in the lurch  and there has not been much development in RMI/Corba type remoting either for at least 10 years. 

 

 Realizing this has caused me to seriously consider switching to a non-Microsoft development platform, such as D, rather than continue to invest my intellectual capital and my company's future in a framework that is clearly being designed away from us.

 

>> The smaller solutions are of little threat  , MS main threat is Java.  Smaller platforms have small libraries and the moment the product is not hot and trendy you are on your own.  Its worth noting that WPF took 1500 man years and WCF probably about the same,

 

BenK95781 wrote:

By standardising on one solution they can make that solution better.

I understand the desire for unification and standardization, and it makes a great sound bite. However, in practice, standardization means abstraction, and abstraction means loss of functionality. That is exactly what is happening here. By "standardizing" on an SOA model, all other options are taken away, meaning the developer is being pigeon-holed into a solution that may not be the best for his situation.

 

>> Remoting was going the way of SOA anyway , and you can still do some remoting style stuff ( the best practices stuff) with  WCF. 

 

BenK95781 wrote:

If you have an existing remote object application you will suffer  ( or better yet continue with remoting) , but if you are developing a new app you can base it more around SOA principals and get significant benefits for your clients such as integration into other systems , better tooling , standard security , better reuse/modularisation  ( reuse in OO is very poor)  etc.

Assuming, of course, that you NEED integration into other systems, tooling support, and a standard security model. If you don't, all of that is just wasted air. And since when does SOA give you better reuse or modularization? Reuse in OO is very poor??? Where do you get this from? In my experience, SOA requires you to jump through numerous extra hoops every time you want to reuse something, whereas an object-oriented approach in plug-and-play (you do know that reuse is one of the main reasons OO exists, right?)

 

>> OO reuse in OO is a myth and is only good within very small teams .   The knowledge required to use a OO DLL library ( and the 100's of methods and classes ) , general documentation practice ( eg we auto document ) and not invented here  really make it hard.  I have seen this at many organisation - they all have tried and failed.  It does work ok within smaller skilled teams  , but the expected payoffs were cross team.  A few libraries spent the time  to create an easier to use standard access interface but most teams dont bother / run out of time , With SOA you start with the interface.

Go to a conference ask everyone to put up their hand who implemented a OO reuse policy - most peoples hands will go up . Then ask how many are still using it.

 

The main reason for SOA is to try to fix it because it was promised and didnt work  ( and to closer allign these reusable modules to the business requirements) .  Compare to SOA where a service has 3-9 method and you auto build your proxy this makes it real easy !.

 

 

BenK95781 wrote:

While remoting samples are quick , real life large apps i have seen are often dreadfull

Have you seen any real-life large SOA apps recently? Dreadful doesn't begin to describe them.

 

>> Yes i have written 2 over the last 4 years ..with a team . And im very happy with the result compared to the remoting ones i did.  I have also seen a bad one where they just wrapped DB stored procs , though i spoke to the architect and he basically was saying we pay a 100% overhead now and make everything interop via a standard , we can then go in and replace key parts. There are a lot of parralels here with software development.

 

The fact of the matter is that in the real world, most large scale mulit-team applications end up being patched together, and there is no technology that can improve that. As much as we would like to pretend that any of the dozens of development methodologies we have come up with can make short work of any development project, the fact of the matter is we are all human, and when we bite off more than we can chew, the result just doesn't look very good, even if we can make it work.

>>At least SOA is trying to make it better not just sticking its head in the sand saying too hard - though remoting best practice was extremely similar.  This integration is better with SOA.  Your very right about the last bit.

 

BenK95781 wrote:

it should be noted in 2001 i ( and many others) were writing remoting apps and it was best practice to not abstract away the network and use interfaces/DTO libraries- these solutions map very nicely into SOA.

>It is quite easy to make the network explicit in a remoting solution, and as you say, it is considered best practice in solutions of decent size. But what we are talking about here is reuse of transmittable types in an object-oriented manner, which WCF and SOA, being message-based not object-based, completely disallow, for NO GOOD REASON.

 

>> With very good reasons ... here are a few they apply to remoting solutions as well ( not SOA or WPF)

 

1) Build a remoting solution deploy - make a small emergency patch on the client or server and every single piece needs to be redeployed., Many people fell into this trap because it was to easy.. Multiply this by lots of systems and you have a very bad tatse in your mouth.  Note you can still do this if you dont go overboard as you can serialize into your own library , its just not as easy. Though i dont recommend it . This is why many people went the dog slow Xml route with remoting.

 

2) Proxies do this automatically for you - so why create a build and code dependency ? When it is no work and no performance overhead to have it loose.  People fudged this with remoting and using xsd,

 

3) Clients can see classes from a different point of  view  ( larger systems) .

 

4. Seperation of roll - in distributed systems real business logic should be contained on services . Clients should have logic todo with display and some UI validation. This means your class/DTO  say customer on the client has the roll to  display Customer and to validate it  ( You often get methods to help data binding /UI presentation here) yet in the back end it has a different roll and takes part in Business logic such as do we allow this person to become a customer eg a method like MeetsMinimumStandard.  This clearly breaks one of the important things in OO that an object have one roll and having UI and Business on the same objects gets really uggly after a few maintenace developers have there way. Hence you need different objects on client and server anyway . IMHO its a good way of splitting the logic.

 

5. Such objects often automatically created , further comms with the service without the developer  realising it like iteration thorugh a collection of sub objects which were on the server.  This is part of the abstract the network away.

6. It encourages developers to have messages that mymic the OO design ie based on method calls - this results in frequent messages , a cluttered interface and poor performance.  There is little aggregation done and you tend to have tons of methods creating a more difficult to maintain interface,

 

BenK95781 wrote:

And it is not hard to swap between  them  ( the server retains the library and the client generates a new library based on aa proxy of the server) - if you are using XML serialization  and use your xsd to generate the DTO's you almost have an SOA system ( and this is how SOA developed)

>But how much faster would it be if you didn't have to create an XSD, or generate new DTOs? Which you wouldn't have to do if WCF included support for the remoting paradigm, which is exactly what we are talking about.

 

>> You dont create these xsd they are auto created , and once you build your library you dont touch them unless the client to server message changes  ( We are talking remoting here - with WCF it is all automatic) . At run time this is not really used except for instantiating a DTO  the cost of which is insignificant compared to serialization, Call the serializer 0.1% less  by sending less and chunkier messages and you will have a far better response.

 

BenK95781 wrote:

In my opinion SOA solutions are often MUCH faster than a lot of remote object ones and can be pretty lean ( binary and no security)  , this is basically done by sending the message once and not have conversations , by the time you have 2 calls a single fat call is usually better.  ; Especially if you need security.

Well, in my opinion, I have NEVER seen an SOA solution which was faster in practice than a remoting solution, nor do I see any reason from a technological perspective why it should be.

 

>> I have highlighted why above - basically less client server traffic. There are a few SOA implementations that are jsut done for encapsulation reasons obviously these get none of the benfits such as chunky messages and a simpler interface  ( though they can now re-engineer some of these interface once they work out what system depends on what) .

 

>>MS benchmarks even show its faster than remoting http://msdn2.microsoft.com/en-us/library/bb310550.aspx

You can also add ROman Kiss inproc channel which will blow away anything as there is no serialization cost ... but basically if you have less calls its faster . 1 1k Message is going to be much faster than 20 64  byte messages . This is a key part of SOA (or well designed remoting systems ).

 

 

 

BenK95781 wrote:

In terms of smaller projects WCF bites and will add a lot to the cost .. It is a development time overhead but i often ask should these have been distributed anyway ?

So you're saying that there should never be any such thing as a small-scale distributed application? Wow, what have I been doing all these years?

 

>> I see many small scale systems that are distributed that should not be  :-)  ANY distributed system will cost a fair bit more than a 1/2 Tier system, .

And these days 2 Tiers with SQL notification ( and maybe Service Queues- though i hate it) is a very good solution.  The one exception is systems that MUST be distributed like monitoring systems but how many of these are written in .NET  ( Com+ is common though)  - and with these interop is very important so i would seriously consider WCF/SOA?

And I dont think an SOA/WCF  system will take any longer to develop than a remoting system , probably less.  You create your interface , you create your DTO , auto genate your proxy and thats it nothing else to be done .

 

 

BenK95781 wrote:

If however you are talking lots of small interconnected systems than SOA is ideal. Each is a completely seperate component with no links (except for maybe a lightweight framework)  , if one is behaving badly and many fixes have failed or bugs keep apearing because it was wirtten by a summer student ,you can regenerate it from an interface , rewrite it , re run your tests , release , point an existing service at the new service and all the other systems are unchanged this is very powerfull and really cuts your testing/release cycles.  To Roll back you just point at the old service.  The same applies for testing.

 

I can get everything you just described using an object-based remoting solution, PLUS I don't have to worry about regenerating contracts and DTOs for EVERY SINGLE SERVICE that I want to reuse! How does forcing the extra overhead and bloat of redefining contracts for objects which already exist in shared libraries make SOA "ideal"?

 

BenK95781 wrote:

Looks like the source code for remoting will be released ( with the framework) so im sure some companies will take up  extending remoting in future.

 

Actually, I doubt many will. Its simply not worth the time or the risk to develop your own distributed computing solution when there is already one available, even if it does not match your needs and forces you to jump through unnecessary hoops. So what will probably happen is the vast majority of us will continue to use WCF while wishing that Microsoft would give us a better solution.

 

By the way, it would be easy to read all of the above and come to the conclusion that I hate WCF. Nothing could be further from the truth. I love it. I think it brings a lot of functionality to the table that was impossible or very difficult using remoting, I like the relative ease with which various protocols and behaviors can be configured, and I like its declarative nature (although I often wish that the imperative options were easier to use). And for software which is already a good candidate for SOA, I think WCF is ideal. However, what Trevor and I, and numerous other developers I have seen blogging and commenting on this issue want to get across is this:

 

> Yes this is more an argument about OO design ( and moving objects accross boundaries) vs SOA ( interface first - can use OO or Proceduaral Within services)  rather than remoting/WCF.  All i can say is try it - i was a big sceptic SOA done right is quite nice. SOA is just an evolution  of good remoting distrubuted practices.

 

There are many distributed software solutions which are NOT good candidates for SOA.

 

...and for these solutions, WCF is far from ideal. I wish Microsoft would at the very least acknowledge that, and then either give us a better solution for those situations, or at least tell us that they are not going to.

> I do note they did add the abbility to serilaize into an existing DTO interface or class. So they did listen.

 

Instead, all we hear is "WCF is the perfect solution for all but a few niche distributed software needs", which leaves us with nothing to believe but that they are simply out of touch with a large portion of the developer community, and have left us to fend for ourselves. Which I suppose is exactly what has happened.

 

 

> Im not confinced  80% of these are from people who have FUD ( Fear uncertainty and doubt ) about SOA design due to lack of experience which is not helped by the big end marketing and super fat systems.  Your argument is basically saying microsoft is not supporting distributed OO systems , id say they do support this ( your DTO's can serialize into a shared library) they are just making it more difficult ( few examples) as many people get this wrong.  Ok if you have an exisitng system and want to convert it will be hard but MS have been saying since 2004 that remoting style will die and you should use ES( COM+) .

.

  There are cases where COM+ or remoting is better but give SOA a try with WCF it will surprise  especially in maintenance and the 2nd half of a project .  This is what i do just follow the old remoting best practices and keep it simple and light ( remember instantiating or converting a class is a v cheap process compared to cross process comms)

-  Develop Interface  from use cases first ( design first after conceptual and evolve - before your classes)

- Client treats service  as a data source

- Chunky calls not many methods per services.  The less calls the more maintable your system , the closer it will match your business logic and the faster it will run.

- Services need to be smart and easy to use from the client

- Dont use default bindings use Binary/ and no security.

- And use TDD for your services.

- Use simple types in your messages /DTOs strings/int/bool /DateTime/arrays / other DTO's  ( and no more) . Avoid generics , collections ,enums , interfaces etc. ( Yes you can use some of these but there is no need - avoid it and you wont have any hard bugs/tricks to find)  

- Default value and EmitDefault='false' are your friend if you want small messages.

- When starting create big services with multiple interfaces as you gain confidence split them and increase service to service comms.

- After a while use message such as request and response the WCF Guidance package automatically creates converters to internal or Data objects.  Id start with serializing my DTO's but after 1 or 2 systems swap .

- Converting is quick and simple - dont try to seriialize your objects directly . Convert to a message then serialize this also means your comms is seperated from you BLL/Data so you can easily repalce your comms layer.

 

Learning curve with SOA , Workflow , WCF , WPF  , Cab , Ent library , TDD etc is the  major issue.

 

Regards,

 

Ben

Answer 20

> Yes this is more an argument about OO design ( and moving objects accross boundaries) vs SOA ( interface first - can use OO or Proceduaral Within services)  rather than remoting/WCF.  All i can say is try it - i was a big sceptic SOA done right is quite nice. SOA is just an evolution  of good remoting distrubuted practices.

 

 

This is seriously getting ridiculous. You are saying that it is an issue of OO design of sending objects versus SOA concept of interface first? How so? Where was that brought up anywhere? Have you read the GoF and patterns of good design? Since when do OO programmers not take advantage of interfaces? Since when is the issue about remoting versus WCF?

 

The problem is that OO designers want just that: to send an ISomething via the service and that SOA design mandates that you must PUBLICLY REDFINE, UNDER VERY STRICT STANDARDS  what you want to send (predeclare everything that is already defined in a library) AND that you actually need to declare the actual type on the service itself versus sending an interface type and sending whatever instance that meets the interface definition. WCF should simply concentrate on the idea that the client can have shared assemblies with a service. SOA simply blocks the proper use of interfaces and butchers proper OO design.

 

A person has to be really dumb - and I hate to use such a harsh word -  if they cant understand that no matter what, a library must be developed that contains the objects, business logic, etc. Only an idiot can't figure out that its more efficient to simply copy the library and let the client use it than it is build a library and also meet all the SOA rules where its mandated to publicly declare objects types, xsds, validation rules, exceptions, etcetera. Hmm imagine... its actually faster to build a library and copy it, than build a library and learn all the SOA related rules, and then meet those rules by creating a detailed public definition of the library. Seriously, there is no argument here - none - creating essentially teo versions of the same library is wasteful compared to creating one version; especially when tere is no learning curve without the SOA bloat, and when the SOA requirements are so heavy. SOA is simply waste.

 

 

> Learning curve with SOA , Workflow , WCF , WPF  , Cab , Ent library , TDD etc is the  major issue.

 

Hmmm you say that and also this:

 

> I just think people often make judgement without trying an SOA solution . In many cases it will surprise what is better. When i start questioning these people it turns out they have very little experience actually implementing an SOA solution. SOA matches remoting best practices pretty closely.

 

Well, what does that mean... that if everybody went with the admittedly steep learning curve, that SOA is actually more efficient? I think I covered that.

 

> You dont create these xsd they are auto created , and once you build your library you dont touch them unless the client to server message changes  ( We are talking remoting here - with WCF it is all automatic) . At run time this is not really used except for instantiating a DTO  the cost of which is insignificant compared to serialization, Call the serializer 0.1% less  by sending less and chunkier messages and you will have a far better response.

 

You need to stop confusing remoting versus WCF with OO design versus SOA design... they are not the same issues and not the main point. Our point has been that the focus of WCF is its SOA context versus an OO design context.

 

Honestly, the more one works with SOA, the more it sucks. Where are these armies of third parties that easily migrate? Isn't that the reason to go through all that effort? If you design a library, your developers are the experts that intimately know the library. To add the overbloated fat of SOA with the hypothetical idea that publicly declaring everything about the library is really going to make third parties simply be able to "connect" is a laughable joke. It takes less time to have the developers who designed the library work hand-in-hand with the 3rd party to build a custom solution than it is for the third party to interact solely via the publicly declared SOA interface - on their own as it is impled is possible.

 

There is the myth. The myth is that ease of consumption of a service actually happens with SOA.

 

OO design is solid and everywhere, SOA design is only in bloated, bureaucratic organizations where people, time and resources are wasted in grossly high numbers. The believ they are nmore efficient, but are they? Or... is the reality that some bureaucrats create really dumb rules (like ws standards) that force inefficiency? 

 

I would stake my career, my wages, and my reputation that I alone could outperform a team of ten SOA designers. That I could work with a client, gather their needs (from scratch), design the forms, design the business rules/logic, create the database structure,  create the secure communication channel and have a released fully-functioning distributed application, meeting or exceeding the provided guidelines faster and better than the team of ten.

 

I am positive that SOA overhead is inefficient. I will remind you of kaizen (seeking continous improvement through the targeted elimination of waste).

 

Let me ask you this.  If you take your current SOA application, what database does it use? If I were to ask you to switch the application from using the current database and asked that it support SQL Server 2005, MySQL, and Oracle, what would you have to change?

 

If your answer is anything other than - change the connection string, you don't get effiecient, or designing a solid application that is - database independent. Another concept that gets supported when one seekds the elimination of waste. I would wager a great deal of money that you cannot simply migrate from one database to another. I  would wager that the majority of SOA designs require entirely different libraries to support one datbase versus another and that there actually is substantial - significant - overhead in supporting multiple databases. I can state emphatically that I only need to change one line of ciode - the connection string - and that all other code remains fully intact to supprt all major databases. 

 

Do you have any idea how often organization have sunk enormous costs into a particular database? If you design applications such that your application cannot easily migrate from one database to another,then you are a long ways from efficient. I ask you you to reconsider. If your application cannot change databases easily, it likely doesn't change validation rules or busines logic easily either. When you mention the claim to be at a convention and ask people to raise their hand on what is common practiv=ce, be careful of what convention you attend. Was that the latest SOA convention where you collected such facts?

 

I highlighted databse support efficiency and , of course there is more:  if you define a library and business logic and build code to handle exceptions, and then you redundantly create code to publicly declare what is already created in that library - simply to meet SOA standards, then you dont get efficient in the same context. Something is WRONG when there is redundancy or duplication in code - period.

 

Proper design dictates that code should do one thing and do that one thing well. It also should mean that there are no multple instances or versions of that "one" thing which SOA design mandates and why SOA sucks.

Answer 21

Ben,

 

I appreciate your detailed response. Unfortunately, we still seem to be talking past each other, because very little that you are saying makes sense to me, or even seems to be relevant to the topic at hand. For the record, let me restate what I am arguing for.

 

SOA wants to break everything up into little pieces that exist independently from each other and only communicate using publicly declared interfaces. The theory is that by creating well-defined operational boundaries, independent parties will have a narrow, well-defined window in which to communicate, reducing the potential for miscommunication and making it easier for heterogeneous systems to talk to each other. Which is all fine, as far as it goes.

 

The problem with that philosophy is that not all communication is done between independent parties. For example, I am building a smart-client/server application which has a 3-layer architecture existing on 2 physical tiers. SOA would have me completely separate the two physical tiers from each other, forcing an artificial break in the logical architecture where none should be. SOA wants me to treat the two physical tiers as completely independent; the problem is, they are NOT completely independent! I am building ONE application, that happens to exist on multiple physical tiers, and I need to be able to move data between physical tiers while staying within my logical architecture. There is no good reason why I should introduce the artificial separation that SOA wants to force on me. Remoting will do the job just fine without asking me to butcher my design.

 

Now I will try to answer your specific points that are relevant to that topic:

 

BenK wrote:

They certainly have not tossed out any thing , it is just  they will not continue new development

 

Not continuing new development IS my definition of tossing it out the window

 

BenK wrote:

SOA matches remoting best practices pretty closely.   ...you can still do some remoting style stuff ( the best practices stuff) with  WCF.

 

No, it really doesn't, and no, you really can't. Not in the areas that I care about for the sake of this discussion anyway. What I am talking about is building ONE application that relies on the same code base but happens to exist on multiple physical tiers. That concept doesn't even exist in SOA, whereas remoting has no problem with it. So you can't really say that they match.

 

BenK wrote:

But i did always hate forms...

 

Of course Windows Form have their problems. They can be incredibly frustrating and hard to work with. But if I am building a simple LOB application, I am going to reach for WinForms before WPF, period. WPF adds too much overhead for not enough benefit in simple applications. Much like WCF...

 

BenK wrote:

OO reuse in OO is a myth and is only good within very small teams.

 

Well isn't that convenient, since I have a really small team! And if OO reuse is a myth, then it is a myth from which we benefit greatly on a daily basis.

 

As for your 6 points, I don't think that any of them are at all relevant to this discussion:

 

BenK wrote:

...make a small emergency patch on the client or server and every single piece needs to be redeployed.

 

I'm not sure why you think that. Most of our releases are done to one side or the other. We only have to release to both sides at the same time if the shared code has changed. And if the shared code changes, then we would have to release to both sides regardless of whether we were sharing code or not.

 

BenK wrote:

Proxies do this automatically for you...

 

Remoting proxies do, yes. All SOA proxies do is force you to redefine yet another type that you already had access to but that SOA design won't let you use.

 

BenK wrote:

Clients can see classes from a different point of view...

 

Not exactly sure what you are getting at here.

 

BenK wrote:

Seperation of [roles]...

 

Absolutely there should be separation of roles. That does NOT, however, necessitate completely redefining objects when moving between physical tiers. We have a system where objects stay the same but are "wrapped" in different roles as they move through different layers of the system. It works great...except that WCF won't let us use it.

 

BenK wrote:

...real business logic should be contained on services . Clients should have logic todo with display and some UI validation.

 

In an ideal world where network communication costs nothing, maybe. However, in the real world, network communication takes time, and for many of our clients who are scattered across the globe, round-tripping to a service every time any minor business calculation needs to be performed is not an option. That's why we designed a smart-client which is capable of performing business calculations on the client side when necessary. But that requires reuse of code, which WCF does not want us to do.

 

BenK wrote:

having UI and Business on the same objects gets really [ugly]

 

Of course it does. I never said I had UI interaction code and business logic code in the same object.

 

BenK wrote:

Such objects often automatically created...without the developer realising it...

 

If you are abstracting the network away, yes. Which is why we don't do that. I don't want to use remoting to abstract away the network. I want to use it to reuse types and code across physical tiers. I think I have beaten that to death now.

 

BenK wrote:

It encourages developers to have messages that mymic the OO design ie based on method calls...

 

This is no different - I repeat, NO different - than SOA using proxies. Of course you have to use chunky calls to maximize performance - this is best practice no matter what technology you are using, and therefore once again is not relevant to the discussion.

 

CommonGenius.com wrote:

I have NEVER seen an SOA solution which was faster in practice than a remoting solution, nor do I see any reason from a technological perspective why it should be.

BenK wrote:

I have highlighted why above - basically less client server traffic.

 

But there is no reason why there should be less client-server traffic. Remoting and WCF both use an RPC paradigm, in which a message is sent from client to server which contains the method to be called and a representation of the arguments. WCF has better support for one-way calls, which would reduce traffic, but these are not very common in my experience. You seem to imply that using SOA instead of remoting automatically means that you get less chatty calls, but this simply is not true; it entirely depends on how you use them. And it is just as easy to implement best practices in remoting as it is in SOA.

 

I have already seen that performance comparison by Microsoft, but it is meaningless since it doesn't give enough information about the circumstances of the benchmarks to be validated. It also only used named pipes, and says nothing about using TCP.

 

BenK wrote:

In terms of smaller projects WCF bites and will add a lot to the cost...   And I dont think an SOA/WCF  system will take any longer to develop than a remoting system...

 

I guess you haven't really made up your mind yet. In my experience, WCF takes significantly more time to setup and adds development cost and maintenance overhead versus remoting. The impact of this is felt especially hard in medium to small projects; but Microsoft, rather than acknowledge this, simply continues to praise WCF for how easy it is to setup and use.

 

BenK wrote:

All i can say is try it...

 

I have tried it. I have built several SOA-based systems using WCF, of varying sizes. And like I said, I like WCF in many cases. But in many other cases, it simply is not the best solution. That doesn't mean that it is worthless, or that Microsoft wasted their time developing it; on the contrary, it obviously has great potential. But that doesn't mean it is a silver bullet. And it doesn't mean that Microsoft should pull support for other, equally valid distributed application technologies because they have a new favorite son.

 

BenK wrote:

Your argument is basically saying microsoft is not supporting distributed OO systems , id say they do support this...they are just making it more difficult...as many people get this wrong.

 

If people are getting it wrong, then how does it make sense to make it more difficult?!? Shouldn't they instead concentrate on making it easier to do right? Isn't that common sense? I'm sorry, I guess I just don't understand this.

 

David

Answer 22

Trevor, I think you may have gotten a little off point there. Supporting multiple databases has nothing to do with remoting vs SOA or WCF. I think you are trying to say that people who use SOA are only following the latest trend and are therefore not very good developers, which would manifest itself in not being able to support multiple databases. However, this is not true, for several reasons. SOA can be employed with great effectiveness, when it is the right tool for the job; the argument here is that it is not ALWAYS the right tool for the job. Furthermore, for many applications, being able to support multiple databases simply is not part of the business requirements, and spending extra time and testing effort on making sure that you can support databases that will never be used is not an efficient use of resources.

Answer 23

I am not trying to say that SOA developers are 'bad' developers and I agree that multiple database support is off-track... I used it to highlight a point about efficiency. The real point is efficiency; it is about ease of development, ease of maintenance, and quality of product.

 

There are many people making claims about SOA. The main claim (that I see offered most) is that SOA design results in the most third-party friendly conumption of a service.

 

Of course, many applications do not need to support multiple databases; however, who really can anticipate the future? If you "knew" that you could deploy one framework over another and that one framework was extrememly database dependent and another allowed you to freely design your code with near complete disregard for persistence, what framework would you choose?

 

In relation to the topic, there is a choice of OO design versus SOA design. There, of course, are also forms of hybrids between the two. Ultimately, from my perspective - its about efficiency and simple "smell tests" that most good developers acquire naturally. Is anyone disputing that any code, or any framework, should raise a warning due to a simple "smell test" when a developer finds duplicate and/ or redundant code?

 

Here is another off-topic example to clarify: I still find that most component vendors create form controls primarily supporting validation that is performed on the form itself. They are not at fault - they build what customers ask for and now their support members often recommend such design techniques. Thus, a simple check to validate an email address is likely nothing more than a Regex pattern test. However, developers often place the test directly in each respective form's code. The result is numerous forms with duplicated code splattered everywhere. This practice should fail a "smell test" and a good developer should seek to centralize the validation so that each form doesn't have the code embedded within each form and, instead, should have each form refer to a common validation library.

 

This is what I find with SOA, that there are obvious, in-my-face duplications and redundancies. I must admit that I obsess with refactoring and centralizing because experience has taught me just how much it leads to vast improvements - its very effective and very rewarding. I obsessed with my peristence library (database access) and it paid off in spades. I simply cannot imagine using an framework that isn't database independent. Nor could I use a framework without centralized validation and business logic.

 

So, if I am able to communicate my point at all - it is the redundancy of SOA that stands out and simply fails my "smell test". My experience teaches me that many developers deploying SOA are no longer able to recognize the bureaucracy they are part of; it also teaches me that many do recognize the innefficiencies and they are frustrated with the daunting task of getting anything changed. 

 

SOA demands, more often than not, result in high maintenance and development costs. Most importantly, I do not see the assumed ease in consumption of services by third-parties - except - for very simple services. For example, a service to provide/retrieve credit reports is not - relatively - complex and the SOA requirements can work just fine. If you expand into EDI (electronic document interchange) and the scenarios of sharing purchase orders, invoices, shipping, etc where complex business logic starts to get heavily involved, then SOA becomes a monstrous nightmare. I see both sides of a service in these scenarios expending an exorbanate amount of resources and my trusty friend - kaizen - just screams out that waste is heavily involved. SOA simply fails my "smell test".

 

Of course, this is just one man's opinion - I am just sharing it openly.

 

 

 

 

 

 

Answer 24

I agree with you that "proper" SOA design in an internal system tends to lead to redundant code, and I agree that redundant code is generally a sign of a poorly designed system. That is part of my complaint with SOA in general, and WCF in particular. My other complaint is that SOA forces the shape of data being communicated to be very explicitly declared, which is very useful when communicating between independent systems; but when communicating within a system in which data shapes (i.e. object hierarchies) are shared, it merely imposes an artificial restriction which gets in the way of good design without providing any benefit.

 

I have started a separate thread to address that specific topic (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2884951&SiteID=1), since this one is meandering across several different topics (all of which are worth discussing, but the issue of data shape is that one that most interests me at this point).

Answer 25

I'm a little wary of getting involved in this discussion as I lack any experience with Remoting. I've been skimming the thread as posts have been made as, in general, they are a bit hard to follow. BenK's very worthwhile replies are so poorly formatted that they're hard to decipher. He definitely gets a pass for replying where others have remained silent.

 

TrevorW wrote:

This is what I find with SOA, that there are obvious, in-my-face duplications and redundancies... ...So, if I am able to communicate my point at all - it is the redundancy of SOA that stands out and simply fails my "smell test".

Maybe I missed this in one of your earlier posts, but which redundancies are you referring to?

 

TrevorW wrote:

SOA demands, more often than not, result in high maintenance and development costs. Most importantly, I do not see the assumed ease in consumption of services by third-parties - except - for very simple services.

Not sure I follow these two points. A proper versioning scheme for service and data contracts can help reduce maintenance costs. Allowing the client and service to version independently of each other = lower maintenance costs. I'm not sure if this benefit is exclusive to SOA's.

 

I'm not aware of an easier way to get a Delphi client app to talk to a .Net assembly residing on a remote server than than through WSDL. Proxy generation via WSDL is widely supported in many languages' favorite IDE's, which reduces development time. Proper factoring of service interfaces, data contracts, and messages in general defines what sort of "nightmare" you have on your hands. I may have missed your point on this one.

Answer 26

I provided several links below. I suggest you concentrate on the first link and look for "Tenat 3: Services Share Schema and Contract, Not Class" and "Tenet 4: Service Compatibility Is Based Upon Policy"

 

 

In .Net, the referenced SOA schema and contracts do nothing other than their purpose in relation to Microsoft's SOA architecture. The classes (objects) in some assembly are where the "meat" actually lies - where the business logic resides and must exist somewhere in order for the SOA aspect to be relevant, and SOA assumes what you mention: that a third-party is actually a Delphi application or a Java-based application, or some form of interop is involved and that we must use SOA because some non .Net application may be involved. Again, the assumption with SOA is that the very rigid specifications force compliance, and thus interoperability.

 

My experience differs greatly in relation to WCF. I find that there are far more applications for WCF outside this SOA architecture and I am finding that I have to fight all the effort put forth to make WCF an SOA only library. 

 

The most important scenario I mentioned was a distributed application where there is no interop and there are no third parties involved. WCF is simply used to securely communicate between a service and various distributed clients. In this case, the clients share common .net assemblies with the service and a .Net assembly already exists to define objects and their relationships, validation and business logic. *** There is no need for  WSDL, or XSD , or any of the SOA overhead that are necessary to the contracts that "proper" SOA expects - SOA assumes a dumb, disconnected client. I blieve there are more scenarios for clients that are mutually .net and share assemblies than there are truly interop scenarios. There is no benefit in this case to go through that effort. It is only frustrating. What is most problematic is the decision to force declaring types and not to use the most advantageous aspect of an object-oriented language: the inheritence and abstraction, the ability to refer to a reference type object and not a specific implementation (I.e. interfaces). 

 

I should be able to define a contract such that the method on a contract would allow for something like this (assume we have a service contract to "do something" with an address)

 

ServiceResult ProcessAddress(IAddress address)

 

Notice the interface reference - the refernce type, not implementation! I "should" be able to send ANY object that matches the interface and WCF should allow for the assumption that the client and service share assemblies.

 

This is not directly possible in WCF because of the rigid SOA mentality. I can only send concrete types. Now, there are work-arounds, but, in my opinion, it is simply rediculous and I am simply dumbfounded that nobody seems to get that there are more small to medium sized, even numerous enterprise scale applications that have a need for an SOA-less WCF. In fact for every truly interop, in each of those cases, I would wager that there are more non-interop services than interop actually being managed by the particular developer(s). 

 

Whe there is no true interop and no true third-parties involved, then all that SOA "stuff" is bloated, meaningless, overhead.

 

http://msdn2.microsoft.com/en-us/library/ms954638.aspx

 

http://www.microsoft.com/presspass/press/2006/oct06/10-04PragmaticSOAPR.mspx

 

http://java.sun.com/developer/technicalArticles/WebServices/soa/

 

http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1251630,00.html

 

Answer 27

 

> Yes this is more an argument about OO design ( and moving objects accross boundaries) vs SOA ( interface first - can use OO or Proceduaral Within services)  rather than remoting/WCF.  All i can say is try it - i was a big sceptic SOA done right is quite nice. SOA is just an evolution  of good remoting distrubuted practices.

 

 

This is seriously getting ridiculous. You are saying that it is an issue of OO design of sending objects versus SOA concept of interface first? How so?

 >>  WCF ,  XML in its standform ( and SOA  because ots based on XML ) do not allow inheritance one of the pillars of OO.  Nor does it allow interfaces to be passed in as DTO's , nore genrics.  So its right to say that WCF , XML in its standard form ( and SOA)  does not allow an OO Design to go cross tier.  You can still use OO within the client and server  but WCF ( and its Java equivalents like Axis) makes it difficult to extend this architecture accross the whole app.

 

Where was that brought up anywhere? Have you read the GoF and patterns of good design? Since when do OO programmers not take advantage of interfaces? Since when is the issue about remoting versus WCF?

 

>> Yes.. I have - its not a question on whether OO programmers allow this but what WCF ( and XML dependency ) allows.

 

The problem is that OO designers want just that: to send an ISomething via the service and that SOA design mandates that you must PUBLICLY REDFINE, UNDER VERY STRICT STANDARDS  what you want to send (predeclare everything that is already defined in a library) AND that you actually need to declare the actual type on the service itself versus sending an interface type and sending whatever instance that meets the interface definition. WCF should simply concentrate on the idea that the client can have shared assemblies with a service. 

>> I have mention inanother blog this is based on the limitations of XML/XSD ( and the binary XML format) ,

"SOA simply blocks the proper use of interfaces and butchers proper OO design." - Exactly and OO bloats an SOA design , people have different oppinion etc etc . This is exaclty what im saying WCF is an SOA based technology and you want  / insist on using an architecture model that is not entirely competible with it .  Note OO design is compatible , distributed OO model of sharing a library is not .   How can this not be an argument on SOA ( with OO or procedural) vs OO distributed ?

 

 

 

 

A person has to be really dumb - and I hate to use such a harsh word -  if they cant understand that no matter what, a library must be developed that contains the objects, business logic, etc. Only an idiot can't figure out that its more efficient to simply copy the library and let the client use it than it is build a library and also meet all the SOA rules where its mandated to publicly declare objects types, xsds, validation rules, exceptions, etcetera. Hmm imagine...

 

>> OO create interfaces , factories and concrete DTO. SOA create interface , create DTO  , auto gen proxy and your end to end is working , They are not that different .  I have used both for a long time.

 

 

 its actually faster to build a library and copy it,

>> no real difference here .. Add reference  and you have your proxy .,. No different to copy the dll and add a reference and you dont have those issues with redeploying the dll when the version changes.

 

than build a library and learn all the SOA related rules, and then meet those rules by creating a detailed public definition of the library.

 

>> What rules ? You mean the 3-9 methods ? This is what SOA is good at ...

 

Seriously, there is no argument here - none - creating essentially teo versions of the same library is wasteful compared to creating one version; especially when tere is no learning curve without the SOA bloat, and when the SOA requirements are so heavy. SOA is simply waste.

 

>> This is Totally insignificant compared to a project , not even 1% of the time.  And SOA is not Bloat thats FUD.

 

 

> Learning curve with SOA , Workflow , WCF , WPF  , Cab , Ent library , TDD etc is the  major issue.

 

Hmmm you say that and also this:

 

> I just think people often make judgement without trying an SOA solution . In many cases it will surprise what is better. When i start questioning these people it turns out they have very little experience actually implementing an SOA solution. SOA matches remoting best practices pretty closely.

 

Well, what does that mean... that if everybody went with the admittedly steep learning curve, that SOA is actually more efficient? I think I covered that.

 

>> SOA has very little learning curve . WCF and WPF now they have learning curves.

 

SOmething  is SOA

-if it has services with about 3-9 methods which should map to usecases

- You dont share not framework dll between client and services

- You define a contract consiting of a service interface and some simple DTO's

 

Not exactly rocket science... ok there are a few details like how do define logic into when services talk to each other and how big services are but the basics are enough,  It just doesnt mash well with a strong OO design .

 

> You dont create these xsd they are auto created , and once you build your library you dont touch them unless the client to server message changes  ( We are talking remoting here - with WCF it is all automatic) . At run time this is not really used except for instantiating a DTO  the cost of which is insignificant compared to serialization, Call the serializer 0.1% less  by sending less and chunkier messages and you will have a far better response.

 

You need to stop confusing remoting versus WCF with OO design versus SOA design... they are not the same issues and not the main point. Our point has been that the focus of WCF is its SOA context versus an OO design context.

 

>>  this was responding to the other poster and i was highligting how SOA evolved from remoting best practices, yes SOA  vs Distrubuted OO ..  ( You can use OO within an SOA service or client)

 

Honestly, the more one works with SOA, the more it sucks. Where are these armies of third parties that easily migrate? Isn't that the reason to go through all that effort? If you design a library, your developers are the experts that intimately know the library. To add the overbloated fat of SOA with the hypothetical idea that publicly declaring everything about the library is really going to make third parties simply be able to "connect" is a laughable joke. 

 

>> Not third parties ,,, other development teams witin a company would be a massive win.

 

It takes less time to have the developers who designed the library work hand-in-hand with the 3rd party to build a custom solution than it is for the third party to interact solely via the publicly declared SOA interface - on their own as it is impled is possible.

 

There is the myth. The myth is that ease of consumption of a service actually happens with SOA.

 

OO design is solid and everywhere, SOA design is only in bloated, bureaucratic organizations where people, time and resources are wasted in grossly high numbers. The believ they are nmore efficient, but are they? Or... is the reality that some bureaucrats create really dumb rules (like ws standards) that force inefficiency? 

 

>> I have seen VERY Bloated OO as well. Try interfaces and factories for every object.  All i can say dont comment on SOA until YOU try some small services and an SOA app , i was extremly sceptical and firced into it but im very HAPPY with the results and how easy it is to change and maintain ,  it works well.  Yes some comanies are busy wrapping everything in SOA but this is done so they can respond to business request and reconfigure and build new systems easier. 

 

 

I would stake my career, my wages, and my reputation that I alone could outperform a team of ten SOA designers. That I could work with a client, gather their needs (from scratch), design the forms, design the business rules/logic, create the database structure,  create the secure communication channel and have a released fully-functioning distributed application, meeting or exceeding the provided guidelines faster and better than the team of ten.

 

I am positive that SOA overhead is inefficient. I will remind you of kaizen (seeking continous improvement through the targeted elimination of waste).

 

>> It doesnt need to be - in large organisations it will be as they will create a comitee but they will do the same to any system .   You can do SOA at the small end,

 

>> Not really an appropriate comparison . Ok if i have a <50 user system i know wont change much i often use 2 Tier and just use RAD and this can be very cost effective - it is hard for many OO system to match RAD, For larger systems I use OO in the client and server ( though use WF / Procedural more and more) and SOA to communicate between them .

For a 2 Tier  app with a very complex UI i would use pure OO, Its horses for courses and they all have a place . Try it ..

 

Let me ask you this.  If you take your current SOA application, what database does it use? If I were to ask you to switch the application from using the current database and asked that it support SQL Server 2005, MySQL, and Oracle, what would you have to change?

 

>> I use LINQ now :-) But many systems never need to ake this change . SOme people even put all the data in a seperate SOA service if this is a requirement so if they went to Oracle they can copy the pieces they need rewrite all the SQL to be comaptible with Oracle and then just repoint the n services that use that data to use the new oracle DB , Not very hard.

 

If your answer is anything other than - change the connection string, you don't get effiecient, or designing a solid application that is - database independent. Another concept that gets supported when one seekds the elimination of waste. I would wager a great deal of money that you cannot simply migrate from one database to another. I  would wager that the majority of SOA designs require entirely different libraries to support one datbase versus another and that there actually is substantial - significant - overhead in supporting multiple databases. I can state emphatically that I only need to change one line of ciode - the connection string - and that all other code remains fully intact to supprt all major databases.

 

>> My answer was change the connection string :-)  There is nothing stopping you haveing an OO datamodel within the service supporting this as well. The contract is defined by the DTO and Services interface so adding a nerw DB is just like it is with OO,

 

Do you have any idea how often organization have sunk enormous costs into a particular database? If you design applications such that your application cannot easily migrate from one database to another,then you are a long ways from efficient. I ask you you to reconsider. If your application cannot change databases easily, it likely doesn't change validation rules or busines logic easily either. When you mention the claim to be at a convention and ask people to raise their hand on what is common practiv=ce, be careful of what convention you attend. Was that the latest SOA convention where you collected such facts?

 

I highlighted databse support efficiency and , of course there is more:  if you define a library and business logic and build code to handle exceptions, and then you redundantly create code to publicly declare what is already created in that library - simply to meet SOA standards, then you dont get efficient in the same context. Something is WRONG when there is redundancy or duplication in code - period.

 

Proper design dictates that code should do one thing and do that one thing well. It also should mean that there are no multple instances or versions of that "one" thing which SOA design mandates and why SOA sucks.

 

Huh where does it say that in SOA ?  Ok  in large organisations you may have version 11 and 12 of a services  but i can guarantee you you iwll have less SOA services for a function than you would by bindiung to a library , in many cases you can add functionality / members and because of the XML serialization ( will only fail if a member or operation is renamed or deleted ) old apps can use the new service.

 

Regards,

 

Ben

 

Answer 28

Hi David,

 

I appreciate your detailed response. Unfortunately, we still seem to be talking past each other, because very little that you are saying makes sense to me, or even seems to be relevant to the topic at hand. For the record, let me restate what I am arguing for.

 

> Sorry for the rushed replies..

 

SOA wants to break everything up into little pieces that exist independently from each other and only communicate using publicly declared interfaces.

 

> Note Same as OO when using the everything is defined from an interface...Just the pieces are bigger.

 

The theory is that by creating well-defined operational boundaries, independent parties will have a narrow, well-defined window in which to communicate, reducing the potential for miscommunication and making it easier for heterogeneous systems to talk to each other. Which is all fine, as far as it goes.

 

> Yep - and exactly the same as it is for OO theory.  Note you can send and receive ANY message that subscribes to the interface defined by the data contract  - it doesnt have to be the exact message and you can send different address records. Due to XML limitations it just done differently.

 

The problem with that philosophy is that not all communication is done between independent parties. For example, I am building a smart-client/server application which has a 3-layer architecture existing on 2 physical tiers. SOA would have me completely separate the two physical tiers from each other, forcing an artificial break in the logical architecture where none should be. SOA wants me to treat the two physical tiers as completely independent; the problem is, they are NOT completely independent! I am building ONE application, that happens to exist on multiple physical tiers, and I need to be able to move data between physical tiers while staying within my logical architecture. There is no good reason why I should introduce the artificial separation that SOA wants to force on me. Remoting will do the job just fine without asking me to butcher my design.

 

> For small applications this is correct for Medium applications your Address really has multiple roles such as displaying Address ,handling the business  logic of address and persisting address,  Hence it breaks the responsibility down to layer works quite well , client display  , service = business and data  ( or use seperate data service) . 

 

>I do agree there is a small hole for small distributed apps , but i do these with RAD / 2 Tier or for complex ones as 2 Tier OO Still WCF is so based on SOA = xml  , it is really serializing xml that has the limitations. There are times when i dont get a perfect fit but i can still produce a good soluton.

 

 

 

and

 

Now I will try to answer your specific points that are relevant to that topic:

 

BenK wrote:

They certainly have not tossed out any thing , it is just  they will not continue new development

 

Not continuing new development IS my definition of tossing it out the window

> Then a lot of Java has been tossed out including all there remoting RMI stuff.

 

BenK wrote:

SOA matches remoting best practices pretty closely.   ...you can still do some remoting style stuff ( the best practices stuff) with  WCF.

 

No, it really doesn't, and no, you really can't. Not in the areas that I care about for the sake of this discussion anyway. What I am talking about is building ONE application that relies on the same code base but happens to exist on multiple physical tiers. That concept doesn't even exist in SOA, whereas remoting has no problem with it. So you can't really say that they match.

 

> Note you can have the same DLL in server and client with WCF ( im talking WCF here not SOA ) and  serialize into them on client and server, Its just not best practices but for small systems its ok . This is supported with both the XML serializer and data formatter. What you cant do is use OO techniques like inheritance and interfaces ( for the DTO's) .. For small apps these are of dubious benefit anyway are you realling going to create more than one address for IAddress >?.

 

BenK wrote:

But i did always hate forms...

 

Of course Windows Form have their problems. They can be incredibly frustrating and hard to work with. But if I am building a simple LOB application, I am going to reach for WinForms before WPF, period. WPF adds too much overhead for not enough benefit in simple applications. Much like WCF...

>OT

 

BenK wrote:

OO reuse in OO is a myth and is only good within very small teams.

 

Well isn't that convenient, since I have a really small team! And if OO reuse is a myth, then it is a myth from which we benefit greatly on a daily basis.

 

> It was just sold to companies with big department taht all their teams will now work together ..Like SOA is now. ..

 

As for your 6 points, I don't think that any of them are at all relevant to this discussion:

 

BenK wrote:

...make a small emergency patch on the client or server and every single piece needs to be redeployed.

 

I'm not sure why you think that. Most of our releases are done to one side or the other. We only have to release to both sides at the same time if the shared code has changed. And if the shared code changes, then we would have to release to both sides regardless of whether we were sharing code or not.

 

> Agreed For small apps it is less of a concern.

 

BenK wrote:

Proxies do this automatically for you...

 

Remoting proxies do, yes. All SOA proxies do is force you to redefine yet another type that you already had access to but that SOA design won't let you use.

 

> But using them is trivial and the key thing is it allows a client to talk to a new server with a newer interface withotu changing or recompiling or use someone elses system ( ok again not very usefull for small systems). I would argue they have more of a roll than most interfaces - (yes i only use interfaces if i know something will be reusued or when refactoring)

 

BenK wrote:

Clients can see classes from a different point of view...

 

Not exactly sure what you are getting at here.

 

> In larger apps Customer ,Address , Person etc mean very different things to different parts of the system.

 

BenK wrote:

Seperation of [roles]...

 

Absolutely there should be separation of roles. That does NOT, however, necessitate completely redefining objects when moving between physical tiers. We have a system where objects stay the same but are "wrapped" in different roles as they move through different layers of the system. It works great...except that WCF won't let us use it.

 

> Wrapping or converting is pretty much the same, you can debate the theory but the difference is trivial.

 

BenK wrote:

...real business logic should be contained on services . Clients should have logic todo with display and some UI validation.

 

In an ideal world where network communication costs nothing, maybe. However, in the real world, network communication takes time, and for many of our clients who are scattered across the globe, round-tripping to a service every time any minor business calculation needs to be performed is not an option. That's why we designed a smart-client which is capable of performing business calculations on the client side when necessary. But that requires reuse of code, which WCF does not want us to do.

 

> SOA or WCF services can reside on the client ...This is prob too heavy for small apps but is good practice say if you have options to calculate.

 

BenK wrote:

having UI and Business on the same objects gets really [ugly]

 

Of course it does. I never said I had UI interaction code and business logic code in the same object.

 

BenK wrote:

Such objects often automatically created...without the developer realising it...

 

If you are abstracting the network away, yes. Which is why we don't do that. I don't want to use remoting to abstract away the network. I want to use it to reuse types and code across physical tiers. I think I have beaten that to death now.

 

> And you can do that with WCF ! What you cant do is reuse a certain style of code - eg heavy in abstractions.  If you if you have simple classes methods etc you can serialize directly into that code. This is why this comes down to a debate on WPF not allowing some OO design. You can do it  - just not the way you want.

BenK wrote:

It encourages developers to have messages that mymic the OO design ie based on method calls...

 

This is no different - I repeat, NO different - than SOA using proxies. Of course you have to use chunky calls to maximize performance - this is best practice no matter what technology you are using, and therefore once again is not relevant to the discussion.

 

> Im probably biased here by seeing a few apps where child object collections were iterating to the server without the devs knowing. For good design it is the same but i find remoting solutions tend to mymic classes and have lots of methods while SOA proxies tend to be more chunky. I dont know why but its not because the SOA developers are better. My guess its too much work to have too many contracts.

CommonGenius.com wrote:

I have NEVER seen an SOA solution which was faster in practice than a remoting solution, nor do I see any reason from a technological perspective why it should be.

BenK wrote:

I have highlighted why above - basically less client server traffic.

 

But there is no reason why there should be less client-server traffic. Remoting and WCF both use an RPC paradigm, in which a message is sent from client to server which contains the method to be called and a representation of the arguments. WCF has better support for one-way calls, which would reduce traffic, but these are not very common in my experience. You seem to imply that using SOA instead of remoting automatically means that you get less chatty calls, but this simply is not true; it entirely depends on how you use them. And it is just as easy to implement best practices in remoting as it is in SOA.

 

> Agree on how it is used , but note with traditional distributed object architecture these tend to be chatty . Agree this is now bad practice and it doesnt have to be that way.  I saw a few  SOA implementation that each class as a seperate object ...com+ anyone ?

 

I have already seen that performance comparison by Microsoft, but it is meaningless since it doesn't give enough information about the circumstances of the benchmarks to be validated. It also only used named pipes, and says nothing about using TCP.

 

>Not meaningless just saying remoting and WCF are very similar on TCP and your design and chatiness will be far more important.

 

BenK wrote:

In terms of smaller projects WCF bites and will add a lot to the cost...   And I dont think an SOA/WCF  system will take any longer to develop than a remoting system...

 

I guess you haven't really made up your mind yet. In my experience, WCF takes significantly more time to setup and adds development cost and maintenance overhead versus remoting. The impact of this is felt especially hard in medium to small projects; but Microsoft, rather than acknowledge this, simply continues to praise WCF for how easy it is to setup and use.

 

> I think this is determined very much on the style and architecte of the system. I can say using a very abstract OO architecture WCF is a big pain - if you do a simple OO design with few interfaces no generics then it comes together pretty quick.

 

 

 

 

BenK wrote:

All i can say is try it...

 

I have tried it. I have built several SOA-based systems using WCF, of varying sizes. And like I said, I like WCF in many cases. But in many other cases, it simply is not the best solution. That doesn't mean that it is worthless, or that Microsoft wasted their time developing it; on the contrary, it obviously has great potential. But that doesn't mean it is a silver bullet. And it doesn't mean that Microsoft should pull support for other, equally valid distributed application technologies because they have a new favorite son.

 

> I wouldnt use it for small projects either ( or remoting) unless i had to ... For medium and large i think there are signifcant advantages. If i had to for small apps i would probably favour WCF mainly because im more comfortable with it not having used remoting for 5 years.  Still do you think Remoting deserves support ahead of Vb6 and windows forms ?

 

BenK wrote:

Your argument is basically saying microsoft is not supporting distributed OO systems , id say they do support this...they are just making it more difficult...as many people get this wrong.

 

If people are getting it wrong, then how does it make sense to make it more difficult?!?

 

Shouldn't they instead concentrate on making it easier to do right? Isn't that common sense? I'm sorry, I guess I just don't understand this.

 

> Thats exactly what they are doing ...if you follow the samples etc . If you come from remoting / very abstract OO you will have a lot more trouble but have a look how many samples use this style..If you come frpm a Procedural VB background i think you will find it much easier.

 

> For a small project , try to use a shared OO lib with little abstraction ( interfaces etc , inheritance if you have to with Known Type ( XML needs it ! ) )like we did the old C++ OO  than serialize the server and client directly to those libs . Id be interested to see how hard / easy this is. For a small project the abstraction is of less benefit anyway follow the old second person creates the abstraction rule.

 

> I think this works fine but you dont want to do it .. hence it comes down to the fact you cant serialize heavily abstracted classes . Is that what you really object to .

 

 

Regards,

 

Ben

Answer 29

Hi David,

 

I appreciate your detailed response. Unfortunately, we still seem to be talking past each other, because very little that you are saying makes sense to me, or even seems to be relevant to the topic at hand. For the record, let me restate what I am arguing for.

 

> Sorry for the rushed replies..

 

SOA wants to break everything up into little pieces that exist independently from each other and only communicate using publicly declared interfaces.

 

> Note Same as OO when using the everything is defined from an interface...Just the pieces are bigger.

 

The theory is that by creating well-defined operational boundaries, independent parties will have a narrow, well-defined window in which to communicate, reducing the potential for miscommunication and making it easier for heterogeneous systems to talk to each other. Which is all fine, as far as it goes.

 

> Yep - and exactly the same as it is for OO theory.  Note you can send and receive ANY message that subscribes to the interface defined by the data contract  - it doesnt have to be the exact message and you can send different address records. Due to XML limitations it just done differently.

 

The problem with that philosophy is that not all communication is done between independent parties. For example, I am building a smart-client/server application which has a 3-layer architecture existing on 2 physical tiers. SOA would have me completely separate the two physical tiers from each other, forcing an artificial break in the logical architecture where none should be. SOA wants me to treat the two physical tiers as completely independent; the problem is, they are NOT completely independent! I am building ONE application, that happens to exist on multiple physical tiers, and I need to be able to move data between physical tiers while staying within my logical architecture. There is no good reason why I should introduce the artificial separation that SOA wants to force on me. Remoting will do the job just fine without asking me to butcher my design.

 

> For small applications this is correct for Medium applications your Address really has multiple roles such as displaying Address ,handling the business  logic of address and persisting address,  Hence it breaks the responsibility down to layer works quite well , client display  , service = business and data  ( or use seperate data service) . 

 

>I do agree there is a small hole for small distributed apps , but i do these with RAD / 2 Tier or for complex ones as 2 Tier OO Still WCF is so based on SOA = xml  , it is really serializing xml that has the limitations. There are times when i dont get a perfect fit but i can still produce a good soluton.

 

 

 

and

 

Now I will try to answer your specific points that are relevant to that topic:

 

BenK wrote:

They certainly have not tossed out any thing , it is just  they will not continue new development

 

Not continuing new development IS my definition of tossing it out the window

> Then a lot of Java has been tossed out including all their remoting RMI stuff.

 

BenK wrote:

SOA matches remoting best practices pretty closely.   ...you can still do some remoting style stuff ( the best practices stuff) with  WCF.

 

No, it really doesn't, and no, you really can't. Not in the areas that I care about for the sake of this discussion anyway. What I am talking about is building ONE application that relies on the same code base but happens to exist on multiple physical tiers. That concept doesn't even exist in SOA, whereas remoting has no problem with it. So you can't really say that they match.

 

> Note you can have the same DLL in server and client with WCF ( im talking WCF here not SOA ) and  serialize into them on client and server, Its just not best practices but for small systems its ok . This is supported with both the XML serializer and data formatter. What you cant do is use OO techniques like inheritance and interfaces ( for the DTO's) .. For small apps these are of dubious benefit anyway are you realling going to create more than one address for IAddress >?.

 

BenK wrote:

But i did always hate forms...

 

Of course Windows Form have their problems. They can be incredibly frustrating and hard to work with. But if I am building a simple LOB application, I am going to reach for WinForms before WPF, period. WPF adds too much overhead for not enough benefit in simple applications. Much like WCF...

>OT

 

BenK wrote:

OO reuse in OO is a myth and is only good within very small teams.

 

Well isn't that convenient, since I have a really small team! And if OO reuse is a myth, then it is a myth from which we benefit greatly on a daily basis.

 

> It was just sold to companies with big department taht all their teams will now work together ..Like SOA is now. ..

 

As for your 6 points, I don't think that any of them are at all relevant to this discussion:

 

BenK wrote:

...make a small emergency patch on the client or server and every single piece needs to be redeployed.

 

I'm not sure why you think that. Most of our releases are done to one side or the other. We only have to release to both sides at the same time if the shared code has changed. And if the shared code changes, then we would have to release to both sides regardless of whether we were sharing code or not.

 

> Agreed For small apps it is less of a concern.

 

BenK wrote:

Proxies do this automatically for you...

 

Remoting proxies do, yes. All SOA proxies do is force you to redefine yet another type that you already had access to but that SOA design won't let you use.

 

> But using them is trivial and the key thing is it allows a client to talk to a new server with a newer interface withotu changing or recompiling or use someone elses system ( ok again not very usefull for small systems). I would argue they have more of a roll than most interfaces - (yes i only use interfaces if i know something will be reusued or when refactoring)

 

BenK wrote:

Clients can see classes from a different point of view...

 

Not exactly sure what you are getting at here.

 

> In larger apps Customer ,Address , Person etc mean very different things to different parts of the system , this gets worse as you add mroe designers.

 

BenK wrote:

Seperation of [roles]...

 

Absolutely there should be separation of roles. That does NOT, however, necessitate completely redefining objects when moving between physical tiers. We have a system where objects stay the same but are "wrapped" in different roles as they move through different layers of the system. It works great...except that WCF won't let us use it.

 

> Wrapping or converting is pretty much the same, you can debate the theory but the difference is trivial.

 

BenK wrote:

...real business logic should be contained on services . Clients should have logic todo with display and some UI validation.

 

In an ideal world where network communication costs nothing, maybe. However, in the real world, network communication takes time, and for many of our clients who are scattered across the globe, round-tripping to a service every time any minor business calculation needs to be performed is not an option. That's why we designed a smart-client which is capable of performing business calculations on the client side when necessary. But that requires reuse of code, which WCF does not want us to do.

 

> SOA or WCF services can reside on the client ...This is prob too heavy for small apps but is good practice say if you have options to calculate.

 

BenK wrote:

having UI and Business on the same objects gets really [ugly]

 

Of course it does. I never said I had UI interaction code and business logic code in the same object.

 

BenK wrote:

Such objects often automatically created...without the developer realising it...

 

If you are abstracting the network away, yes. Which is why we don't do that. I don't want to use remoting to abstract away the network. I want to use it to reuse types and code across physical tiers. I think I have beaten that to death now.

 

> And you can do that with WCF ! What you cant do is reuse a certain style of code - eg heavy in abstractions.  If you if you have simple classes methods etc you can serialize directly into that code. This is why this comes down to a debate on WPF not allowing some OO design. You can do it  - just not the way you want.

BenK wrote:

It encourages developers to have messages that mymic the OO design ie based on method calls...

 

This is no different - I repeat, NO different - than SOA using proxies. Of course you have to use chunky calls to maximize performance - this is best practice no matter what technology you are using, and therefore once again is not relevant to the discussion.

 

> Im probably biased here by seeing a few apps where child object collections were iterating to the server without the devs knowing. For good design it is the same but i find remoting solutions tend to mymic classes and have lots of methods while SOA proxies tend to be more chunky. I dont know why but its not because the SOA developers are better. My guess its too much work to have too many contracts.

CommonGenius.com wrote:

I have NEVER seen an SOA solution which was faster in practice than a remoting solution, nor do I see any reason from a technological perspective why it should be.

BenK wrote:

I have highlighted why above - basically less client server traffic.

 

But there is no reason why there should be less client-server traffic. Remoting and WCF both use an RPC paradigm, in which a message is sent from client to server which contains the method to be called and a representation of the arguments. WCF has better support for one-way calls, which would reduce traffic, but these are not very common in my experience. You seem to imply that using SOA instead of remoting automatically means that you get less chatty calls, but this simply is not true; it entirely depends on how you use them. And it is just as easy to implement best practices in remoting as it is in SOA.

 

> Agree on how it is used , but note with traditional distributed object architecture these tend to be chatty . Agree this is now bad practice and it doesnt have to be that way.  I saw a few  SOA implementation that each class as a seperate object ...com+ anyone ?

 

I have already seen that performance comparison by Microsoft, but it is meaningless since it doesn't give enough information about the circumstances of the benchmarks to be validated. It also only used named pipes, and says nothing about using TCP.

 

>Not meaningless just saying remoting and WCF are very similar on TCP and your design and chatiness will be far more important.

 

BenK wrote:

In terms of smaller projects WCF bites and will add a lot to the cost...   And I dont think an SOA/WCF  system will take any longer to develop than a remoting system...

 

I guess you haven't really made up your mind yet.

 

> i certainly have not tried or seen tried many different architecture / tech combinations in this field , the projects are long and what aplies to trivial samples / protypes is often completely different from a real implementation with real changes. RAD beats everything for small projects ( most of my small projects are RAD now), i have done a few RAD front ends to some quick and dirty TDD based procedural services this seems to be pretty good but the jury is out. For larger apps im pretty comfortable with SOA. . 

 In my experience, WCF takes significantly more time to setup and adds development cost and maintenance overhead versus remoting. The impact of this is felt especially hard in medium to small projects; but Microsoft, rather than acknowledge this, simply continues to praise WCF for how easy it is to setup and use.

 

> I think this is determined very much on the style and architecte of the system. I can say using a very abstract OO architecture WCF is a big pain - if you do a simple OO design with few interfaces no generics then it comes together pretty quick.

 

 

 

 

BenK wrote:

All i can say is try it...

 

I have tried it. I have built several SOA-based systems using WCF, of varying sizes. And like I said, I like WCF in many cases. But in many other cases, it simply is not the best solution. That doesn't mean that it is worthless, or that Microsoft wasted their time developing it; on the contrary, it obviously has great potential. But that doesn't mean it is a silver bullet. And it doesn't mean that Microsoft should pull support for other, equally valid distributed application technologies because they have a new favorite son.

 

> I wouldnt use it for small projects either ( or remoting) unless i had to ... For medium and large i think there are signifcant advantages. If i had to for small apps i would probably favour WCF mainly because im more comfortable with it not having used remoting for 5 years.  Still do you think Remoting deserves support ahead of Vb6 and windows forms ?

 

BenK wrote:

Your argument is basically saying microsoft is not supporting distributed OO systems , id say they do support this...they are just making it more difficult...as many people get this wrong.

 

If people are getting it wrong, then how does it make sense to make it more difficult?!?

 

Shouldn't they instead concentrate on making it easier to do right? Isn't that common sense? I'm sorry, I guess I just don't understand this.

 

> Thats exactly what they are doing ...if you follow the samples etc . If you come from remoting / very abstract OO you will have a lot more trouble but have a look how many samples use this style..If you come frpm a Procedural VB background i think you will find it much easier.

 

> For a small project , try to use a shared OO lib with little abstraction ( interfaces etc , inheritance if you have to with Known Type ( XML needs it ! ) )like we did the old C++ OO  than serialize the server and client directly to those libs . Id be interested to see how hard / easy this is. For a small project the abstraction is of less benefit anyway follow the old second person creates the abstraction rule.

 

> I think this works fine but you dont want to do it a certain way .. hence it comes down to the fact you cant serialize heavily abstracted classes . Is that what you really object to ?  The limitation in WCF is really because its based on XML ( as mentioned above in another post) and SOAP ( security layers , addressing etc)  , these technologies cant really handle interfaces and inheritance ( ok there is a MS cludge for inheritance but its pretty ugly on the wire) . In terms of remoting support it would be nice but does it deserve to be ahead of Windows Forms and VB IMHO ..  

 

Regards,

 

Ben

Answer 30

 

Well, Ben I appreciate all your comments, but I sense we are spinning in circles. I have my particular background and you have your particular background. It is very possible that your experience is based on some form of SOA implementation that I really don't get, and it is possible that I might change my opinion if I could really have the opportunity to see the whole view that you have gained from your perspective.

 

However, I am still skeptical.

 

1. I have been working with WCF for some time and I have more than tried SOA techniques - I do not believe that "not trying SOA" is my issue, or that I am just completely ignorant of how - easy - SOA is to implement.

 

2. For me, it is about the limitations SOA puts on sharing objects across boundaries where the asumption is that the client should gain all knowledge about what it can send or receive through the published contract information. It is also about the loss of object hierarchies, and it is also about the profound changes to design that SOA forces well beyoond the object changes. The scenarios where SOA techniques make sense  - IN MY OPINION - are more far MORE RARE than the scenarios of assuming the client has a shared .dll or library.

 

When I create a contract in WCF, - the recommended way - I end up declaring every "known type" and have a very limitied amount of abstraction - really no abstraction - everything is concrete. What this means is that I am forced to create volumes of contracts for every nuance in difference for a potential request. When libraries are shared and SOA rules are tossed-out, it is possible to send/receive nearly, if not all, requests/responses through a single contract - not necessarily my recommnded implementation, but its a huge impact on design and maintenance.  THIS IS CRITICAL - whenever a change is made the non-SOA way, there is rarely an associated change to a contract (from my experience, using my particular OO methods). There simply is no need to ensure that changes to "known types" are maintained because declaring "known types" is retarded when you gaurentee that the client shares the same assembly. IT IS BECAUSE I HAVE TRIED SOA techniques that I complain so loudly. When using SOA techniques, I simply am constantly having to manage WCF. When I toss-out the SOA techniques, I rarely manage WCF changes because the changes I make to my business model are not affecting the contracts. Further - AND CRITICALLY - SOA techniques force changes to the business model itself and these changes are not minor.

• With shared assemblies I am gauranteed that the client and service are on-the-same-page whereas with SOA techniques, I may have "forgotten" to declare a new "known type", or update an XSD, or WSDL... or I may have forgottten to declare a new type of exception that crosses a boundary and not updated the client to react appropriately...
• What happens to business logic using SOA techniques? You gloss over this easily, but practically its HUGE. With shared libraries, the response to errors, to exceptions are all in harmony between the client and server; they are always kept in-sync naturally, with no concentrated effort. Consider the obvious - it is assumed with SOA that a client is a different platform, let alone implements different business logic. With SOA's forced separation, there are forced changes to business logic and what is possible with shared libraries. First, the service must be  - MANUALLY - syncronized. Anyone working with SOA knows that because the client is completely disconnected, there is nothing to ensure the client is actually syncronized with the service. Units tests could "somewhat" ensure proper syncronization, but they are manual,  add compexity if they are only needed for SOA, and can not exist or can be designed improperly where holes in proper syncronization can still slide by. SOA in trying to keep a service and client "in-sync" by forcing public declariation of everything related to the shared contract, by forced separation, simply causes profound negative effects.  
• Can libraries be shared with SOA? ANS: Yes - BUT - not nearly as gracefully and with substantiall added overhead, and most importantly at greatly added complexity. In an OO model (combined with WCF in a custome manner), one method can handle numerous potential objects via the ability to work with a non-concrete type. Using SOA techniques (WCF's intended design), this cannot be done because concrete types must be pre-declared. Further, SOA causes a huge increase in contract definitions and this separating of contract has a direct impact on business logic/design that - in my opionion - has a profoundly negative impact.

 

 

Answer 31

Trevor,

 

Most of your concerns and arguments seem to involve the specific case where both sides of the client/server pair are owned by the same development group, or are at least homogenous with regard to technology. This is not the scenario SOA set out to solve, but as you know it's not precluded by SOA. SOA may indeed not make the most sense in your case. You've been saying that all along and I think BenK agrees with you on that. In mixed development environments where it is not possible or is in fact foolish to distribute libraries containing business logic and/or data types, SOA makes more obvious sense. Even in situations where SOA fits, the cost to rework an existing codebase may be prohibitive - not everyone starts from scratch.

 

I'm sort of a tangential predicament - no Remoting experience, but I am in a situation where my group owns both sides of the client/server piece and our first app will be rather small in scope. We chose WCF over alternatives such as remoting an RemObjects for a variety of reasons, including the de facto deprecation of Remoting and the license costs involved with RemObjects. We had a choice on where to spend the learning curve. Ultimately our department envisions providing an array of enterprise web services to installations in our client sites and eventually the service orientation of our business goals led us quite logically to a service oriented architecture. Suffice it to say I'm only outlining a small percentage of the factors.

 

I'm glad that you've found an amenable workaround for your situation using WCF, and I think it speaks well to WCF's extensibility that you were able to fit the squarish peg in the round hole. If you could be placated by having your solution factored into the WCF as more of a first-class citizen, and if that in turn lessened the initial pain of those migrating from Remoting, then I don't see any reason why not as long as it has a big red flag attached to it that says "Not Interoperable - Does Not Play Well with Others." :-)

 

 

 

Answer 32

Will,

 

You are right that SOA (and by extension WCF) is not targeted at applications which need network communication within the same application, or homogeneous group of applications. The problem is, for those of us who have that need, we have no viable alternative except for deprecated technologies such as remoting. WCF was supposed to "unify" the various distributed application technologies, but what it really did was unify a particular subset of those technologies and leave the rest out. Which is fine! Don't get me wrong, I don't necessarily believe that WCF has to be all things to all people (although it would be nice to be able to combine distributed OO hierarchy with WCF's other features such as configurable channel stacks). My concern is that no one within Microsoft is willing to recognize that WCF is not a sufficient replacement for remoting in the very large set of applications that fall into the category that we have described. They have simply stopped development on remoting, proclaimed that WCF is better, and assumed that everyone who is currently using it will eventually migrate to the "better" WCF.

 

What I want is for someone to wake up and realize that WCF has a huge gaping hole, and that it is unreasonable to deprecate a perfectly valid technology without providing something to replace it which can do what it did. WCF cannot do what remoting did; therefore to call WCF a replacement for remoting is a non sequitur. Either remoting needs to remain a first-class citizen of the MS distributed application technology stack, or remoting-like capabilities need to be first-class citizens in WCF. There is no other reasonable alternative. Even if some want to continue to belittle the distributed OO paradigm as outdated and not interoperable, I think we have adequately demonstrated that there is a time and a place where it makes the most sense, and that time and place is not as rare as many would like to believe.

Answer 33

Did some poking around under the premise that we can't possibly be the only people debating this issue and found an interesting link. Looks like this argument was summarized pretty well in this blog post:

http://weblogs.asp.net/esanchez/archive/2006/03/20/440611.aspx

Answer 34

That is a decent if overly simplified summary of the argument. He seems to imply that the regional directors forum had a pretty lively debate going. Too bad that debate has not spilled out where the rest of us could see it. I have a feeling that most people simply accept WCF as "the new way of doing things" and dont really think about whether it is more appropriate for their scenario (similar to his first post on the subject).

 

You would think if the MS regional directors were split on the issue, it would at least get some attention within MS. But so far, the silence is deafening.

Answer 35

I've been watching this post with interest, and I can't stay quiet any more. Trevor, you are awesome. Try not to hit below the belt, but your passion is commendable. You are the reason I haven't had to post before now -- you are saying what needs to be said. I will say that I am very pleased to see intelligent discourse, and I'm a little discouraged that I haven't seen more discourse from Microsoft itself. As David (CommonGenius) points out, that linked discussion is highly simplified, and "the general silence is deafening." I would now like to call everyone's attention back to the primary topic.

 

Much has been said of SOA and OOP. I won't even enter the discussion because I believe that in every case there is a "right" answer, and it is on a case-by-case basis. The SOA to OOP question is sort of like the OOP programmers asking "abstract base class or interface?" The answer is, it depends on what you are doing, and there's probably only one right answer. I will say that since SOA is newer and less understood, it is more likely to be misused. I will also say that OOP is the right answer most (but not all) of the time.

 

The reason this thread started was that WCF seems to have a hard time addressing the OOP answer. I was never a fan of remoting, and have no trouble believing that WCF uses a far superior serialization and communication mechanism (before WCF, I wrote my own OOP communication mechanisms because remoting wasn't good enough). The problem is (as has been stated), that WCF seems to assiduously eschew any possible use for OOP. Some concrete examples:

 

1. TCP/Named Pipes: the documentation is woefully inadequate, the default bindings are practically useless, and unexplained faults are everywhere. I can point you to a half-dozen examples of this, including some by Lhotka, who seems to generally support SOA but who I trust to make the correct case-by-case decision on most design issues. It seems that if you're not using HTTP, though, you're just not cool. I have to wonder about that. HTTP has been the bane of network communication for a long time. It is being used way outside its original mission, and has no place in software except for those rare B to B cases such as incorporating UPS tracking in your web application or integrating Amazon order processing into your web store. It honestly shouldn't even be being used for the web any more. OK, back to the topic at hand...

 

2. Bindings: in the config file. Why on earth would anyone put binding information in the config file? Well, OK. I can think of a couple of cases. If I put my bindings in my config file, however, I could be sued (the medical industry is a mess -- what can I say?). My application needs to be completely self-contained, or it can't even be approved by the FDA, not to even get into HIPAA compliance. And my application is among the majority, not the minority. So why is there no documentation for code-defined bindings? Why did it take me weeks to figure out the correct binding stack so that I can get to the settings I need? I understand why Microsoft would limit the default outbound connections per channel to only two, but the amount of work required to change that setting in code is simply unacceptable (and that's just one example).

 

3. Exceptions. As Lhotka says, sometimes we want an exception to be thrown in the server and propagated back to the client. I am aware of the security risks, but sometimes this behavior is exactly what is needed. Unfortunately, this is usually impossible. Oh, you can set the "IncludeExceptionDetailInFaults" to true in about three different places (mostly undocumented), but that won't help you. All you'll get is "A fault happened. Turn on your exception details or your trace log. Best of luck." This is pretty useless as the trace log doesn't provide exception details either. I recently spent two days finding a server-side bug which should have taken me two minutes to find, except that I had no exception to go on. I needed that exception!

 

We could debate SOA to OOP until we are blue in the face, but without concrete cases we will just be spinning our wheels. In my (fairly extensive) experience, if more than 10% of software communication cases are implemented in SOA and/or HTTP, then people are doing something wrong. That number is completely off the top of my head, so please don't argue because I know I could be wrong. It could be as high as 30% or as low as 5%. Still, let's not debate the "merits" of one over the other because in most cases, one is right and one is wrong, and both of these philosophies have their place.

 

Instead, let's focus on getting WCF to do what the majority need it to do, because right now it is only serving the minority. Does anyone have any suggestions for addressing some of these anti-OOP problems in WCF?

Answer 36

Sorry in my last post i didnt really get my point accross as there are 2 different posters with different reasons.

 

David ,

 

Is particularly interested in remoting for small projects and MS support of remoting.

 

I think what he wants to do can pretty much be done for small projects

  - Just make a normal old syle OO class library for your business objects  with little abstraction . ( Inheritance is ok but keep it down unless you NEED it )

 - Link the library  on server and client.

 - Dont create the proxy just invoke channel factory of type the interface .

 

This will be pretty good and you can argue that heavy abstraction is a waste on small projects.

 

 

Is it as good as remoting - probably . A fraction less in terms of architecture and software design but a little better in terms of being able to use WCF features and security and for small projects the architecture question shouldnt really matter  .

 

The bit where you suffer is your existing libraries need heavy conversions ( unless wrapped in a pure SOA service - which is not appropriate for some small systems ) or if you have an existing remoting system.

 

Personally i dont think remoting is far enough up the priority list to include feature expansions considering what WCF does . VB , windows forms , VBA easily have far greater need .

 

 

Trevor

 

Is more of an OO pure-ist ( this is not bad in itseself it just clashes heavily with SOA) ,he has a certain architecture already inmind and is not willing to compromise , personally for distributed systems you shoud always compromise and not abstract the network - there are many examples of disasters here and teh Java community is a long way ahead   I think he should experiment with some SOA on a medium project ..  I was of similar views and oppinions until forced by my boss to use it.

 

Regards,

 

Ben

Answer 37

 

Well, Ben I appreciate all your comments, but I sense we are spinning in circles. I have my particular background and you have your particular background. It is very possible that your experience is based on some form of SOA implementation that I really don't get, and it is possible that I might change my opinion if I could really have the opportunity to see the whole view that you have gained from your perspective.

 

> I hope to try...

 

However, I am still skeptical.

 

1. I have been working with WCF for some time and I have more than tried SOA techniques - I do not believe that "not trying SOA" is my issue, or that I am just completely ignorant of how - easy - SOA is to implement.

 

> I used to think i only wanted one copy of a class to have less classes , then i was forced to use SOA and had to use proxy objects.  I now think it increases maintenance as you can copy different classes and stops classes being contemenated by things they shouldnt do.  There are many who use interfaces for every business object but how often is the reuse actualy used here ?

 

 

 

2. For me, it is about the limitations SOA puts on sharing objects across boundaries where the asumption is that the client should gain all knowledge about what it can send or receive through the published contract information.

 

> Not exactly it is similar to an OO interface . The client can send any message with more fields etc as long as it supports the server contract ( interface) .  The designers could have used interfaces to represent these DTO's but then you wuld have had top have concrete objects as well , hence they went down the DTO's with attributes route.

 

 It is also about the loss of object hierarchies, and it is also about the profound changes to design that SOA forces well beyoond the object changes. The scenarios where SOA techniques make sense  - IN MY OPINION - are more far MORE RARE than the scenarios of assuming the client has a shared .dll or library.

 

> that depends on your exposure and whenre you work. WCF ( a SOAP based stack) and SOA are very new  , most organisations are just learning it or blindly following consultants - who create very theoretical systems.

 

 

When I create a contract in WCF, - the recommended way - I end up declaring every "known type"

 

> I hope we are talking SOA here ... Using inheritance ... is already going the non SOA way . There should be no inheritance in SOA. If you use known type its painfull and expensive .   Think of the service as a relational database there is no multi versions Person in a table. 

 

and have a very limitied amount of abstraction - really no abstraction - everything is concrete. What this means is that I am forced to create volumes of contracts for every nuance in difference for a potential request.

 

> How is this different from SQL ? And types can be shared accross contracts.  Like SQL you may have one person object and a person type field rather than have 5different contracts. Its just a different way of doing it  but if you have experience building an SQL db then you have the techniques.

 

When libraries are shared and SOA rules are tossed-out, it is possible to send/receive nearly, if not all, requests/responses through a single contract - not necessarily my recommnded implementation, but its a huge impact on design and maintenance. 

 

 THIS IS CRITICAL - whenever a change is made the non-SOA way, there is rarely an associated change to a contract (from my experience, using my particular OO methods). There simply is no need to ensure that changes to "known types" are maintained because declaring "known types" is retarded when you gaurentee that the client shares the same assembly.

 

> Agreed ...but you dont have to use known type this is an OO concept and contracts shoudl be more relational.

 

 IT IS BECAUSE I HAVE TRIED SOA techniques that I complain so loudly. When using SOA techniques, I simply am constantly having to manage WCF. When I toss-out the SOA techniques, I rarely manage WCF changes because the changes I make to my business model are not affecting the contracts. Further - AND CRITICALLY - SOA techniques force changes to the business model itself and these changes are not minor.

 

> No you are using OO / SOA hybrid and trying to expose your OO hyrachies thats where it gets painfull. Its an impedance mismatch similar to the problem OR mappers have.   Its not that SOA is hard and expensive to maintain its an OO/SOA Hybrid thats hard.  It took me a while to realise this and my services now have very little OO .

• With shared assemblies I am gauranteed that the client and service are on-the-same-page whereas with SOA techniques, I may have "forgotten" to declare a new "known type", or update an XSD, or WSDL... or I may have forgottten to declare a new type of exception that crosses a boundary and not updated the client to react appropriately...

> This only applies to single client/ single service smaller apps. Its a big pain linking multiple team apps.  Again if you stick to SOA rules  you dont have this issue

        - Use simple types ( string instead of enum)

        - Arrays instead of collections ( Ok list is ok as it auto converts)

       - no Knowtype

       - Only use string , int ,datetime , arrays and other datacontracts as  your type.

 

See you are not really using SOA you are using OO and trying to get it to serialize with SOA style contracts.

• What happens to business logic using SOA techniques? You gloss over this easily, but practically its HUGE. With shared libraries, the response to errors, to exceptions are all in harmony between the client and server; they are always kept in-sync naturally, with no concentrated effort. Consider the obvious - it is assumed with SOA that a client is a different platform, let alone implements different business logic. With SOA's forced separation, there are forced changes to business logic and what is possible with shared libraries. First, the service must be  - MANUALLY - syncronized. Anyone working with SOA knows that because the client is completely disconnected, there is nothing to ensure the client is actually syncronized with the service. Units tests could "somewhat" ensure proper syncronization, but they are manual,  add compexity if they are only needed for SOA, and can not exist or can be designed improperly where holes in proper syncronization can still slide by. SOA in trying to keep a service and client "in-sync" by forcing public declariation of everything related to the shared contract, by forced separation, simply causes profound negative effects.  

> Not sure where you getting at but as an example i have often added some new validation in the business logic and the deployed the service because there is an exact contract and it only applied to a certain logic path i can quickly release the new service. No client needs to be redeployed. Similarly  i have added some UI  validation to a client DTO display object and the services didnt need to change and only the type of client that was changed needed to be redployed instead of everything .  For non trivial projects this is a huge win - for smaller projects where you have complete control then there is little difference,.

There are many ways to deal with errors . In general you have UI type validation in the client and BL in the service.

The only way to complete gurantee synchronisation is by hard coding a particular assembly this  is extremely painfull for multiple clients/ teams etc .  SOA uses a contract exaclty the same as an OO interface if  the client doesnt match the contract it complains ( at runtime  though) . Like OO just because a class obeys an interface doesnt mean it behaves correctly and you still need unit test. eg Joe bloe changed your shared assembly and added something you didnt realise in the last release.,

 

• Can libraries be shared with SOA? ANS: Yes - BUT - not nearly as gracefully and with substantiall added overhead, and most importantly at greatly added complexity.

> Only if you need to use inheritance .. If you share a lib and dont do these all you need to do on the client is call the Channelfactory and specify your interface.  Thats it !  And its gracefull - add inheritance and it gets uggly.

> One more difference - you can automatically call an MArshal by Ref object without knowing you need to manually add the code to call the proxy . ( Can be done via lazy loading ) . This is a good thing !

•  
•  In an OO model (combined with WCF in a custome manner), one method can handle numerous potential objects via the ability to work with a non-concrete type. Using SOA techniques (WCF's intended design), this cannot be done because concrete types must be pre-declared. Further, SOA causes a huge increase in contract definitions and this separating of contract has a direct impact on business logic/design that - in my opionion - has a profoundly negative impact.

> Note SQL doesnt allow this either.  The contract increase are because you are using OO with SOA.. Think relational DB  with logic !

 

Regards,

 

Ben

 

Answer 38

I think this is a health thread and a good debate ..

 

I will expand on this a little - I notice this before this list  but a number of people who use OO design and consider SOA as bad are not actually using SOA ( rather OO with SOA  like contracts) .  People from data / procedural backgrounds who sometimes had great trouble grokking OO often find SOA pretty easy . ( Btw i come form C++ / OO but have had quite a few VB people in teams) .

 

Note i dont think SOA is a silver bullet either ... Distrubuted will always be more expensive and has its issues ( remoting and SOA have different ones) .  I do want to highlight mistakes with SOA that give people trouble.

 

Before i do here is a great blog to read from 2005.

 

"Once I got to that point, once I was willing to let go of OO as a notion for distributing services, I was finally able to appreciate what SO meant."

http://blogs.msdn.com/richardt/archive/2005/12/13/503358.aspx

 

Here are the most common SOA serious mistakes i have seen ( and made) - not in order

 

- Using OO abstraction and interfaces at the contract ( including knowntype / inheritance) .  Think DB type structures and contracts refering to row descriptions.  You should have about one data contract per table . ( Im not saying they are the db records - they can be merged/split etc but just like you dont have 3 types of Persons in SQL you dont in your SOA contracts, )

- Too many methods , Having methods like SearchByXXX is bad. Have one methods for all types of searching for that service. If you see Crud messages that is normally bad as well .

 

instead of Crud have

OrderManageResultsMessage ManagerOrders ( ManageOrderMessageRequest messages)

 

- Too many services , especially the one conceptual class = 1 service. Most services should be made of closely related information eg Customer/Contact/Address. Its better to be too big than too small.  Even start with a single service with multiple contracts ,

-  Using parameters ,...Methods should have one paramater and one return type. Eg

 

OrderResultsMessage SearchOrders ( OrderSearchRequestMessage message)

 

more contracts yes .. but it means

   - You will have less methods because its more work  :-)

  -  When you add a paramater the contract does not change for all clients.

 

- Using non basic types ( use basic types ie string, Datetime , int , arrays and Data Contracts ) . CLR types  , collections ,char , long etc all should not be used.

- Using default types , like security .

 

Most of these are a few hours more upfront work but pretty smooth afterwards.

 

Regards,

 

Ben

Answer 39

Ben,

 

I agree that this is intelligent discourse, and I greatly appreciate it. Thank you for that blog post. I can personally relate to the story. I remember that moment myself in the early 90's when I had that "ah ha!" moment with OOP. Coming from assembly and C, I had read some various books on C++ and hadn't really caught on until I read the dirt-simple C++ Primer from Wrox, and then, ah ha! The whole flood of understanding of OOP.

 

In many cases, you are probably right about people's criticizing SOA without truly understanding. I feel that I already had my "ah ha!" moment with SOA, and I agree that it has its place. If a team is working on a generic "XYZ" client and another team is working on the "XYZ" server, and these clients and servers are going to be implemented in unknown or uncontrolled environments (with changing network, security, and platform requirements), there is a very real case for SOA. Let's stay focused on the actual problem, however.

 

Think of SQL Server 2005. Think of the management studio. The server has a greater purpose, of course, but for example's sake we're talking just about the management of the server. This manager should use named pipes (and it does, in this case). This manager should have an "always-on, fully reliable connection" mentality. Nobody could argue otherwise.

 

You said, "When you add a paramater the contract does not change for all clients." Interesting. That means that it is possible to consume the original function while ignoring the new addition to the data contract. Does this sound like the best way to develop a tightly coupled client/server such as the SQL Server Management Studio? Should the developers of the client be allowed to disregard changes to the function arguments?

 

Absolutely not! The client should break. Simply, unequivocally, break. There is such thing as too loosly coupled. Why do you think we use typed datasets? Because haveing arrays of objects is too loosely coupled, and for reasons of performance and business logic, some things must be coupled. SOA wantonly de-couples everything, which is not appropriate in many (if not most) cases.

 

So here's how that applies to the topic at hand. Where is the tight-coupling support in WCF? I don't care about remoting, I'm talking about the assumption that a pipe is reliable and that an exception in the server should trickle down to the client verbatem. In WCF, such assumptions are practically impossible.

 

I think Trevor and I need to start an OOP over WCF foundation to support the 70% or more of us who know how to couple our applications when appropriate. SOA is handled, and WCF does a fine job with SOA when necessary, but Trevor and I can't figure out why the minority is getting such prefferential treatment. Does sombody at Microsoft have an answer, perchance?

 

 

Answer 40

Ben, the issue is nit that SOA does not work for me. I have models based on SOA that work just fine. You, obviously, feel that SOA is efficient.

 

In this case, I am asking for one simple thing:

 

*** I want MS to support WCF in a non-SOA fashion, where the client and Service are assumed to be sharing .NET libraries. ***

 

Is that so aweful to accept? Honestly, there is a great learning curve for SOA, and SOA forces a disconnect because it assumes that client don't even shgare the same operating system, let alone the same exact, mutually-shared, .NET library.

 

You will not sell me that SOA is advantageuous to developers where the client and service are the same application, designed by the same developers. Its simply not.

 

I don't think it helps to assume that I know nothing about SOA and to try and convince me otherwise.

 

I have already worked around the SOA walls tossed in front of me (that made me happy)  and I now have what I am very pleased with - with a few still missing features that SHOULD be supported - like sending an interface type where the concrete type is determined at runtime. I fixed the problem by taking over the serialization process and I simply send byte arrays via WCF. In other words, I send what I want and WCF (like it should in this case) doesn't care what I am sending, it just packages it, protects it, and send it.

 

My model works for me and there are armies of people who want the same thing.

 

The difference is this: those who want to use a SOA model get alll the support in the world (its kinda sad how few use it with so much support - this should be a strong hint). For those of us complaing - at least for me - it is not remoting that I want, I think remoting should die for numerous reasons. It is the ability to assume that WCF is used in scenarios where an application talks to itself. WCF for me is a means to extend an internal application into external boundaries - to distrubute the application to remote clients. The clients are not using various operating systems and using various non .NET libraries (like Delphi): they are KNOWN clients that are KNOWN to be compatible.

 

I do not want to beat this topic up anymore. Either someone at MS can get a clue and realize there is a need as I describe with a very large associate market, or they can ignore the market and ignore a large customer base. I tried SOA; I have been inside numerous SOA-based development centers; I have used SOA-based products.  

 

I don't like SOA, I don't have a need for SOA, and I won't be switching to SOA while it has such obvious redundancy problems. I am not alone.

 

Again, is it really so tough to support the use of WCF in scenarios where the client and service share assemblies: where WCF should allow the free exchange of .NET objects and not enforce the SOA public contract information? It would certainly make a lot of people happy.

 

 

Answer 41

Charles and Trevor have hit the nail on the head. I think we got too far afield in our Remoting vs WCF discussion. I don't really care about remoting per se. What I want is the ability to use the newest and "best" networking technologies available to build my new system. In my case, my system requirements would be served best by a tightly coupled implementation. But WCF makes building a tightly coupled system extremely difficult, and in some cases impossible, for no other reason than the WCF team has decided that everyone should be building loosely coupled systems. This is an arbitrary and unfounded decision, and it shows a disdain for the legions of developers who are carefully considering their development approach instead of jumping on the latest bandwagon. It is far past time for Microsoft to respond to this serious ommission from their sparkling new networking technology.

Ben, your every response has boiled down to one thing: "OO in distributed applications is flawed, try SOA, its better." You have ignored the evidence and examples that Trevor and I have provided that SOA is not beneficial in our scenarios; and you continue to assume that our desire to not use SOA is simply due to ignorance or lack of experience, despite the fact that we have both indicated several times that we have each built SOA systems and appreciate them in appropriate circumstances. The fact that you tried to separate your responses to Trevor and I on the grounds that we have "different reasons" merely reinforces to me that you don't really understand the issues being discussed here. Trevor and I (and Charles, I believe) are arguing essentially the same thing, if from slightly different perspective (and with somewhat different styles). You claim that you "dont think SOA is a silver bullet." Yet every time anyone tries to present evidence as to why a tightly coupled implementation would be better than loosely coupled (via SOA) in a particular situation, your response has been to throw out reasons why SOA is actually better. But most of your reasons are not relevant, and your arguments are not compelling. Based on all of this, I believe the following:

1. You have concluded based on your experience that loosely coupled systems are always better than tightly coupled systems. This is a perfectly valid opinion, but it does not match my experience, and neither you nor anyone else has offered compelling evidence that would cause me to question my experience.
2. You therefore agree with Microsoft's decision to completely ignore tightly coupled systems and attempt to force anyone who uses WCF to implement loosely coupled solutions.
3. There is no point in further debating this with you, since you are not interested in seriously considering any evidence contrary to your conclusions.

As far as trying to remedy the situation, it would theoretically be possible to build a serializer which could handle tightly coupled situations. The NetDataContractSerializer takes a small step by unifying object references, rather than separating them like SOA wants you to. But there would be a lot more work to do. I will take a deeper look into this, but I don't know if I have the time or the range of expertise necessary to do it.

I am also directly contacting some of those on various Microsoft teams related to WCF, in an attempt to elicit responses from them on this issue. I will let you know what if anything they say.

David

Answer 42

 

Hi Charles  et all.

 

"

You said, "When you add a paramater the contract does not change for all clients." Interesting. That means that it is possible to consume the original function while ignoring the new addition to the data contract. Does this sound like the best way to develop a tightly coupled client/server such as the SQL Server Management Studio? Should the developers of the client be allowed to disregard changes to the function arguments?

"

Yes ... For example adding a new search option does not mean all clients now have to support that new search option.

 

Eg

SearchCriteria

   Name

  

 

Now

 

SearchCriteria

Name

Location.

 

This is extending functionality and with good design it should not break -  now if you were to change the logic of the processing than the client would need to do more extensive testing.l

 

If you are adding an operation to the contract than you definelty dont need to change existing clients.

 

This is good practice in remoting using XML files for the criteria ( or xml formatter) but is done much more elgantly these days.

 

Absolutely not! The client should break. Simply, unequivocally, break. There is such thing as too loosly coupled. Why do you think we use typed datasets? Because haveing arrays of objects is too loosely coupled, and for reasons of performance and business logic, some things must be coupled. SOA wantonly de-couples everything, which is not appropriate in many (if not most) cases.

 

> Even in OO it states that if the interface does not change it should not cause other code to change so why recompile somehting that does not change ??. In SOA contract specifies everything you need  - SOA is strongly typed ( the other parites were aguing its to strong ) . If  the service adds a new paramater  say AuthorisingManager  you can specify must have and it will break but i see no reason why clients  need to be rebuilt when they dont use a piece of new functionality. Another good example is a web site consumer for your app wants to make a change this has nothing to do with your code ro release but because they need a new method you are forced to make a new release.  It was for this reason that Remoting was moving towards xml serialziation despite its crappy performance with remoting ( unlike WPF) .

.

> Do you have any idea what its like to manage services  with 4 different simple clients ( still one small - medium application) which may not even be online ;  Just because there is a minor cosmetic bug that one manager insist on being removed for PR reasons. ?  In SOA you can make the change - see its non cirtical , low risk and has no impact hence choose not to alter the contract version , rerun your unit tests and in 5 min you can pass the service to operations to replace at night or lunch if important.  5 min for them to install the service at night and thats it. As opposed to having 60 people screaming because they cant use the system , because the internet or WAN is to slow to download the new client ( or have a whole team in a remote location pre deploying it the night before and then if you have to roll back uninstall from each machine etc) . If something goes wrong you just roll back the service and not every client.

Again i restate you can force clients to update if you want but you are not forced to just because binary serialization requires exact versions.

 

 

> Likewise if functionalitty changes you can choose after testing to not change clients  by leaving the xml namespace si the same of you can force the clients to recompile by changing teh xml namespace ( normally the date) , in this case you would probably leave the old service ( or contract) running and deploy the new one and then gradually update. Note you can force this but you dont have to .. And if you have completed your testing why on earth would you want to redeploy all your clients when the old client works fine ??

 

Note SOA has these options its just we need experience in using it . If we stick to our OO Crutch and implement a distributed OO version of SOA ( including OO over WCF ) we are doomed to compromised solutions which rail agaisnt the designer intensions.

 

 

So here's how that applies to the topic at hand. Where is the tight-coupling support in WCF? I don't care about remoting, I'm talking about the assumption that a pipe is reliable and that an exception in the server should trickle down to the client verbatem. In WCF, such assumptions are practically impossible.

 

>Faultcontracts go to client verbatum.  Again the problem is you want OO behaviour . Fine WCF cant do this and never will.  But you can create solution in SOA which are just as efficient - thats my main argument . Exactly in this thread i can see people using KnownType - thats bad .  

 

I think Trevor and I need to start an OOP over WCF foundation to support the 70% or more of us who know how to couple our applications when appropriate.

 

> Actually i dont think its fundamentally possible , the stack is so based on SOAP you would have to start from scratch  without the SOAP /XML limitations . These are whats causing the problems and things like knowType are MS hacks ..real xml does not have such support. I would start at using REST as the underlying format withmaybe the old serializer over UE64 encioding , or maybe the message filter is worth a try . In either case you will miss most things from the stack , will not be competible with changes and may as well have continued remoting especially with the source being released.

 

SOA is handled, and WCF does a fine job with SOA when necessary, but Trevor and I can't figure out why the minority is getting such prefferential treatment. Does sombody at Microsoft have an answer, perchance?

 

> Distributed OO ( remoting) got pref treatement for many years :-) I argue why ASP.NET has always had such nice controlls and forms didnt  - now we have WPF . Maybe it will again in .NET 4.0 /5.0. These things go in cycles .

 

>But seriously SOA is an evolution of remoting - all the best practices like serializing using XML , not abstractiung away the interface should be used.  Redploying clients nightmare when one service needs a minor bug fix  etc Im writing a small to medium systems single application system with SOA - yes i compromise "OO" best practice but it works damn well.  Better IMHO than dstributed OO  in terms of performance ,reusability and development time ( and i have used both for 4+ years),.Is there as learning curve ? Absolutely ; i see the same mistakes time and time again - especially from OO developers. Still the curve is MUCH lighter than OO that got forced down many developers throats whether they thought it best or not ( I still think RAD 2 Tier blows OO away for small apps) .

 

> In terms of majority .. I think 90% of MS developers are Large company developers who work 9-5 with a VB background who never visist developer forums except to sort out as problem. These are moving from 2 Tier to distributed systems and WCF /SOA  is a very good combination for them and i woudl argue MS is looking after their own and the majority.  ( Note im not a VB or Procedual developer - i write pretty damn good OO code in C++ and C# , buit i understand their plight)

 

> And i still see many apps that are distributed that shoudl be 2 tier. Yes there are exception like a non web based internet reach app but I dont think they are favouring the minorty.

 

 

Regards,

 

Ben

 

 

PS: Give SOA a go , the real way ( forget all that OO design  until after you have the SOA service and treat it just like a DB ( + Procedural BL - process order etc)  , save your OO for non BL libraries and your front end .. Its a nice spanner for your toolkit.  Start with a small-medium app ( not too small) . With experience you may decide its a better solution where before you didnt before and the learning curve is much easier than OO was . .

 

PS: im not saying SOA is always ideal - but it is a lot better than people in this thread point out ( ie using Knowntype means you are digging a hole from the start and implies an OO based design for a SOA system).

 

PS: I am interested in using a share DLL with a few known types ( not many classes) as David wants to do . It might mean i choose SOA/WPF for some smaller systems.  It may work very well , but im not aware of  anyone having tried it  in a real project or samples.

 

Answer 43

 

I think your model/design requirements are so different that you are simply not seeing what I see.

 

I don't want to go through point-by-point what you stated in your post because I don;t think it is necessay.

 

Consider this:

 

When I create a WCF "contract", it is simply a means to communicate (from my view), not a means to enforce protocols.

 

Let me explain with how I WANT things to work...

 

Let's assume I have a simple service to process address changes (its a simple example for a reason).

 

I define an interface:

 

//pseudo code to follow

public interface IAddress {

   string Line1 {get;set}

   string City {get;set}

   string State {get;set}

   string PostalCode {get;set}

}

 

MY SERVICE requires that information (defined in my interface) for the service to work...the basics that it requires. So I define a WCF contract:

 

AddressResponse ProcessAddressRequest(IAddress address);

 

The AddressResponse is the message reponse and ProcessAddressRequest the method - it is not a dual contract (in this case)... the service performs the request and the client waits for the response... it could be a dual binding (fire and forget where a callback is used).

 

Within the code for the service is the validation and if something goes wrong, the response includes the error information, if all went well, it includes the success message. *NOTE- in real-life the client gets a copy of a simple validation library to pre-check data as they enter it within forms.

 

Now, KEY TO MY POINT. is that I want to create a library and within that library may be one, two, three, dozens, or hundreds of objects that implement the IAddress interface. The service should not care which one it receives (or sends)... if it did, it would not declare an interface as an acceptable type.. my example is to sjhow what "should" be possible, at  least within the realm of GOOD OO design.

 

In my case, I create a library with the "business objects" and along with it the definition of shared interfaces. The client and service share these interfaces and they are gauranteed to match... How????, you might ask?

 

Well, the client is deployed via ClickOnce and "phones home" to verify that everything (the shared libraries) are up-to-date with the service. So, how does it work?

 

Well, let me now assume that I need to change the interface to add an adress "Line2", the interface the client uses is now deprecated... it won't work... What happens?

 

First, I use sessions with WCF and when a user (client) logs into the service, the versions are verified and the client login is rejected (with a message) if there is a version mismatch. Second, ClickOnce auto-checks versions for the client and would normally catch a required update before a login attempt anyway.

 

So, in my case, the client can never get out-of-sync with the service!

 

Do you understand?

 

Synchronization and compatiblilty between a client and service do NOT have to be defined by the WCF contract!!

 

let me repeat:

 

Synchronization and compatiblilty between a client and service do NOT have to be defined by the WCF contract!!

 

In my case, synchronization and compatiblilty between a client and service are defined in mutually shared assemblies that are forced to be the same version both via the login process and via ClickOnce. So, now you know, in my scenario there is never a need for cross-functional teams to figure out how to get a client and service in-sync.... they are always forced to be in-sync via other ... more effective means.

 

Does that help make it more clear?

 

Answer 44

 

Charles and Trevor have hit the nail on the head. I think we got too far afield in our Remoting vs WCF discussion. I don't really care about remoting per se. What I want is the ability to use the newest and "best" networking technologies available to build my new system. In my case, my system requirements would be served best by a tightly coupled implementation. But WCF makes building a tightly coupled system extremely difficult, and in some cases impossible, for no other reason than the WCF team has decided that everyone should be building loosely coupled systems. This is an arbitrary and unfounded decision, and it shows a disdain for the legions of developers who are carefully considering their development approach instead of jumping on the latest bandwagon. It is far past time for Microsoft to respond to this serious ommission from their sparkling new networking technology

 

> I dont think its as abritary as that .. Im pretty sure the sytem started out as being a replacement for COM+ and to have SOA support. The SOA support means they build SOAP and xml through the whole stack ?  Every  WCF messasge is XML and parses through  Xml layers/transalators and even the binary/tcp channel is a form of xml.  How do you express inheritance, Generics etc in XML ?   You cant . The only way is to use the old binary serializer and uuencode it to a string.  This is similar to the byte[] Trevor uses and if you have no one else using it i cant see a problem with it. However the binary serializer is responsible for more than its share of disasters in larger companies ( ok ok you only want small /self contained systems)_ \.

 

Ben, your every response has boiled down to one thing: "OO in distributed applications is flawed, try SOA, its better." You have ignored the evidence and examples that Trevor and I have provided that SOA is not beneficial in our scenarios;

 

> Yes my argument is a pure SOA design is as good and better than a distrubuted OO design or the difference is likely to be insignificant . However there are a few cases where this is not the case and i dont think saying statements like WCF doesnt cater for the majority are hence correct. Actually i highlighted that you were not using SOA ...ie Trevors use of KnownType thats just a mistake - it doesnt exist in SOA.. So what you are really doing is trying to do OO in an SOA tool and because it doesnt work nice , you say OO is much better than SOA.

 

> In your case ,not Tervor you  have a point but i clearly stated this case is supported with WCF and if you keep the known types down to a minimum i thnk it will work well ,. After all in a small  app how much change can there be ?? 

 

and you continue to assume that our desire to not use SOA is simply due to ignorance or lack of experience, despite the fact that we have both indicated several times that we have each built SOA systems and appreciate them in appropriate circumstances.

 

> I believe you  ... but how many systems can you have build if you are relying on knowntype ???  This bites ..i learned that in my 2nd SOA project where we used a more OO design ( and even earlier with web services) . And you cant call any system SOA if you are using it . So i do question the SOA design experience - more in Tervors case than yours as you do state there use. And SOA does not fover your solution well withotu the added expense of local services,  However I was puzzled by your comment that you could not share a library in WCF , its not recommended but you can serialize into it , and if you do not have a strong OO design or your OO library has a fascade /DTO's then you can still hapily use it - after all thats what ServiceModel is - OO dll on client and server.  i think not using a little inheritance , interfaces and genrics on a small project is fine ..  If you use inheritance rarely known type wont be that bad, in most cases a lot of classes will never be extended and after all if you add a new type of Busines object you have a pretty major change anyway.

 

> This is a solution that covers your need and i think it will work one. WIll it work with an exsiting library - probably not. However microsoft clearly stated in 2004 that new distributed apps should be based on the Enterprise services model.

 

 

The fact that you tried to separate your responses to Trevor and I on the grounds that we have "different reasons" merely reinforces to me that you don't really understand the issues being discussed here.

 

>Even you argued against Trevor  who is of the oppinion that distributed OO is always better  and SOA cant handle changing DB's .. and like i said if you base your SOA opinion on a solution that uses known type you have a very flawwed view on SOA . This is the main thing i try to get accross ( not just you but many peopel who try to do SOA with a heavy OO background)

 

Trevor and I (and Charles, I believe) are arguing essentially the same thing, if from slightly different perspective (and with somewhat different styles). You claim that you "dont think SOA is a silver bullet." Yet every time anyone tries to present evidence as to why a tightly coupled implementation would be better than loosely coupled (via SOA) in a particular situation, your response has been to throw out reasons why SOA is actually better. But most of your reasons are not relevant, and your arguments are not compelling. Based on all of this, I believe the following:

> SOA has a contract so its about as loose as an OO concrete class using an interface,. Ok its not as tight as the binary serializer or binding but its certainly not as loose as say passing a colelction of strings or a property bag collection.

 

1. You have concluded based on your experience that loosely coupled systems are always better than tightly coupled systems. This is a perfectly valid opinion, but it does not match my experience, and neither you nor anyone else has offered compelling evidence that would cause me to question my experience.

 

> I prefer loosely copupled systems where there is a minimal cost and flexible depolyments... This is where it comes down to ...  and in you original statements both of you stated you believe SOA is more time consuming than a dstiributed system and Tervor specifically uses tthe point you have to keep changing KnownType.  Where as im closer to the view that you put your DB logic in your service - put some Procedural logic in there and there is your service .  For client consume with RAD or OO if you have a complex client.

 

> I also find it strange that people who write OO with a heavy use of interfaces ( Trevors comment fo IAddress) is concenred about loose coupling after all this is another level of indirection... Whereas in my oo solutions i have always used  interfaces only when there is a clear case for reuse or there is a change that requires it and hence use tighter coupling ....

 

> I dont think there is much point trying to work out how the other party thinks ( we are both doing it ) email is not really the best place for this. Personally i dont think its an argument on tight/loose and the benefits but more what style we are comfortable with , im pretty practical and will change my style to suit the tools available rather than debating what is better - those arguments go nowhere and are often dubious - i saw an OO app with perfect ratings in all code reviews , the maintenace devs could not understand it so to get things done they massacred and when the architect /lead left it was much maligned - havent we all seen this ?  Try it as intended  ( and using inheritance with SOA is not trying it IMHO) ,  a year after and some maintenance compare. In my 3 projects it surprised me and i was happier with the results than the 2 remoting ones i did. .

 

2. You therefore agree with Microsoft's decision to completely ignore tightly coupled systems and attempt to force anyone who uses WCF to implement loosely coupled solutions.

> We clash with WPF here as well ( also more loose ) .  I believe it would have been nice to continue some support for remoting ( especially a few needed bug fixes) but i understand financial priorities some of these system cost well over 1000 man years. When your talking ~9 figures for a modern system i can understand they want to have fewer ( 1)  system . I think WIndows Forms , VB6 , VBA are all more deserving than remoting (which does works - you are unlikely to be able to use VBA in future versions of office , even VB6 was not going to be available for Vista at one stage) .

3. There is no point in further debating this with you, since you are not interested in seriously considering any evidence contrary to your conclusions.

 

> I certainly considered your case for  a small app  with internet clients and a shared lib due to comms difficulties. The problem is it means compromising your OO design ? Is this what you really object to ?  For these apps is it really that much harder to support having Address vs IAddress ??

 

> Also everybody acknowledges if you have exisitng distributed apps base don remoting you are caught behind a rock and a hard place, I think MS knew this all allong hence the advise on remoting in 2004/2005.. Remoting apps do NOT map to SOA /WCF and if you try you will get a pretty crapy solutions such as has been mentioned ( lots of contracts , Knowntype etc)

 

> So i do think i do consider problems etc. Its just based on previous experience i see SOA as not having a high cost and the other parties do.

As far as trying to remedy the situation, it would theoretically be possible to build a serializer which could handle tightly coupled situations. The NetDataContractSerializer takes a small step by unifying object references, rather than separating them like SOA wants you to. But there would be a lot more work to do. I will take a deeper look into this, but I don't know if I have the time or the range of expertise necessary to do it.

 

> The bigest gotcha i can see is all the message processing logic expect some sort of XMlSerializer for the body and uses xml for the message headers including action .  This is hacked with REST i think some sort of action is added later based on the URI.  Any serializer would  just wrap the binary serializer grab the byte array and spit that out , the encoder portion would then nead to convert to UUENCODE64 or byte[] depending if xml or tcp.

> Is it worth using a IxmlSerializable ( from a base class for all objects ) and get that to call the binary serializer and spit it out as uuencoded xml string  ?  This will work  but will work best using messages to wrap your inner classes ( as only these need to implement IXMlSerialziable/inherit from the base class) .  When the class is deserialized it will call the same ( you may have to process it  ),

Limitations - no discovery/wsdl/proxies  , use CHannelFactory with the interface as the paramater - ( you can add the scema via Xml serialziation but it will just be a string)

I am also directly contacting some of those on various Microsoft teams related to WCF, in an attempt to elicit responses from them on this issue. I will let you know what if anything they say.

 

> Please , but this was discusses on a lot of MS blogs in 2004-2005. And it is a far hotter question a few years ago in the Java community ( The old RMI/J2EE  to POJO to  Axis /Web services/Rest) . We are just on the tail folloiwing what they do 3 years ago.

 

Regards,

 

Ben

 

PS: Appologies if i get you wrong  Trevor but the SOA comments about the DB and known type were a bit of the mark.,.. and i often hear this extra development cost etc from strong OO advocates who try SOA - SOA does not support inheritance and does not match well to OO design/procedures .. Trying to get it to work like an OO system is what gets you into trouble,  People from RAD/Procedural backgrounds have it much easier ( they struggle a bit with design / contract first) .

 

PSS: David your solution can be handled with local SOA services as well , and one of my coleagues is a big pusher of these however i do agree that the cost of these is often to excessive ( performance and development time) and not suited to small - medium single apps. In a large organisation when you can get these local services to be reused by other teams but not in your case,

 

PSSS: I will give it a rest for now - i have said what i think  and visa versa,

Answer 45

Ben,

This is exactly what I was talking about. You assume that every system has multiple clients of different types that need maximum flexibility. You assume that every application which needs some type of distributed communication fits the model of a client consuming a service. You assume that the reason that those of us commenting in this thread don't want to use SOA is because we don't understand it. Instead of trying to understand our circumstances and considering our arguments, you spout the same "Loose coupling, loose coupling!" mantra that SOA zealots have been trying to cram down the development community for the last few years.

For the record (I have said all of this before, but since you seem to have trouble understanding, I will reiterate one last time):

1. I develop client-server applications which have relatively narrow scope. My company does not have the need, the inclination, or the resources to develop multiple clients for various purposes targeting the same set of functionality. Therefore, we do not receive any significant advantage from creating independent consumable services.

2. When our applications change, it is because our users or our management has dictated that the associated requirements change. Clients are not allowed to upgrade as they choose; they have to upgrade immediately. Therefore, we have no need to support multiple versions of the application in production simultaneously. (Your search example is erroneous. Of course search options are always optional. But there are far more changes that occur in a client/server application that are not optional, especially when those changes are driven by external requirements which are not voluntary. I'm not sure the SSMS example is the most appropriate, but it is at least illustrative, and your attempt to refute it is specious.)

3. I am not looking for distributed OO. Maybe that's where all of your hostility to remoting comes from, but I am fully aware of the problems that it causes. What I am after is the ability to use abstractions that are common to each side of the system without having to explicitly expose those abstractions to whatever communication medium I happen to be using. SOA doesn't want to allow that, because SOA was designed for B2B solutions, where abstractions are by definition specific to one side of the communication context or the other. But I am not building a B2B solution! I just need a method of moving data from 1 physical tier to another WITHIN the context of my application. Why does WCF have such a problem with that? For that matter, why do you?

You continue to claim that we would embrace SOA if we would just make an effort to understand it better. I would submit that it is you who does not truly understand SOA. Understanding a technology is more than just implementing it; understanding it means understanding its origins, its advantages, and its drawbacks. SOA evolved as a mechanism to help simplify the integration of B2B systems; its features are geared toward that purpose. Thus we have the concepts of explicitly declared contracts, non-breaking changes to services, and fault hiding. And they are good concepts when building a B2B system! But they serve no purpose in an internal distributed application. And their drawbacks - such as disallowing the use of shared abstractions - make SOA an inappropriate choice for my circumstances.

The fact that you have such difficulty comprehending this - and your continued use of examples that do not in any way fit the circumstances that have been described to you - tell me that either you are simply not listening, or that you do not have enough experience in an environment such as mine to understand where I am coming from. Either way, I simply don't see how discussing this with you any further serves any purpose.

David

Answer 46

Ben,

I read your most recent post after reading your previous one, and it left me even more flabbergasted. I know I should just drop it, since there clearly is no point, but I just can't let it go yet.

BenK wrote:

SOA support means they build SOAP and xml through the whole stack

No it doesn't. They could have chosen a more neutral representation and converted to XML as necessary. The fact that they chose to base the entire system on XML merely reinforces the fact that they intended all along for WCF to be an SOA-only technology, to the exclusion of all other possibilities.

BenK wrote:

a pure SOA design is as good and better than a distrubuted OO design

I said OO in distributed applications; you said distributed OO. There is a difference, and I think that may be one source of the confusion. Distributed OO is the attempt to "abstact away the network", to move method calls transparently from one tier to another. This has well-known performance problems, and I don't want any part of it. What I am talking about is using OO abstractions within a client/server application, where such abstractions are common to both sides of the system.

BenK wrote:

what you are really doing is trying to do OO in an SOA tool and because it doesnt work nice , you say OO is much better than SOA

No, I never said that. In fact, I have said multiple times that SOA is fine for many situations, and that WCF is a great implementation of SOA. But for the situations where I don't want SOA, when I want a tightly coupled OO system, WCF doesn't fit the bill. Which wouldn't bother me, except for the fact that it is the only distributed technology that will get any attention from Microsoft in the forseeable future.

BenK wrote:

how many systems can you have build if you are relying on knowntype ? if you base your SOA opinion on a solution that uses known type you have a very flawwed view on SOA

Why are you so focused on KnownType? I am talking about building real SOA systems, and again, it went great. Obviously KnownType is a hack, but since Microsoft's new "unifying" distributed technology doesn't support any notion of OO, I have attempted to use KnownType as a workaround. But it doesn't work well at all; not surprising given how extreme the bias toward SOA is in WCF.

BenK wrote:

I was puzzled by your comment that you could not share a library in WCF

I didn't say you can't (and if I did, I misspoke). My problem is that WCF assumes that you won't, and therefore it makes it far more difficult than it has to be. This is a significant barrier in my circumstance.

BenK wrote:

SOA has a contract so its about as loose as an OO concrete class using an interface,.

This is a seriously flawed statement and it reinforces my believe that you don't really understand the issues being discussed here. Interfaces are about "interface contracts", defining the ways in which objects interact with each other. They care nothing about the implementation, or more specifically the data, that is involved in completing that interaction. SOA contracts, on the other hand, require specific definitions of the data involved. This is what makes it so difficult to use OO abstractions in WCF; OO abstractions allow the shape of data to change, WCF contracts don't.

Understand this - I am NOT advocating the use of OO abstractions in SOA. They are two different paradigms, and they don't work well together, nor were they ever intended to. What I want is the ability to use OO abstractions in a supported distributed application technology. The only .NET technology that currently fits that bill is WCF, but it is so heavily focused on SOA that it almost entirely precludes the use of OO. That is what I have a problem with.

BenK wrote:

in you original statements both of you stated you believe SOA is more time consuming than a dstiributed system

...in the internal development environments in which we are operating, yes.

BenK wrote:

put your DB logic in your service - put some Procedural logic in there and there is your service

This is an absurdly simplified view that once again assumes that the application that I am building falls into a typical client/service model. But it is far more complex than that; I am building a client/server application in which the server is far more than simply a wrapper for individual "business logic" operations. The server has a complex OO model of its own which is tightly coupled to that of the client, for good reason. To attempt to separate them simply so that I can turn the server into an independent service broker that fits the SOA model would indeed be quite time consuming and would provide no significant benefit.

BenK wrote:

I think WIndows Forms , VB6 , VBA are all more deserving than remoting

I don't care about remoting itself. What I care about is using the OO abstractions that remoting allowed in a currently supported technology.

BenK wrote:

if you have exisitng distributed apps base don remoting you are caught behind a rock and a hard place

The issue is not maintaining existing apps; they will of course continue to work. The issue is building new applications with perfectly valid OO distributed networking techniques using a supported networking technology.

BenK wrote:

i dont think its an argument on tight/loose and the benefits but more what style we are comfortable with

And this is precisely why you don't really understand the discussion. You think its just a matter of style, and that if we could just broaden our horizons and put aside our OO ways we could make the transition to SOA and then we could use WCF without any problems. You don't understand that its not just a matter of style; that tight and loose coupling really are very different paradigms, with their own advantages and disadvantages that make them suitable to different environments and requirements. You cannot accept that tight coupling really is better given our circumstances and that therefore SOA (and WCF) is not suitable.

David

Answer 47

Ben,

This is exactly what I was talking about. You assume that every system has multiple clients of different types that need maximum flexibility.

 

> No i dont , i use  SOA for apps with single clients and i dont think there is a big differencer to remoting in this model. Its just in bigger applications you get more benefits.

 

> I ask you this why do OO apps loosly couple business objects ( like  Trevors I Address ) . The reason is you NEVER know how your requirements will change . I have seen MANY application that were never to be integrate , suddenly need a 3rd party client for some business deal.  If you have an app that NEVER does this than it is certainly not the majority . 

Even besides this even with one client i dont see SOA as a big overhead if done the SOA not SOA /OO way.  Ok in your case you have an internet app and its too expensive to call the sercvice so you move some business logic local . Fair enough but its not common - most apps you can get the data and post the changes .

 

 You assume that every application which needs some type of distributed communication fits the model of a client consuming a service. You assume that the reason that those of us commenting in this thread don't want to use SOA is because we don't understand it. Instead of trying to understand our circumstances and considering our arguments, you spout the same "Loose coupling, loose coupling!" mantra that SOA zealots have been trying to cram down the development community for the last few years.

 

> No - like i said i dont really care on loose couple of tight coupling . The only exception is i dont want to change all my clients ( even if one app) when the service needs a minor change. This is a function of the BinarySerializaer remoting uses.

For the record (I have said all of this before, but since you seem to have trouble understanding, I will reiterate one last time):

1. I develop client-server applications which have relatively narrow scope. My company does not have the need, the inclination, or the resources to develop multiple clients for various purposes targeting the same set of functionality. Therefore, we do not receive any significant advantage from creating independent consumable services.

 

> Again a judgement that this will take a lot more resources than SOA... This is my main bone of contention.  If it takes less dev resources and runs faster would you still preffer remoting for every case ?

2. When our applications change, it is because our users or our management has dictated that the associated requirements change. Clients are not allowed to upgrade as they choose; they have to upgrade immediately. Therefore, we have no need to support multiple versions of the application in production simultaneously. (Your search example is erroneous.

 

> I have seen many OO become WCF apps where its not.,.. GetAddressByLocation GetAddressByCustomer all mapped directly to SOA methods,  This is where often comments like need hundreds of methods and contracts come from.

 

Of course search options are always optional.

> I have seen many apps that do not , so  ALWAYS optional so thats clearly wrong . 

 

But there are far more changes that occur in a client/server application that are not optional, especially when those changes are driven by external requirements which are not voluntary. I'm not sure the SSMS example is the most appropriate, but it is at least illustrative, and your attempt to refute it is specious.)

 

> Not really there are many examples .. of change thatg shouldnt require a recompile - lets say a constant value , an error message  etc .

3. I am not looking for distributed OO. Maybe that's where all of your hostility to remoting comes from,

 

> David , the threat starter Clearly does .,..you have even stated abstracting the network etc to him is bad. And i agree for your problem its a bad fit but i dont agree that its the most common as i believe most distrubuted development occurs within large companies.  

 

but I am fully aware of the problems that it causes. What I am after is the ability to use abstractions that are common to each side of the system without having to explicitly expose those abstractions to whatever communication medium I happen to be using. SOA doesn't want to allow that, because SOA was designed for B2B solutions,

 

> No SOA was designed for interapp communication and later evolved as away for companies to increase cross team re-use and to help the practiucalities of disributed deployment ( roll outs , upgrading one service without the whole enterprise needing to change) .

 

where abstractions are by definition specific to one side of the communication context or the other. But I am not building a B2B solution! I just need a method of moving data from 1 physical tier to another Within the context of my application. Why does WCF have such a problem with that? For that matter, why do you?

You continue to claim that we would embrace SOA if we would just make an effort to understand it better.

 I would submit that it is you who does not truly understand SOA. Understanding a technology is more than just implementing it; understanding it means understanding its origins, its advantages, and its drawbacks. SOA evolved as a mechanism to help simplify the integration of B2B systems; its features are geared toward that purpose.

 

> It evolved from B2B AND  problems with Distributed solutions like RMI/J2EE  etc and took the best practices from them and avoided some of the disasters these had implementing them within large companies.  Some of the main features  were well used for remoting type solutions ..

 

> I know this i was writing remoting apps from 2000-2004 and saw how they evolved to cover problems and too tight coupling. ,,

 

Thus we have the concepts of explicitly declared contracts, non-breaking changes to services, and fault hiding. And they are good concepts when building a B2B system! But they serve no purpose in an internal distributed application.

 

> In an internal application that never connects to another system.

 

And their drawbacks - such as disallowing the use of shared abstractions - make SOA an inappropriate choice for my circumstances.

 

> In your case i can see that .. ( and have said so)

The fact that you have such difficulty comprehending this - and your continued use of examples that do not in any way fit the circumstances that have been described to you - tell me that either you are simply not listening, or that you do not have enough experience in an environment such as mine to understand where I am coming from. Either way, I simply don't see how discussing this with you any further serves any purpose.

 

> I have experienced it David and i am listening ..but just because i disagree on some key points  doesnt mean your right asnd im worng or visa versa. And its worth beariung in mind the initial messages from the thread that do not apply to your case whihc i was specifically answering.

David

Answer 48

I do not believe the issues I am raising are significantly different from those that Trevor is experiencing, but as the person who started this thread I will let him speak for himself.

If you can see that SOA is not appropriate for my circumstances, then why are you so willing to defend Microsoft for forcing it on me? I can understand that resources are finite (even for MS), that choices have to be made, that they have to support the majority as they see it (though I am not in any way convinced that a majority of people are better off using SOA than OO). But why does it have to be all SOA, all the time? Enforcing contracts is much more difficult than NOT enforcing contracts, so why aren't the contracts optional? Then those who want them could use them, and those who don't, don't have to. It seems like such a small amount of effort for such a huge gain in functionality. Perhaps I am oversimplifying, but simply telling me "you're not in the majority" is not much of a comfort when taking away my best implementation options (not just not providing, but taking away).

Answer 49

David ,

 

 

Take a deep breath and sit on it for a while ( me also) - just because we have different views doesnt mean either one is wrong or write -we should explore the possibilities what the other persons says.  eg im more insterested in your trying to find a work around  - you might come with a nice solution. Have any of you asked how i solved your similar problem ? Or my small single client solutions ?  I think this is a good thread  and shows both sides but we should be able to improve our views.

 

> Yes im a bit patronising at the moment in terms of SOA i see a lot of bad SOA solutions so i need to see the person actually knows / has experience in implementing SOA solutions ( ie more than one) this is much more important than the theory . SOA has some nice practical benefits,   Remember teh theory on COrba ( later COM+) one class one service solution ... Failed in practice , distributed OO the same.  SOA will not live up to the hype im sure - but im happier with my single client SOA solutions that the remoting ones - have any of you asked why ?  Just theory ....

 

Ben,

I read your most recent post after reading your previous one, and it left me even more flabbergasted. I know I should just drop it, since there clearly is no point, but I just can't let it go yet.

BenK wrote:

SOA support means they build SOAP and xml through the whole stack

No it doesn't. They could have chosen a more neutral representation and converted to XML as necessary. The fact that they chose to base the entire system on XML merely reinforces the fact that they intended all along for WCF to be an SOA-only technology, to the exclusion of all other possibilities.

 

> True they could but didnt . I doubt it went this way..  more like

Management : Build me an SOA solution - developers build WCF

3 years later Management : WHy do we have COM+ and remoting  , i only want to pay for one distrubuted solution ? I only want 1 team . Developers after 3 years add support for COM+ and knowntype ( some of these changes like knowntype on interfaces occured quite late in the betas)

BenK wrote:

a pure SOA design is as good and better than a distrubuted OO design

I said OO in distributed applications; you said distributed OO. There is a difference, and I think that may be one source of the confusion. Distributed OO is the attempt to "abstact away the network", to move method calls transparently from one tier to another. This has well-known performance problems, and I don't want any part of it. What I am talking about is using OO abstractions within a client/server application, where such abstractions are common to both sides of the system.

 

> Yes i know you do and some of the earlier posting bled into it . Many people still want to do Distributed OO - we need a more specifi thread for your case ( which i know you started but - the emails were a bit hot here for  me to take it up in a new thread. ) .

BenK wrote:

what you are really doing is trying to do OO in an SOA tool and because it doesnt work nice , you say OO is much better than SOA

No, I never said that. In fact, I have said multiple times that SOA is fine for many situations, and that WCF is a great implementation of SOA. But for the situations where I don't want SOA, when I want a tightly coupled OO system, WCF doesn't fit the bill. Which wouldn't bother me, except for the fact that it is the only distributed technology that will get any attention from Microsoft in the forseeable future.

 

Again leaking from Trevors thread.  Though i still think you can quickly build very efficient small SOA services -we should explore this more .. Something like how do we build a small SOA service app and how will it compare.   It may be better but if it is 95% as good why bother and you have a good tool . I think using SOA for small services is not being done. and has not been thoguht much about .. Things like

- Serialize to same assemble ( not SOA but might be a nice WCF model) - obviously cant use much inheriutance

- Local WCF services or shared assembly

- What is the overhead ( dev time ) of using a shared WCF  vs SOA vs Remoting . If its like within 5% than id argue the choice is irrelevant .  We can add deployment /roll out , developer skills , how the app is mainatained and build management here.  Theory doesnt reaslly cover thsi well,

( Except for using old libaries , build methods , policy etc - SOA bites for these when you start)

BenK wrote:

how many systems can you have build if you are relying on knowntype ? if you base your SOA opinion on a solution that uses known type you have a very flawwed view on SOA

Why are you so focused on KnownType? I am talking about building real SOA systems, and again, it went great. Obviously KnownType is a hack, but since Microsoft's new "unifying" distributed technology doesn't support any notion of OO, I have attempted to use KnownType as a workaround. But it doesn't work well at all; not surprising given how extreme the bias toward SOA is in WCF

 

> Yes any system based on Knowntype is flawed and is an OO /SOA hybriud whcih will give a poor impresion if thats what you think , Again mainly from Trevors commenst about thousands of data contracts , problems with change and known type etc .

.

BenK wrote:

I was puzzled by your comment that you could not share a library in WCF

I didn't say you can't (and if I did, I misspoke). My problem is that WCF assumes that you won't, and therefore it makes it far more difficult than it has to be. This is a significant barrier in my circumstance.

 

> The only obstacle is you cant have a nice OO design but a basic design with no ( or v little) inheritance should work nicely . The only things here would be

    - The limited inherticance.

     -  DataMember Types should be fairly basic ( no generics)

    - Class need datamember /Data contract defintition

    - Dont use proxy but can use ChannelFactory<IMyinterface> to call.

     - Calls back to the service need to be explict but could be lazy loaded.

 

Is this that bad for smaller applications - your hardly going to get a a lot of value out of heavy Abstraction in small to medium apps.  Am i missing something major ?   I would argue that for small apps the loss is about equivalent to the gains ( WCF security , abbility to integrate with other systems if ever needed , WCF channel options like http , deployment)

    

BenK wrote:

SOA has a contract so its about as loose as an OO concrete class using an interface,.

This is a seriously flawed statement and it reinforces my believe that you don't really understand the issues being discussed here. Interfaces are about "interface contracts", defining the ways in which objects interact with each other. They care nothing about the implementation, or more specifically the data, that is involved in completing that interaction. SOA contracts, on the other hand, require specific definitions of the data involved. This is what makes it so difficult to use OO abstractions in WCF; OO abstractions allow the shape of data to change, WCF contracts don't.

 

> OO interfaces are bit more tighter but not going by Trevors comment

 

GetAddress(IAddress)  - How does this OO interface not talk about the data . The Data must comply ( implement IAddress)

 

And this is a form of loose coupling compare with

 

string GetAddressType(string  addresstype)

 

Here there is no indirection and this is tightly coupled ( much more than a WCF contract) , hence they are similar,  

 

WCF contracts allow only minor changes in data shape ( ie you can have a child tree or not  ) . Agreed and i know but OO interfaces ARE a form of loose coupling and its done for the same reasons. Its only a difference fo degrees  compare a concrete rpc style tightly coupled remoting interface ( which is unfortunately too common) ..  ok we learned . and we now use OO interface that are looser - however what is more tight - id say WCF as it specifies the specific shape  - its why OO interfaces are better.

 

>This is what makes it so difficult to use OO abstractions in WCF

 

I think this is where we are getitng crossed - my answer is dont use them or convert to and from them - we have been doing it with dbs for years.

 

 

Understand this - I am NOT advocating the use of OO abstractions in SOA. They are two different paradigms, and they don't work well together, nor were they ever intended to. What I want is the ability to use OO abstractions in a supported distributed application technology. The only .NET technology that currently fits that bill is WCF, but it is so heavily focused on SOA that it almost entirely precludes the use of OO. That is what I have a problem with.

 

> Agree with this 100%. And i think its important. 

BenK wrote:

in you original statements both of you stated you believe SOA is more time consuming than a dstiributed system

...in the internal development environments in which we are operating, yes.

 

> I have never build an SOA system for B2B .. Lets say in your believe a non cross team internal development system? Or would you say an oo distrubuted system is better there as well ?

BenK wrote:

put your DB logic in your service - put some Procedural logic in there and there is your service

This is an absurdly simplified view that once again assumes that the application that I am building falls into a typical client/service model.

 

>Its more on how an SOA app looks  but it provides a good basic point for our readers - all SOA apps should be like this . Note the statement i agree with above "but it is so heavily focused on SOA that it almost entirely precludes the use of OO" . I was saying the same thing here.

 

But it is far more complex than that; I am building a client/server application in which the server is far more than simply a wrapper for individual "business logic" operations. The server has a complex OO model of its own which is tightly coupled to that of the client, for good reason. To attempt to separate them simply so that I can turn the server into an independent service broker that fits the SOA model would indeed be quite time consuming and would provide no significant benefit.

 

> COnverting existing OO distributed systems to SOA and WCF bites ,  Its difficult and requires lots of wrapping, I was under the impression though that you were writing a new app ?

BenK wrote:

I think WIndows Forms , VB6 , VBA are all more deserving than remoting

I don't care about remoting itself. What I care about is using the OO abstractions that remoting allowed in a currently supported technology.

 

> DIfficult due to the nature of WCF see later.

BenK wrote:

if you have exisitng distributed apps base don remoting you are caught behind a rock and a hard place

The issue is not maintaining existing apps; they will of course continue to work. The issue is building new applications with perfectly valid OO distributed networking techniques using a supported networking technology.

 

With new apps you can try SOA.  Using your old techniqies will bite and i would NOT use WCF for this id either go 2 Tier or  go SOA services with the OO being just used for the clients. 

BenK wrote:

i dont think its an argument on tight/loose and the benefits but more what style we are comfortable with

And this is precisely why you don't really understand the discussion. You think its just a matter of style, and that if we could just broaden our horizons and put aside our OO ways we could make the transition to SOA and then we could use WCF without any problems.

 

I did :-) And im happy . I still use heavy OO in some fancy clients i designed and in just about every library/framework  .. but less and less for services , i went through a number of stages but The domain model tends to become anaemic anyway so i dont really bother doing any conversions unless its large service.  .

 

You don't understand that its not just a matter of style; that tight and loose coupling really are very different paradigms, with their own advantages and disadvantages that make them suitable to different environments and requirements. You cannot accept that tight coupling really is better given our circumstances and that therefore SOA (and WCF) is not suitable.

 

You mean looser OO interface coupling :-) A joke..   I know the benefits but  just think the benefits are marginal and there are lots of soft factors that are more important . 

 

The exception argument is *** - its certainly bad form to throw the exact exception to the client and i have some code  i used when starting OO that pulls the exception out and recreates it  by reflection but dont use it anymore.

 

The version argument can be addressed by embedding the build version into the xml namespace ( though id never do this) - when the server changes it will only be linked with a new proxy or shared dll.

 

Really the main difference in terms of loose and tight for new apps are

 

1)  The shaping laws ( due to xml ) mean you cant use a lot of OO  features without a fasacde.

2)  The error exceptions( but if you want you can catch and rethrow in your own proxy  - i have nice one that logs and can spit out teh exceptions )

 

So the loose /tight  comes down to the OO features..which you want to use. Am i missing more  ?  

 

In terms of using a shared assembly you have a valid point but this can also work. based on the above OO limitations.

 

Im think we should let it lie for a while

 

Regards,

 

Ben 
David

Answer 50

Ben,

 

I think it's time to join the discussion or leave it. As the others say, you keep trying to change the facts to support your argument. I am a scientist, and as such, if you were to show me empirically that your way is right, I would change. The problem is, you're not applying your thinking to the situations we are discussing.

 

Remember when I said:

 

>The client should break. Simply, unequivocally, break.

 

And you said:

 

>Even in OO it states that if the interface does not change it should not cause other code to change...

 

That's because in the case I was talking about, we don't want interface behavior. We want directly coupled behavior, where if we add a new piece of criteria, we want the client to be broken until we are processing that new piece of criteria. But you basically came out and told me that you don't understand my example:

 

>Do you have any idea what its like to manage services  with 4 different simple clients ( still one small - medium application) which may not even be online...if you have completed your testing why on earth would you want to redeploy all your clients when the old client works fine ??

 

I have a very good idea, since I've done it, and SOA is perfect for that extremely rare scenario. Why would you use this example when I was asking you about SQL Server Management Studio? Are you saying that the management studio might or might not have a connection to its SQL Server? Are you saying that there are many versions of the management studio?

 

Get back with the example or don't comment on it. You are trying to tell me the benefits of SOA. We don't have anything against SOA. We are trying to figure out how to use WCF in non-SOA situations. Stop providing us wth the SOA situations! We know! We are all (like you I assume) quite competent developers and we know when to use SOA. Get back to SQL Server. Use MY EXAMPLE and talk to me about it. Like I said, you could convince me, but you haven't yet even addressed it.

 

>Faultcontracts go to client verbatum.  Again the problem is you want OO behaviour . Fine WCF cant do this and never will.  But you can create solution in SOA which are just as efficient...

 

Couldn't let this one go. Fault contracts? No. I want exceptions. I want to set IncludeExceptionDetailInFault = true and I want the exceptions to appear on the client end. It works sometimes, and fails most other times. Lhotka found one specific case where it fails miserably, and he agrees that there are cases (SQL Server!!!) where the client needs the actual exception (Primary key violation! Table does not exist! Type mismatch!). We want to know why this is so minimally supported.

 

And yes, we know we have to use ugly hacks to make WCF work properly. Please don't waste your breath making fun of our hacks, because all you do is support our case that Microsoft has made some serious omissions in their communication model.

 

 

Answer 51

I agree, I think we should let it lie for a while and come back to it later.

As food for thought, I will sum up all of my arguments by saying this:

WCF is supposed to be the new "unifying" technology for building distributed applications. However, it approaches the problem of distributed applications from only one direction, that of SOA. In my experience, there is no single direction that is always the right one. We can argue the details of when SOA might or might not be appropriate until we are blue in the face (and in fact we have done just that). But surely we can all agree that there is no single "best" solution for all cases. Therefore, WCF has failed in its primary mission. I want to see it succeed, but for that to happen we must first admit that it has not yet succeeded; and so far I can't get anyone to admit that it has failed so far. That is all I am really trying to do.

David

Answer 52

This has descended into arguments about whether things are tight rather than can we make a good or comparable solution with WCF for small apps ( which i think you can).

 

In terms of loose and tight binding there really is not that much difference ( except as will be noted)

 

Take the ( non SOA example) of.

 

1) Remoting uses auto generated proxies (and in the process abstracts the network boundary away unless you are carefull  . eg you get a network timeout exception which you didnt cater for /retry when you directly linked the server dll without remoting. )

2) Remoting with an xml serializer does not allow any of the OO goodies WCF doesnt allow.

3) After receiving an exception message remoting regenerates and throws the exception from the message.

 

How is this different from WCF where you can link the same dll and use Channelfactory for your proxy and rethrow exceptions if you like  ? ( Ok the one difference is the explicit call to the proxy but this can be handled with the standard OO abstraction - link direct or via a proxy and is a good idea anyway as it avoids abstracting the network)

 

Ok now we change the serializer to binary and we get all the OO goodies , by changing the serializer ( a config file change) we now go from loose to tight  , keh ? When the interface allows more things  ( binary serializer shaping instead of xml) and everything else is the same ???  Or are you saying remoting with the XML serializer is loose but using teh binary serializer and OO is tight ?

 

Remoting was never "tightly bound" it just pretended to be and made this a little bit easier at the cost of many lesser skilled devs abstracting away the network boundary or creating deployment/upgrade nightmares (doesnt apply to David) .

 

This is not about  being more tightly bound ( as its not that different really , though it apears more tight) but more why cant we use ALL the OO goodies in the client to server DTO's. (I still dont know if David is serializing the business objects direct in his distrubuted OO or using Martin Fowler style DTO's .)  And i question the real impact /benefit of this for new code .

 

I do note if you have existing OO remoting not built on the DTO pattern you have a tough choice ( and even if you do you have to strip out some OO enhnacements) . You really have to encapsulate and redesign your client to service comms . If you try to use the exsiting paths and classes (and have lots of inheritance)  you will have a pretty grubby solution which is neither SOA or a distrubuted OO solution. Though i note MS stated in 2004 please move to the Com+ model for future compatability.

 

Regards,

 

Ben  

 

Answer 53

Ben,

Thank you. This is a much more productive post. Now we're away from the OO/SOA discussion and back to the particulars of WCF, which is what this thread was started about. Some comments:

>How is this different from WCF where you can link the same dll and use Channelfactory for your proxy and rethrow exceptions if you like  ?

Rethrow exceptions? We can't even get many types of exceptions. It seems like there should be a basic mechanism for "I can't serialize this particular exception, so I will 'ToString' it and send it along as a generic exception", but that is not what happens. Instead, the exception dissapears forever. Here's one tiny example from Lhotka (but from personal experience, the problem is far more widespread):

http://www.lhotka.net/weblog/WCFNetDataContractSerializerAndSecurityException.aspx

You have now demonstrated our primary concern. WCF can't accomplish many of the tasks we need it to accomplish without ugly hacks and long workarounds.

>Remoting was never "tightly bound" it just pretended to be and made this a little bit easier at the cost of many lesser skilled devs abstracting away the network boundary or creating deployment/upgrade nightmares

Quite true! Even many experienced developers (such as myself) never used remoting because it was not a good solution or a good way of doing things in many respects, and those who did use it either knew exactly what to do to protect themselves or got into trouble. Nobody in this thread has had anything nice to say about remoting (that I've seen). On the other hand, at least remoting gave us some options which are missing from WCF.

Ben, given the points made in this discussion, do you agree that WCF is sincerely lacking in some areas, even if those areas don't typically apply to you? I would feel better if Microsoft could see that even those on the "pro" side can see the problems. I've only been contributing to this forum in an effort to bring these things to Microsoft's attention. From what we've seen of them in the past, they are not totally oblivious, and they tend to create outstanding development tools based on our needs.

Answer 54

Hi guys,

 

Very interesting thread. Thanks a lot!

 

My experience is from the BizTalk side. It's interesting that we have similar issues.
For example, using contracts in the current formats tends to be rigid. What I need in the many cases from the data/message contracts is "use this XML structures form the data I care for and, please, please, do not validate other parts of the data/messages. I don't care if there are errors in those parts, if those parts have the right format, etc. I just don't care."
 But the current XML format tends to force using the strict contracts.
From the versioning perspective it means I could not easily expand the current message contracts in the future versions. The client is forced to recognize the different formats and generate errors when it get slightly different format.
Form the OO perspective it means the client could not easily extract the parts of the message that client cares about and just ignore other parts.
From the integration perspective it means to transfer the message format problems/errors to the client side if this is safe. In many cases these errors belongs to the business-rule layer, the transmitting layer mustn't work with these errors.

 

My understanding is the roots of the problem are in the XML standard. It does NOT have good ability to describe the "undefined" parts of the document/message. With the "right" XML the WCF could possibly (and easily) solve several issues discussed in this thread.

 

Answer 55

Hi!

Wow, what an interesting thread! I really needed this wakeup call!

Our team is currently doing remoting and we have a complex domain model with 3 to 4 levels of inheritance, lot's of interfaces and general good OO design with high reuse. The domain model contain almost all business logic and we are quite happy with it. Of course the domain model dlls are reused on both client and server (no DTO anti-pattern). For presentation we either bind directly to domain instances when possible or use the wrapper or mapper patterns if more information is needed for the GUI. This is according to best practices in these books:
- http://www.informit.com/store/product.aspx?isbn=0321268202
- http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215

I was under the impression that WCF was going to make life for people who did remoting easy, I'm really glad that I found out this early that our case isn't supported out of the box. We do not really need SOA, we control all our services and they are only consumed by our client (winform) apps. But we still need to transmit data though....

Answer 56

Hi!

With .NET 3.5 SP1 out a couple of days ago I see that a new serializer for WCF has been released, the DataContractSerializer. It enables serialization of types without mapping them with DataContract and DataMember attributes. Although supporting this it appears that serialization of private fields and properties is not supported:
http://www.pluralsight.com/community/blogs/aaron/archive/2008/05/13/50934.aspx

For me this is not very good, as I've got a lot of state in private fields that should make it across the network boundary, this means that I may still be stuck on the BinaryFormatter.

Answer 57

 

Steinar D,

 

DataContractSerializer is the same serializer that has always been the default in WCF. All of the current behavior regarding DataContract and DataMember is exactly the same. The only thing that has changed is the behavior when serializing objects which do not have the DataContract and DataMember attributes, in which case the public properties of the object are used. If you need to control the way types are serialized, you can implement ISerializable, which has always worked with DataContractSerializer.

 

Answer 58

Hi!

Thanks for clearing that up for me. I do agree that this is progress but it is still inconvenient to implement ISerializable for all my domain classes (We are considering to upgrade to WCF in October, but do not want to spend time implementing low-level serialization specification for something that works out of the box with remoting. That is wasting the time of our customers which are screaming after new features....

Hopefully I can use the NetDataContractSerializer instead, do you have any experience with that one?

Cheers,
Steinar.

Answer 59

Hi!

I've spent some time on researching how I can use WCF in a similar manner as we use .Net Remoting. Finally I've found the Generic.Remoting project that enables serializing of private fields and properties as well. I've been playing with it for a while and it looks really promising. If you have time, check it out  at: http://slagd.com/?page_id=16

---

Steinar