Re: Custom Serializable Objects

I think you are taking my comments too literally. The idea behind creating
my own custom objects which are for all intensive purposes an Interface
which adheres to a particular XML schema (xsd) is completely independent of
the underlying framework. As long as the object that the user sends in to
the WS matches up to the XML schema called Contract, it doesn't matter if
they use Java, perl, etc... It's all about the XML structure of the object.
As for creating the WSDL file by hand, that is just crazy talk, esp with the
IDE so happy to auto generate and overwrite any custom code you have written
every time you go to build in the IDE. There has got to be a way for WSDL
to automatically create the same custom object for the simple fact that they
do for DataSets. As for the remoting, I know what remoting is capable of
I've already written multiple pieces of code in remoting. Remoting is not
part of the scope of this project, it's Webservices just like in the name of
the newsgroup.

"John Saunders" <john.saunders at trizetto.com> wrote in message
news:%230zEoZTzGHA.3656@xxxxxxxxxxxxxxxxxxxxxxx
(Comments inline)

"Techno_Dex" <nospamchurst@xxxxxxxxxxxx> wrote in message
news:%23HL5nxRzGHA.3424@xxxxxxxxxxxxxxxxxxxxxxx
I'm looking for a WebService solution. We have looked into Remoting but
it won't meet the long term needs and goals. Not to mension the fact the
WCF is aimed in the Webservice direction. The functionality in question
is being used across a WAN with all probability of opening it up to 3rd
party vendors to access also.

Will these 3rd party vendors all be using .NET?

The objects that I am passing are XML Serializable but they can
handle/contain complex structures (i.e nesting and collection type
structures of other XML Serializable objects). The whole idea behind WS
is to serialize data and pass it across the wire to be deserialized on
the other end.

I strongly disagree with that statement. Web Services is about
communicating over the Internet using XML, in order to abstract away the
particulars of the type and object systems of any particular platform. The
idea is that it should be possible for your client to be written in C#, or
Perl, or something not yet invented.

You seem to want to use web services, but to tie it to the .NET platform.
Oh, and BTW, have you considered the versioning issues if you're going to
share the same assemblies between your clients and server?

My question is pertaining to the fact that when I create my custom XML
Serializable object to either pass into a WS as a Param or return from a
WS, the WSDL generated code create's it own version of the object instead
of using the schema that I have specified. Say I have created a custom
object "Acme.BizObjects.Contract oContract". When I call the WS, I want
to be able to make the call "oWS.AddContract(oContract)" instead of
making the call "oWS.AddContract(oWSContract)" where oWSContract is of
type Acme.BizObjects.WS.Contract created by WSDL.


See, that's where you're mistaken about this. Acme.BizObjects.Contract is
a type that you've created. You want .NET to look at your WSDL (which I
hope you created by hand, and didn't rely on .NET to create), and to
produce the same exact type. That's not going to happen, except by luck.
If you want to use the same type, you need to be using Remoting.

Even there, the suggestion is to use interfaces to define the contract
between the client and server, and to expose the interface to your
customers, and not the type implementing the interface. This is
effectively what you're doing with Web Services, though the WSDL is then
the contract.

.NET Remoting works well for using an interface as the contract. And, I've
probably already mentioned to you that .NET Remoting can use SOAP over
HTTP.

John




.

Relevant Pages

  • Re: Custom Serializable Objects
    ... I'm looking for a WebService solution. ... We have looked into Remoting but it ... custom object "Acme.BizObjects.Contract oContract". ... Acme.BizObjects.WS.Contract created by WSDL. ...
    (microsoft.public.dotnet.framework.webservices)
  • Re: Return argument has an invalid type - does remoting work reliably at all?
    ... interface back to the client as .NET Remoting will try to create it (not ... BUT I doubt it will allow you to cast it to the interface in your DLL. ... Activate an interface but that is different than remoting an interface. ... > .Net Remoting is really a pain to work with for me. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Best of breed PDM
    ... good SolidWorks integration, good customizability, and great tech ... decent interface and good functionality for its price. ... write custom apps for it, ... > What is the best PDM system for Solidworks. ...
    (comp.cad.solidworks)
  • Re: Another great example of how Word 2007 "brings commands closer to the surface"
    ... trashing and replacing Word's total interface and method of operation was ... remake the entire Word user interface to produce these new features? ... since the "majority" of users don't create custom toolbars and ... Hey, folks, the "majority" of users also never create a macro, ...
    (microsoft.public.word.newusers)
  • Re: What about CAO?
    ... So if I have the remoting service set as SingleCall - it's ... it's not possible to instantiate a new ... Now implement this interface on the ... > only on the client). ...
    (microsoft.public.dotnet.framework.remoting)
Loading