I have a problem which would normally be simple to solve (DCOM C++) but is causing me grief when attempting an implementation with .NET, C# and Remoting).
Simply put I have a service (or just a console host) which scans some sensors and stores the data in a singleton object (based on the example in the Microsoft Enterprise Solution Patterns document - I have tried them all). I am attempting to use the same service (console) to host a .NET remote interface which provides application access to this data. Note I am not attempting to remote the singleton I just wan't to access it from both the internal threads and the runtime remoting thread hosting the remote method call. Multiple internal threads can synchronise with and access the singleton normally, however the remote access SingleCall methods do not 'see' the same singleton. The runtime appears to create a new instance of the singleton (new static data) on first access (I can see the contructor being called). The remote object method instance and the internal service threads appear to be executing within the same AppDomain. Is this an impossible solution? Is there something else I should know about (Contexts maybe). This must be a fairly common thing to want to do say implementing an in memory global sesion cache for instance. Thanks in advance. Norman Burkies System Engineer High Integrity Solutions Ltd 7 Romsey Industrial Estate Great Bridge Road Romsey, Hampshire SO51 0HR United Kingdom Tel: +44 1794 525622 (Direct) +44 1794 525610 (Switchboard) Fax: +44 1794 525611 email: [EMAIL PROTECTED] IMPORTANT NOTICE: Information contained in this correspondence is proprietary to High Integrity Solutions, Ltd. (HIS). This information is intended only for the recipient. By reading and retaining this correspondence, recipient agrees to hold the information in confidence and shall not use the information for other than the intent stated or implied in the correspondence. This information shall not be copied or otherwise distributed to others without the express and prior written permission of HIS. Unauthorized disclosure could cause irrecoverable commercial harm to HIS. Transmission of this information is in commercial confidence and does not provide a right to use to any party. -----Original Message----- From: Frans Bouma [mailto:[EMAIL PROTECTED] Sent: 10 February 2004 15:08 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Microsoft's future plans for Component Services and ORM [...] > Now, to clarify my disdain for Web Services and claim that > they are inefficient. You said it yourself when you said, > "...I fill a dataset and serialize it to the outgoing XML > Data Stream". There is the single greatest problem with Web > Services, IMO. XML. I'm sure you are aware of what a CPU hog > it is to turn binary data into an XML text representation. > Not only do you turn a few bytes of binary into many bytes of > text, but you also add (by my experience) somewhere in the > neighborhood of 80-90% overhead for tags. Also, you now have > to parse back through that fat block of text to make binary > sense of it once again. Now, given an existing binary data > structure, why in the world would I work the hell out of my > servers' CPUs to turn this into XML? > Why would I not utilize the binary serialization built into > the CLR and just write a custom dispatcher? That's exactly > what we do now. > We have a custom dispatcher that deserializes the > binary-serialized parameters and passes them into the > specified business object. The dispatcher is very simple > and, once written, works everywhere. I read this with a big smile on my face. It's exactly how I look at the current implementation of webservices (which are nice idea nonentheless, just not suitable for a lot of situations). XML is great if you want interoperability between different type of systems since it defines a general format for ascii based data which was in the old days placed in text files in directories. However if you just have an application sitting on 2 1U boxes in the same 19" rack, why on earth would you set up the communication between the processes on both boxes via xml? No-one wants SqlServer's TDS to be replaced by XML for the same reason :) Besides that, webservices in .NET are set up really bad. Here's an example why I think that. Consider an object which is serializable to XML using the SOAP formatter. However this is not what's going to happen if you return such an object from a [WebMethod] marked method. Instead, the XmlSerializer is first serializing the object to XML. This is done using an utterly slow, FILE based approach. The XML constructed by XmlSerializer is then serialized into SOAP. Do you want that? I don't think a lot of webservice using people want that. A lot just want to connect to the .NET webservice from their .NET client and choose webservices over remoting because VS.NET makes it so 'easy' to develop a webservice. Now, if a webservice just would skip the XmlSerializer alltogether and just would serialize the object into SOAP using the SOAP formatter, IF you for example define that with a setting, it would already be a lot better. However, now, the XmlSerializer is severily broken (no cyclic references, no interface based member parameters etc.) and implementing IXmlSerializable is not going to help due to hardcoded codepaths in the XmlSerializer. But it would be even better if VS.NET would have the same support for raw remoting as it has for webservices. Then I think a lot of people would opt for remoting over webservices, however now remoting is something which seems to be 'low level' or 'too difficult', while it would be the better choice for developers in a lot of situations. > This is all just my view, of course. I see advantages to Web > Services and XML, but I really think we need to think about > appropriate application of these technologies rather than to > jump on the bandwagon. IMO, the only problem Web Services > solves is to provide a communication mechanism between > disparate platforms. If you don't have disparate platforms > communicating with your business components, > *don't* use Web Services because all you're doing is > introducing profitless overhead. Same goes for XML in my > view. All too many developers these days are just throwing > Web Services and XML into their apps and blindly believing > that they are solving problems. indeed. In fact, throwing in XML can create more problems due to the often horrible code you have to write to interpret XML constructs or when you write xml constructs. Example: the code to add a node like this: <myNode attrib1="some value" attrib2="someothervalue">lalala</myNode> is very complex and very unusual. (create a node with a doc, however this doesn't add the node to the doc, which requires yet another call etc.) > I'm aware that MS touts Web Services as the next cure for > world hunger. I'm well aware that they would have us move > our middle tiers completely to Web Services. Respectfully, I > think they're wrong. the concept itself isn't wrong though. In fact, if you look at the n-tier idea, an abstract definition for a tier which in fact provides a service to the tier(s) on top of it, is realizable with a webservice. Or better: via a 'service' somewhere on a reachable server. Now, this 'service' can be implemented in various ways, and the only one which gets a lot of airtime (and the proper tools unfortunately) is the webservice. Which is of course sad. FB =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
