«

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.

On Sep 26, 10:28 am, "Jerry B." <grbla...@gmail.com> wrote:
> 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.

Daniel Pitts wrote:
> On Sep 26, 10:28 am, "Jerry B." <grbla...@gmail.com> wrote:
>> 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.

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?

--
Lew

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

The XFire project now redirects one to
<http://incubator.apache.org/cxf/>

mentioned in the OP's post.

It handles all the above-mentioned alternatives, apparently. I've not used it
myself.

--
Lew

On Wed, 26 Sep 2007 17:28:09 -0000, "Jerry B." <>
wrote, quoted or indirectly quoted someone who said :

>My coworkers want to go with web services, but I believe all the
>complexity of SOAP is not necessary here.

There are many ways to skin that cat, and all but one of them don't
require SOAP. See http://mindprod.com/jgloss/remotefileaccess.html

For a summary of approaches, their pros and cons.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Lew wrote:
> 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. <>
> To: Lew <>
> References: < .com> <. com> <>
>
> 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.

--
Lew

Lew <> writes:
>>> 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?
>>
>> 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,

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

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
| (C++, Java, Common Lisp, Jini, middleware, SOA)

Lew wrote:
>> From: Jerry B. <>
>> 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.

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

On Fri, 28 Sep 2007 20:50:47 -0400, Patrick May <> wrote,
quoted or indirectly quoted someone who said :

> Actually, any non-XML protocol is going to pass much less over
>the wire.

Huh? XML is about the fluffiest encoding yet invented.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Roedy Green wrote:
> On Fri, 28 Sep 2007 20:50:47 -0400, Patrick May <> wrote,
> quoted or indirectly quoted someone who said :
>
>> Actually, any non-XML protocol is going to pass much less over
>> the wire.
>
> Huh? XML is about the fluffiest encoding yet invented.

That was what he said !?!?

Arne