data transport

J

Jerry B.

Hi,
I'm designing a service platform and want your opinion on which way to
go.

I have databases and developers, and want to put a service middle-
layer, to serve as a gatekeeper. I don't want the developers touching
the database itself!

The developers work with both Java and .NET, so whatever I do, needs
to be consumable from both platforms. Obviously, I want to abstract
the transport complexities from the users (developers).

I need logging and auditing capabilities (who's using the data, etc),
and security (user/transport)

I want to create a server/client architecture. I will create the
client, so the developers will instantiate my client and get
information. A client snippet would look like this, for example:

dbClient db = new dbClient('myuser');
List <name> names = db.getNames();

Since I own both sides, I can embed a bean 'Name' in my client app
(jar, or whatever C# uses)

My coworkers want to go with web services, but I believe all the
complexity of SOAP is not necessary here. Also, we plan to use this
service internationally, which means we need to save bandwidth.

I've so far played with the following:
1) Ice (zeroc.com). Problem: it doesn't support complex beans, and I
have to create the Slice, since there is no way to derive a Slice from
a Java class. I have hundreds of Java beans, so it's not an option to
create the Slice files manually.

2) JSON-based msg. It marshalls and unmarshalls OK, but now I need a
transport protocol that supports logging/auditing/security. Any ideas?

3) CXF -> Even though it abstracts most of the complexity, we're
finding problems with security, etc.

4) Axis2 -> Is it as slow as people are making it?

Opinions please!!!

Thanks.
Jerry.
 
D

Daniel Pitts

Hi,
I'm designing a service platform and want your opinion on which way to
go.

I have databases and developers, and want to put a service middle-
layer, to serve as a gatekeeper. I don't want the developers touching
the database itself!

The developers work with both Java and .NET, so whatever I do, needs
to be consumable from both platforms. Obviously, I want to abstract
the transport complexities from the users (developers).

I need logging and auditing capabilities (who's using the data, etc),
and security (user/transport)

I want to create a server/client architecture. I will create the
client, so the developers will instantiate my client and get
information. A client snippet would look like this, for example:

dbClient db = new dbClient('myuser');
List <name> names = db.getNames();

Since I own both sides, I can embed a bean 'Name' in my client app
(jar, or whatever C# uses)

My coworkers want to go with web services, but I believe all the
complexity of SOAP is not necessary here. Also, we plan to use this
service internationally, which means we need to save bandwidth.

I've so far played with the following:
1) Ice (zeroc.com). Problem: it doesn't support complex beans, and I
have to create the Slice, since there is no way to derive a Slice from
a Java class. I have hundreds of Java beans, so it's not an option to
create the Slice files manually.

2) JSON-based msg. It marshalls and unmarshalls OK, but now I need a
transport protocol that supports logging/auditing/security. Any ideas?

3) CXF -> Even though it abstracts most of the complexity, we're
finding problems with security, etc.

4) Axis2 -> Is it as slow as people are making it?

Opinions please!!!

Thanks.
Jerry.

I've also heard of xfire (I have no experience on that) and rest
API's. Look for those as possibilities as well.

Other than that, I haven't enough knowledge to provide the feedback
you desire.

HTH,
Daniel.
 
L

Lew

Daniel said:
I've also heard of xfire (I have no experience on that) and rest
API's. Look for those as possibilities as well.

Other than that, I haven't enough knowledge to provide the feedback
you desire.

Of course, both XFire and Axis are SOAP implementations.

What makes SOAP more complex than the listed alternatives, or the
roll-your-own approach?

What do you sacrifice (besides tested and stable solutions) by avoiding
SOAP-based web services?
 
L

Lew

Lew said:
What makes SOAP more complex than the listed alternatives, or the
roll-your-own approach?

What do you sacrifice (besides tested and stable solutions) by avoiding
SOAP-based web services?

You sent your reply to the wrong place; it goes to the newsgroup:
-------- Original Message --------
Subject: Re: data transport
Date: Fri, 28 Sep 2007 09:58:50 -0700
From: Jerry B. <[email protected]>
To: Lew <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]>

Well... for starters I don't want to bloat the communication: XML is a
beast, and I'll need something small to go through the wire.
Then there's the craziness of setting up soap, ws-security, etc in
Java and have it be transparent to .NET and viceversa.
Then there's the marshalling/unmarshalling, the overhead of creating
the soap service/WSDL on the fly, etc.

You'll find the overhead of other protocols isn't so much better, and the
complexity of implementing it yourself instead of leveraging the existing
libraries may be more egregious than just using the standard solutions.

YMMV, of course. Good luck.
 
P

Patrick May

Lew said:
You'll find the overhead of other protocols isn't so much better,

Actually, any non-XML protocol is going to pass much less over
the wire.
and the complexity of implementing it yourself instead of leveraging
the existing libraries may be more egregious than just using the
standard solutions.

There are alternatives that are simpler and more flexible than
the WS death star suite. One that may be appropriate for the original
poster's problem is Jini with a distributed JavaSpace.

Regards,

Patrick
 
G

Guest

Lew said:
You'll find the overhead of other protocols isn't so much better, and
the complexity of implementing it yourself instead of leveraging the
existing libraries may be more egregious than just using the standard
solutions.

Setting up web service toolkits is usually very simple.

XML in general and SOAP specifically do make the wire messages big.

Parsing XML in general and SOAP specifically do cost significant CPU
power.

WSDL is only generated once so that has no performance impact.

Arne
 
R

Roedy Green

That was what he said !?!?

There is an ambiguity. Which did he mean?

1. pass must less useful information over the wire in a given time.

1. pass fewer bits over the wire to express the same message.
 
P

Patrick May

Roedy Green said:
There is an ambiguity. Which did he mean?

1. pass must less useful information over the wire in a given time.

1. pass fewer bits over the wire to express the same message.

I meant (1). ;-)

I intended the obvious claim that XML requires far more bits per
useful message than do other protocols.

Regards,

Patrick
 
L

Lew

Patrick said:
I intended the obvious claim that XML requires far more bits per
useful message than do other protocols.

If it takes twice as many bits to send a message, but the format is three
times as useful, what's the balance sheet?

You're treating "useful message" as the unit of utility. What if you could
attach more or less utility to a single message?
 
P

Patrick May

Lew said:
If it takes twice as many bits to send a message, but the format is
three times as useful, what's the balance sheet?

If the two messages are equivalent, how can a format be more
useful?

Patrick
 
D

Daniel Pitts

If the two messages are equivalent, how can a format be more
useful?

Possibly in flexibility, scalability, extensibility, and backward
compatibility. Along with a lot of other 'bilities not otherwise
listed :)
 
L

Lew

Daniel said:
Possibly in flexibility, scalability, extensibility, and backward
compatibility. Along with a lot of other 'bilities not otherwise
listed :)

Begging the question: placing the conclusion as the premise of the argument.

"If the two messages are equivalent" is the point at issue, isn't it?
 
R

Roedy Green

If it takes twice as many bits to send a message, but the format is three
times as useful, what's the balance sheet?

Most of the time the nested structure of XML is not being used. You
are just sending identical rows of data. You might as well be using
SQL, CSV or a fixed binary format.

XML does not pay until you turn on nesting, multiple values per field
or you only specify a few of many possible fields.

XML is not so painful now that parsing is built in to the JRE.
Previously, you had the overhead of having to download the
parsing class library too even for a tiny XML file.
 
P

Patrick May

Lew said:
Begging the question: placing the conclusion as the premise of the argument.

"If the two messages are equivalent" is the point at issue, isn't it?

Apparently that was your intention.

My question remains, though. The use of a heavy weight wire
format like XML and an equally heavy weight, inelegant infrastructure
like Web Services requires more defense than "It's a standard."
Lighter weight, more efficient solutions are available and should be
considered.

A number of companies that I've worked with use Web Services to
expose interfaces outside their firewalls, but use technologies like
Jini internally. In practice that approach provides significant
benefits, including addressing all the NFRs ("ilities") mentioned by
Mr. Pitts.

Sincerely,

Patrick
 
R

RedGrittyBrick

Jerry said:
2) JSON-based msg. It marshalls and unmarshalls OK, but now I need a
transport protocol that supports logging/auditing/security. Any ideas?

The only JSON example I know of, used HTTP for transport and supported
security by means of an HTTP header containing an SHA1 hash of a
concatenated shared-secret with JSON body text.

The whole point of JSON seems to be that it should be much much simpler
than SOAP/XML. I suspect adding logging and auditing requirements should
make you reconsider the heavyweight web-services protocols like SOAP.

I've done a few projects using SOAP over HTTP(S), the first ones were
fabulously easy. The more recent ones have become depressingly hard. In
particular because of WS-Security, due mainly to the requirement to
canonicalise the XML and hindered by the provision by a government
agency of WSDL that none of my Java/C#/Perl tools could digest.

In your shoes I'd be mightily tempted to use JSON over HTTPS and add
headers to contain the user credentials in some secure form. If you
understand how WS-Security works in SOAP then you'll know enough to work
out how to use RSA or DSA to produce a signature using a private key
from a keystore.

Security = authentication + confidentiality + integrity

* Authentication: use a shared secret, digital signatures or whatever
is appropriate to your situation.

* Confidentiality: let HTTPS take care of that.

* Integrity: Use a hash, signed if needed.

Just some random thoughts. Bear in mind that Usenet advice is often only
worth what you pay for it :)
 
L

Lew

Patrick said:
Apparently that was your intention.

"Apparently" I was not clear. It is exactly my point that XML, while taking
somewhat more wire bandwidth than other formats, provides benefits not
available in other formats, thus making the messages not equivalent.
My question remains, though. The use of a heavy weight wire
format like XML and an equally heavy weight [sic], inelegant infrastructure

That is not a valid engineering assessment. Compared to some other approaches
with more compact wire formats, XML is neither more heavyweight /in
development costs/ nore "inelegant" (whatever /that/ is supposed to mean).

Nor, as you point out, is it the only solution. I only want to elucidate some
of the tradeoffs ignored by the knee-jerk "XML is heavyweight" canard so often
cited.
like Web Services requires more defense than "It's a standard."

Don't trivialize my argument. The point is, that /as/ a standard it has
already subsumed solutions to the problems you will face developing a custom
library, and /as/ a standard will save time and money in development, and /as/
a standard will have many, many others working on the disadvantages inherit in
the approach, e.g., processing efficiency.
Lighter weight, more efficient solutions are available and should be
considered.

Of course, but not based on incomplete assessment of the difficulties one
faces, nor by ignoring other costs than the usually trivial "wire weight".
A number of companies that I've worked with use Web Services to
expose interfaces outside their firewalls, but use technologies like
Jini internally. In practice that approach provides significant
benefits, including addressing all the NFRs ("ilities") mentioned by
Mr. Pitts.

Meaning that they have looked into the different tradeoffs involved and have
optimized to their own satisfaction the balance sheets of those approaches.
This is what I was recommending.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,835
Latest member
KetoRushACVBuy

Latest Threads

Top