Re: application communication in xml without webservices?
From: Dan Rogers (danro_at_microsoft.com)
Date: 11/24/04
- ]
Date: Wed, 24 Nov 2004 00:26:08 GMT
Hi Dave,
The key thing to achieving cross-platform interop is really to pin the tail
on the right donkey. In this case, that donkey that will either carry you
across the desert or leave you clinging helplessly to a canyon wall is the
tool-set you choose to use on each platform. For instance, if you look to
only adopt tools that have been proven to work well together, then you can
shave a whole lot of time off of web service development. If you choose to
use raw java as shipped by Sun, then you have to almost approach it from
the angle brackets on upwards - building everything yourself.
Java tools that work well with services designed to use cross-platform data
types include Visual Studio .NET (for the Microsoft platform), the java
tools from Systinet, Bea and IBM (websphere).
You might want to look at WS-I.org - a group that includes Microsoft, IBM
and others - discussing and setting test/interop guidelines for designing
services that have a chance of working cross-tool and using cross-platform
capable data types.
The statement about "automatic web services" is, to me, a bit harder to
interpret. I think the real issue comes down to what data types you try to
move betweeen callers and services. For instance, you could use a really
loosely coupled approach on one hand - passing DataSet and returning
DataSet - or I've even seen people making method signatures of
XmlNode/XmlNode - but these impede cross platform, cross tool by removing
any call specific semantics. Further, using "high functionality" return
types such as DataSet introduces the need for a REALLY_REALLY_REALLY smart
proxy - somthing that you won't find on other non-Microsoft tools, for
instance.
But I've personally had a LOT of success in defining straightforward
classes (which equate to straightforward XML schemas), that consist of
elements that fall into the intersection of the .NET, Java and XML Schema
type systems (int, string, float, double, boolean, DateTime and compound
structures that consist of these basic types). From there you need to
avoid constructs like "nilable = true" in schemas that represent .NET value
types (the issue being Java is a pure object based language, where .NET has
intrinsic value types).
So the message is that if you define your interfaces to be "safe" for cross
tool, cross language, and then use world-class tools such as Systinet on
the java side, you will have a smooth implementation experience.
I hope this helps
Dan Rogers
Microsoft Corporation
--------------------
>From: david.mcshane@terminalfour.com (Davey)
>Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
>Subject: Re: application communication in xml without webservices?
>Date: 23 Nov 2004 03:06:57 -0800
>Organization:
>Lines: 171
>Message-ID: <791b99c2.0411230306.41601ca0@posting.google.com>
>References: <791b99c2.0411220227.1d9de576@posting.google.com>
<l248ZXM0EHA.2960@cpmsftngxa10.phx.gbl>
>NNTP-Posting-Host: 217.33.79.126
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: 8bit
>X-Trace: posting.google.com 1101208017 6065 127.0.0.1 (23 Nov 2004
11:06:57 GMT)
>X-Complaints-To: groups-abuse@google.com
>NNTP-Posting-Date: Tue, 23 Nov 2004 11:06:57 +0000 (UTC)
.glorb.com!postnews.goog
le.com!not-for-mail
>Xref: cpmsftngxa10.phx.gbl
microsoft.public.dotnet.framework.aspnet.webservices:26768
>X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
>
>Hi All
>Thanks for the comprehensive response Dan! I take your points:
>- webservices remove some of the complexity out of communicating
>between applications
>- they offer a standard way to do things
>- they allow appplications to communicate across firewalls ( not an
>issue in our case as the system will only ever be in internal
>networks)
>- there are tools which do alot of the work for you (for some
>languages)
>
>Some of our team have been creating basic webservices with c# and
>visual studio and its straightforward. Unfortunately,we have other
>applications
>written in Java and Delphi, and creating webservices in Java is alot
>more complex and awkward!
>The delphi developers have not tried yet but they will be getting
>involved soon.
>So these two sets of developers are going to have to learn new skills
>if we go with webservices.
>
>The other issue we are concerned about is interoperability.
>We found this article on it:
>
>and although it says that there probably wont be any problems,there
>could be! In particular we are worried by the comment that
>automatically created webservices may not work properly on other
>platforms. This is worrying,since using visual studio to create
>the webservices for us, would be one of the main advantages of
>webservices in the first place.
>Has anyone any experience of creating webservices used by delphi/ java
>applications? And did you encounter any problems?
>
>At the end of the day we want to ensure we make the right choice.
>Sending a fully defined XML document bewteen applications using a
>standard
>transmission protocol shouldnt be too complex. Granted there is extra
>work in the parsing and adding side of things, but there is also alot
>of work in
>using webservices to do a similar thing.
>
>Any thoughts?
>Dave
>
>danro@microsoft.com (Dan Rogers) wrote in message
news:<l248ZXM0EHA.2960@cpmsftngxa10.phx.gbl>...
>> Hi David,
>>
>> It is certainly possible to do what you are suggesting. For instance,
you
>> could POST an XML document to a URL over HTTP . The code that services
>> that URL could read the XML using a DOM, and then parse the XMl as you
>> suggest. It could then repeat this process, making plain old HTTP
requests
>> on-down the chain. Each level in the chain could use its local DOM and
add
>> nodes, alter nodes, etc, and return the XML as the HTTP POST response.
If
>> you need reliable delivery, you could even just open HTTP ports directly.
>>
>> The tricky part is going to be merging or staging the proper order.
>> Another tricky part is going to be standardizing over time on a request
>> recognition format for your message framework (assuming you want to
extend
>> this pattern over and over again, for different applications, over time).
>>
>> If you want to frame your request/response approach into a form that
will
>> readily pass through firewalls, you will probably want to define
bindings
>> that standardize how you'll use HTTP so that others who follow in your
>> footsteps can do things in a similar fashion. You'll want to
standardize
>> on how you use HTTP headers, whether youw want to define any custom
headers
>> (work with the IETF here if you want to standardize these), and you'll
>> eventually want to define standard ways that a community of programmers
>> such as yourself encode specific object based data structures and schema
>> based document definitions into the on the wire XML stream.
>>
>> You'll probably want to start an OASIS or W3C project that standardizes
the
>> namespace usage so that people who you share these implementations with
can
>> all recognize the element as being your specific content, and not just
>> based on the element name or capitalization.
>>
>> You may even eventually want to develop frameworks for different
platforms
>> that help programmers who adhere to your definitions to not have to do
as
>> much hand coding around XML.
>>
>> Now, if you are following me, you will already recognize the pattern of
>> standardization that I've advocated as being the path that SOAP
followed.
>> In your request you asked whether sending your XML in SOAP will help -
it
>> definitely will. But what I find myself wondering is "what is
inadequate
>> about the web service tools that different vendors have created to help
>> programmers who want to implement this kind of model?"
>>
>> Using a tool such as ASP.net and Visual Studio .NET, you can quickly
build
>> pass-thru methods that take a specific class type as input, add to that
>> class as required, and then return the aggregate result. You don't have
to
>> dive down to raw XML manipulation - which is error prone if you are hand
>> crafting it- but can work at an abstraction layer based on objects.
Other
>> SOAP tools let you work directly with the DOM if you like, and some of
them
>> even let you sling angle-brackets if that is what you want.
>>
>> In short, the SOAP infrastructure defines the
request/recoginition/response
>> semantics for the kind of requests you seemed to describe. A plethora
of
>> tools that make building this kind of application already exist - for
>> virtually any platform or programming language that you can think of.
The
>> approach you describe - some call this an additive or publishing
approach -
>> seems not unsound, and you can get a lot of cross-team, cross platform
>> traction by using web services directly.
>>
>> I hope this helps
>>
>> Dan Rogers
>> Microsoft Corporation
>> --------------------
>> >From: david.mcshane@terminalfour.com (Davey)
>> >Newsgroups: microsoft.public.dotnet.framework.aspnet.webservices
>> >Subject: application communication in xml without webservices?
>> >Date: 22 Nov 2004 02:27:00 -0800
>> >Organization:
>> >Lines: 41
>> >Message-ID: <791b99c2.0411220227.1d9de576@posting.google.com>
>> >NNTP-Posting-Host: 217.35.86.212
>> >Content-Type: text/plain; charset=ISO-8859-1
>> >Content-Transfer-Encoding: 8bit
>> >X-Trace: posting.google.com 1101119221 18878 127.0.0.1 (22 Nov 2004
>> 10:27:01 GMT)
>> >X-Complaints-To: groups-abuse@google.com
>> >NNTP-Posting-Date: Mon, 22 Nov 2004 10:27:01 +0000 (UTC)
>> >Path:
>>
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTFEED02.phx.gbl!tornado.fas
>>
twebnet.it!tiscali!newsfeed1.ip.tiscali.net!news.glorb.com!postnews.google.c
>> om!not-for-mail
>> >Xref: cpmsftngxa10.phx.gbl
>> microsoft.public.dotnet.framework.aspnet.webservices:26741
>> >X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet.webservices
>> >
>> >Hi All,
>> >We are trying to work out how a server application should behave and
>> >how it can communicate with other applications.
>> >Here is the scenario.
>> >
>> >A server application (c#) is responsible for being the middleman
>> >between applications.
>> >Application A needs to find something out, so it sends a request to
>> >the server.
>> >The server does some work on the request and then identifies which
>> >associated application can provide the additional information needed.
>> >The server then needs to call application B
>> >The server then needs to gather the response from application B
>> >then forward that response to application A
>> >
>> >The big problem is getting the applications to communicate.
>> >We have applications writen in Java,C# and Delphi.
>> >So we need a neutral way to communicate and pass information.
>> >My natural reaction would be webservices but I'm not sure if this is
>> >ideal.
>> >
>> >All I really want to do is pass an xml document between applications
>> >and have the application fill in the gaps it knows about.
>> >The xml message has a format of its own, so in a way its its own type
>> >of protocol.
>> >The applications all look at the xml document and work out what
>> >information is being requested.
>> >Then they fill in the blanks in the xml document and send it back.
>> >
>> >Is there a way to simply:
>> >open a connection to another application.
>> >send it an xml document
>> >get a response from that application with the xml document
>> >
>> >maybe its as simple as:
>> >open a connection to another application. (TCP/IP)
>> >send it an xml document(SOAP)
>> >get a response from that application with the xml document(TCP/IP)
>> >
>> >Thanks in advance,
>> >David
>> >
>
- ]