Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Web Services / October 2004

Tip: Looking for answers? Try searching our database.

Confused: WS,  SOA, Messaging any better than CORBA?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Jules - 26 Sep 2004 19:48 GMT
Hello

I am still trying to grapple with Web Services, SOA, Messaging, so
please excuse my ignorance.

I can build and consume (Request/response) Web services with Visual
studio pretty easily. Visual Studio, makes these look like Internet
accessable remote procedure calls RPC.  Sort of like CORBA being
allowed through http enabled Internet firewalls.
 
So now I try to understand SOA, and the emphasis it being a message
based paradigm. This is where I get confused, even WS Enhancements
appear to be generally based around request/response interactions.  I
can see in the WSDL defitnion an opportunity to do a Request Message
only, or Response_Message only, but there seems to be little in the
WSE 2.0 to support this across http.  So I appera to be limited to RPC
style interactions across http. I am reading Url SOA framework book,
and he is makes the distinction between RPC and Document based
payloads. So I am looking for some concrete examples of doing this in
WSE 2.0.

My real confusion is that I don't see 'messages',  I can receive
documents to consume.  But there are no message Queues, so it doesn't
look like any MOM based infrastructure I have seen before. I cannot
queue up messages if processor overloaded, or the server is down. So
why say that SOA its message orientated. Are we really going to get a
WS standard that gives us true message orientated services. I know I
can stuff MSMQ on the end of a web services, but this is true Internet
wide service. (The web servcie may not be there.  But I guess there is
nowhere on the Inter Netwrok to queue the messages anyway)

My other confusion is that with WSE 2.0, to perform Request Only,
Notification only, interactions I can only do this on TCP based
channels (Because http only seems to support requests/response
interactions, which is a RPC pardigm.) So I seem to be constrained to
the RPC paradigm, for cross Internet interaction. If I am stuck with
TCP, I might as well continue with CORBA, since TCP ports will not get
through Internet Firewalls.

At least with CORBA I have a mix of RPC and true messaging.

Looking forward to the day that WS providing a Queued Messaging
standard.

Many Thanks for any clarifications or reference to clearer SOA links.

Jules
Hervey Wilson [MSFT] - 26 Sep 2004 23:20 GMT
> Hello
>
[quoted text clipped - 43 lines]
>
> Jules

SOAP supports one-way messaging, this model is implemented in both the
.NET Framework Web Services (over HTTP) and is fully supported in WSE2
over HTTP, TCP and other protocols that various developers have written
support for, note that this list includes MSMQ which would give you the
reliable queuing semantics that you are looking for.

Check out the SoapSender and SoapReceiver classes, you'll see that that
send / receive one-way messages (SoapEnvelopes). SoapClient and
SoapService can also send / receive one-way and request-response
messages. If you really want to get down to the plumbing, you can also
check out the ISoapInputChannel and ISoapOutputChannel layer).

Much of this is illustrated in the samples and described in the
documentation. In addition, check out the Microsoft Web Services spoke
on http://msdn.microsoft.com/webservices (general WS stuff) and
http://msdn.microsoft.com/webservices/building/wse for more WSE specific
material.

Signature

This posting is provided "AS IS", with no warranties, and confers no rights.

Jules - 29 Sep 2004 22:03 GMT
Many Thanks Hervey

I have started reading and playing around with SoapSender with TCP, as
you suggested. Its great stuff for doing soap servcies with TCP.

I have got a basic http server running with SoapReceiver and using
ashx file referencing WebHandler classes.  The examples and
documentation I have been reading so far seem be based upon TCP based
one way messaging.  ( As far as I can see http has to respond to the
request, even if its a 202 Accepted response.)  I will keep looking
for better http examples.
   
Another query is how I can wsdl query a WebHandler based service,
based upon ashx files. I had hoped that I could still ?wsdl, or use
Add Web Reference against ashx file, but its only expecting asmx
files. Which is a shame, because discovering http services and
SoapReceiver message level is the desirable combination. Am I missing
something.

Thanks anyways

Jules

> > Hello
> >
[quoted text clipped - 61 lines]
> http://msdn.microsoft.com/webservices/building/wse for more WSE specific
> material.
Hervey Wilson [MSFT] - 30 Sep 2004 03:46 GMT
> Many Thanks Hervey
>
[quoted text clipped - 4 lines]
> SoapReceiver message level is the desirable combination. Am I missing
> something.

SoapReceiver itself does not directly produce WSDL output, however
SoapService can generate this automatically. You can override the
GetDescription method on SoapReceiver to return a WSDL document if you
need to.

The WseWsdl2 command line tool in the product can issue the ?WSDL query
to these services and generate a WSE-enabled proxy for them. This should
work on all transports in the product.

Signature

This posting is provided "AS IS", with no warranties, and confers no rights.

Jules - 01 Oct 2004 00:47 GMT
Hervey

Many thanks for your helpful posts,and introducing me to this cool
stuff.

As you recommended using SoapService and [SoapMethod]s,  instead of
SoapReceiver, does now allow me to query Myservice.ashx?wsdl to return
my wsdl desription. I can also Add Web Reference from visual studio
client, on another machine to create some proxy code classes.

However, my wsdl on my initial attempts so far seems to have generated
rather loosely type message types such that my SoapService method:

public void AcceptSubscription(SoapEnvelope env)

becomes to following Wsdl:

<s:complexType name="AnySchema">
       <s:sequence>
         <s:any minOccurs="0" maxOccurs="unbounded"
processContents="lax" />
       </s:sequence>

<message name="AcceptSubscriptionMessageIn">
   <part name="data" type="s0:AnySchema" />
</message>

Which in the (VS Add Web Reference) proxy generated becomes

AcceptSubscription(XMLElement[] data)

I am not quite sure how these proxy methods are really helping me,
beyond simply using SoapClient. I have been reading various MSDN WSE
articles, and I need to read and understand a lot more on how I can
specify my SOA services acros the Internet to third parties. My
feeling is that simply receiving SoapEnvelope, cannot in itself help
define any types. Since it is a message after all, and not a parameter
list. So I guess this means that when I go towards SOA message based
paradigm, which consists of exchanging Soap envelopes, I have do more
of my own specification of what my 'services do'. I cannot really rely
upon auto generated wsdl, to specify my services, and I do need to
provide explicit support to my client developers as to what my
services are doing to their soap bodies.

I guess I have become rather lazy with the Microsoft web service RPC
based paradigm, where I can simply browse for a remote service, Add
Web Reference and develop Client code against generated tightly typed
proxy methods. Which is sort of where I would really like to be with
SOA messaging.

Many Thanks for helping me understand WSE and SOAP processing.

Jules  

> > Many Thanks Hervey
> >
[quoted text clipped - 13 lines]
> to these services and generate a WSE-enabled proxy for them. This should
> work on all transports in the product.
Hervey Wilson [MSFT] - 01 Oct 2004 05:37 GMT
> Hervey
>
[quoted text clipped - 26 lines]
>
> AcceptSubscription(XMLElement[] data)

If your SoapService method deals directly with the SoapEnvelope rather
than the body of the message using an XmlSerializable type, the WSDL
generated will appear as above. This is because WSE has no way of
identifying the schema of the message body from a SoapEnvelope object.
In this case, you must override GetDescription to return the WSDL for
your service. If you use XmlSerializable types in the SoapService, the
generated WSDL will contain schema for those types rather than the open
schema above.

Signature

This posting is provided "AS IS", with no warranties, and confers no rights.

Jules - 02 Oct 2004 12:42 GMT
Thanks

  That makes a sense. I need to spend a bit more time reading what
sort of SOA apsirations we have.  

As you previlusly suggested I should also have used WseWsdl2 to
generates the corrsponding proxies  for [Soapmethod] elaborated
methods. And then its up to me to define the interfaces.

Many Thanks, sorry for being slow and impetious on this stuff, but it
because I am finding it such great stuff that I am tending to  'dive
into' the code without thinking and reading through enough.  

Jules

>> Hervey
>>
[quoted text clipped - 35 lines]
>generated WSDL will contain schema for those types rather than the open
>schema above.
Jules - 01 Oct 2004 18:44 GMT
Doh,

As you sugegsted I should have used WseWsdl2 tool to generate proper proxy
SoapClient class which correctly generates

public void AcceptSubscription(SoapEnvelope request )
{
    base.SendOneWay("AcceptSubscription", request);
}

Sorted
Thanks

> Hervey
>
[quoted text clipped - 67 lines]
> > to these services and generate a WSE-enabled proxy for them. This should
> > work on all transports in the product.

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.