ANN: RemObjects Software introduces the new RemObjects SDK 3.0 for .NET

[Aleks La Rosa [RemObjects Software]]

RemObjects SDK, the award winning remoting framework for Delphi and Kylix,
is now available for Microsoft .NET.

The RemObjects SDK allows you to build fully managed multi-tier servers and
clients for .NET and Mono, while preserving full wire compatibility with
RemObjects SDK for Delphi so that you can easily combine servers and clients
from different platforms.

== Core Features ==

- Fast and efficient BinMessage messaging format
- Service Builder 3, the RAD service-modeling tool
- 100% native .NET code
- Full wire-compatibility with RemObjects SDK for Delphi
- Mix .NET and Mono servers with Delphi/Kylix clients, or vice versa,
to build true cross-platform solutions
- TCP and HTTP based channels
- Extensible framework: add new networking channels or messaging
components with ease
- Data compression for slow networks (ZLib or your own)
- Built-in security features to prevent DOS attacks and server exploits
- Extensible Session Management architecture
- RODL files manipulation classes
- Large set of service-instantiation options (pooled, singleton, per-call)
- Support for a large variety of data types (integer, float, double, 8bit
and wide string, custom objects, streams, datasets, lists, etc.)
- Thread safe core
- Fully object-oriented infrastructure (service and struct inheritance)
- Interface-oriented architecture
- Designed with statelessness and maximum scalability in mind
- No deployment license fees
- Full C# source code
- Extensive IDE integration for Visual Studio and Borland Developer Studio
- Built on RemObjects Internet Pack for .NET
- First class support for C#, Chrome, Visual Basic .NET and Delphi for .NET

(and much more)

Read more about the RemObjects SDK 3.0 for .NET, download the free trial, or
watch the first RemObjects video at http://www.remobjects.com?ronet

Order your copy today at http://www.remobjects.com/order
New License EUR 299, Cross-grade EUR 249

The RemObjects Software Team
http://www.remobjects.com

 

[Liu]

== Core Features ==

- Fast and efficient BinMessage messaging format

How is the performance compare to dotNet Remoting ?
If it is just the same as Remoting, why should i buy another add-on ?

- Extensible framework: add new networking channels or messaging
components with ease

Can you relaborate more on this ?


My current dotnet remoting app is damn slow, i used to transfer
datasets between server and client, how your SDK will help ?


Liu

 

[Miha Markic [MVP C#]]

Hi Liu,

How is the performance compare to dotNet Remoting ?
If it is just the same as Remoting, why should i buy another add-on ?



Can you relaborate more on this ?


My current dotnet remoting app is damn slow, i used to transfer
datasets between server and client, how your SDK will help ?

Apart from RO enhancements, I guess the main problem with datasets is
serialization - they are always serialized to xml.
This article might help you to speed transfer of datasets regardless of the
transportation layer:
True Binary Serialization and Compression of DataSets
http://www.eggheadcafe.com/articles/20031219.asp

 

[Yuancai \(Charlie\) Ye]

Hi,
See the site at http://www.codeproject.com/dotnet/sperformance.asp



Fast and securely accessing all of remote data sources anywhere with
SocketPro using batch/queue, non-blocking and parallel computation

See 30 well-tested and real OLEDB examples
www.udaparts.com

 

[marc hoffman [RemObjects Software]]

Liu,

How is the performance compare to dotNet Remoting ?
If it is just the same as Remoting, why should i buy another add-on ?

For one thing, the BinMessage protocol is highly optimized to include as
little overhead as possible for the data you send. If you send - for
example - an integer, that's exactly 4 bytes in your message, not a single
more; the same applies to all other data types, including structs. Secondly,
RO doesn't use complex reflection-based mechanisms to determine what to a
stream over the net, but auto-generated proxy and stub code that has
detailed knowledge of your message - in other words it knows that - for
example - the first parameter needs to be streamed as a integer, the second
as a string and the thirds as a custom struct, and can thus do so without
looking up the types via reflection, and/or incurring any boxing. Also, our
BinMessage protocol provides integrated compression, which helps to save
bandwidth, especially for large messages sent over the network.

This list is by no means complete, and i'd be happy to answer more detailed
question.

Also, we have a trial version out that you can use to thoroughly test and
evaluate RO, as well as a free "Client SDK".

Can you elaborate more on this ?

Well. the basic point is that the framework is very extensible (and easily
extensible) if you need to add custom messaging formats or transport
channels. Let me say off the start that 99% of all users never ever will
find the need to actually create a custom message or a custom transport
channel, but of you do, you can.

Why would you want to add a custom message? ok, let's say you want to access
some weird server provided by a third party that doesn't use a standard
protocol. You could create a custom message type that would format requests
in the protocol required by your server, and then access that server from
your .NET client using RO - without needing to worry about the different
message format anymore.

Why would you want to add a custom transport channel? Say you have an
existing client and server architecture developed with RO, and now you got a
customer who wants to deploy your application on his premises but doesn't
have ethernet wiring but, say, could provide only RS232 or RS485 lines
between the server and client. That's pretty common if you're deploying an
application in an industrial environment (say a PC somewhere in the factory
talking to a server in the office building). You could implement a RS485
based transport channel, and your application code would continue working
just the same - never knowing it's not even communicating over ethernet.
Implementing such a channel would be very easy.

Granted, both of these scenarios are not something that the majority of
users will ever run into, but nevertheless - if you need it the
extensibility is there.

My current dotnet remoting app is damn slow, i used to transfer
datasets between server and client, how your SDK will help ?

It's had to say something definite on this without knowing the root of your
speed problem, of course. As Miha mentioned, one problem (unrelated to
either Remoting or RemObjects SDK) is that ADO.NET datasets by default
stream to XML, which of course implies an overhead.

If the speed problem you are seeing is in the creation/parsing of these XML
datasets, it's unlikely that changing the remoting layer would help much (on
that front); you should investigate into serializing the ADO.NET dataset
into a binary format. If on the other hand the actual transport of the
(sometimes large) XML dataset is the problem, the RO's compression might
come in handy and solve the problem.

I hope these answers have been helpful; please let me know if you have
additional or more detailed questions.

thanx,

--
marc hoffman
Chief Architect, .NET
RemObjects Software
http://www.chromesville.com

ftr, i'm not sure what the policy on cross-posting in these newsgroups is,
so i'm setting follow-up to microsoft.public.dotnet.framework.remoting,
which probably more closely fits the bill for this discussion.