application communication in xml without webservices?

[Davey]

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

 

[Dan Rogers]

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
--------------------

 

[Davey]

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:
http://devresource.hp.com/drc/resources/creatingInteropWebSvcs/index.jsp
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

 

[Dan Rogers]

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
--------------------