Re: Arch question.
From: William Stacey [MVP] (staceywREMOVE_at_mvps.org)
Date: 07/15/04
- Next message: William Stacey [MVP]: "Re: Reliable way to check for WSE installation?"
- Previous message: SA: "Re: Override default UsernameToken behavior"
- In reply to: SA: "Re: Arch question."
- Next in thread: SA: "Re: Arch question."
- Reply: SA: "Re: Arch question."
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 15 Jul 2004 18:39:24 -0400
Thanks SA. I was thinking about that. But then I thought I would junk up
my internal classes with a bunch of xml goo, so not sure but still open to
this. If you do create seperate xml classes just for webservices
send/receives, do you have a naming standard for the xml classes like
XmlCustomer, XmlCustomerRequest, etc or do you use seperate namespaces?
Cheers!
--
William Stacey, MVP
"SA" <informatica@freemail.nl> wrote in message
news:ucYwBtraEHA.3112@tk2msftngp13.phx.gbl...
> William:
>
> By marking your structures as Serializable() and by providing (if
necessary)
> more info for the XML parser (such as XmlRoot() and XmlElement()), you
don't
> have to do any parsing yourself.
>
> So, your SoapMethod can look like this
>
> <SoapMethod("SayHello")> _
> Public Function SayHello(ByVal MyName As NameInfo) As HelloResult
> ' code here to call business logic using
> ' NameInfo and get result as type HelloResult
> End Function
>
> provided that your structures or classes (I use classes, not structures)
>
> <Serializable(), _
> XmlRoot(Namespace:="http://tempuri.org")> _
> Public Class NameInfo
>
> <XmlElement(ElementName:="Name")> _
> Public Name As String
>
> End Class
>
> Also, be aware that your classes need a default constructor in order to be
> Serializable.
>
> Your client can then call
>
> .SendRequestResponse(MyName)
>
> where MyName is an instance of your NameInfo class. Again, no need to
> convert anything to a SoapEnvelope.
>
> Otherwise, your architecture looks solid.
>
> HTH
>
> --
>
> Sven
> http://www.adduxis.com
>
> "William Stacey [MVP]" <staceywREMOVE@mvps.org> wrote in message
> news:O5eRuaraEHA.752@TK2MSFTNGP09.phx.gbl...
> > Have a server app and using wse 2.0 tcp services as management
interface.
> > Works pretty well so far but have some question on general patterns
here.
> > Right now I am doing:
> >
> > 1) On the server, I have my server classes that don't consider any xml.
> > 2) I created xmldoc classes just for the web services that are just
> simple
> > structures that mirror the server structs to some degree.
> > 3) The webservice apis on the server call the server classes and make
XML
> > simple structures from the server objects as needed.
> > 4) The client has copy of xmldoc classes as needed.
> > 5) The client web methods convert normal method calls and build the
> > xmlrequest docs or parses the reply docs to create client complex
classes.
> > 6) The client has business logic classes ( in this case mostly tree
> > oriented.) that can understand the xmldoc classes and/or convert them to
> > client complex classes. The client business objects also update a
> > treeview/listview pair. The the client business logic serves as manager
> > between the treeview, user, and soap client calls.
> >
> > This all works and offers a clear seperation of business logic and web
> > services, but I am swiming in a soap of classes and translation issues.
> Is
> > this pretty much what others do, or is there a better pattern in
general?
> > Hope that makes sense. TIA!
> >
> > --
> > William Stacey, MVP
> >
> >
>
>
- Next message: William Stacey [MVP]: "Re: Reliable way to check for WSE installation?"
- Previous message: SA: "Re: Override default UsernameToken behavior"
- In reply to: SA: "Re: Arch question."
- Next in thread: SA: "Re: Arch question."
- Reply: SA: "Re: Arch question."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
