Re: MIDAS/Datasnap Alternative
- From: "Mark Annulis" <mannulis@xxxxxxxxxx>
- Date: Fri, 3 Mar 2006 11:34:04 -0500
Guys
I appreciate your interest and comments.
DDCAppservice is a homegrown product that we developed internally to improve
on DataSnap. We are developers, not a tools company. We use this product
daily in developing solutions for our own clients. We are constantly looking
for ways to make this better to increase our productivity.
I will try to answer questions that have been raised. Certainly the
alternatives (ASTA, RemObjects) are excellent, well established products and
we dont have any illusions of displacing these products.
The early versions of DCCAppService have been around since 2001. We made a
small effort in Nov 2003 to guage interest in the Delphi community. We
advertised in Delphi Informant, but soon after the magazine folded. Recently
while perusing this forum, I thought i would drop a line again to guage
interest.
How is this product different? I am not an expert on the other product. What
I can do is talk of ours.
High Performance & Scalability : DDCAppservice is an I/O Completion Ports
based socket server. If you are unfamiliar with IOCP's there are the most
advanced, efficient way of developing server applications.
For a brief overview, see
http://www.sysinternals.com/Information/IoCompletionPorts.html. A handful of
threads, and subsequently, a handful of DB connections can service many
client connections. Increasing the client base does not typically require
changing anything on the server.
Reliability : We use DDCAppService in our own deliverables servicing Oracle,
SQL Server, Access DB's in thin client desktop as well as web based
applications. One installation of an AppService can support multiple server
applications spanning multiple heterogeneous databases.
Extendibility, Better Maintainability, Faster Time to Market
The other products based their approcah on a GUI based server where one
needs to create a datamodule and then drop a query component and a provider
component for each logical data provider. we have applications that have
over 1000 providers. Thats a large datamodule.
Our approach is to define these providers in external XML files. Adding a
provider is as simple as adding a provider definition
<Provider>
<Name>dspKILSMISFilesHeaderCount</Name>
<SQL><![CDATA[
select count(*)
from ILSMISFILESHEADER
where sequenceprefix = :sequenceprefix]]>
</SQL>
<Params>
<Param Name="sequenceprefix" DataType="ftString" />
</Params>
</Provider>
The datamodule approach may be 'pretty' but in our opinion we can create 10
providers in a text editor faster than dropping 10*2 components on forms and
setting properties with our mouse. As we are developing the server, we dont
need to keep compiling these server apps. Save the XML file, reset the
service, and whala, the provider is ready. Need to update your clients
server. We simply send our updated XML file to the server, and it is now
available. No need to stop and replace an executable.
How do I better maintain the application. Well with the SQL defined in
external files, it is available to me to scan through and manage without
having to click on a query component to open up the SQL property. What if I
am defining the same SQL over and over again in my queries? We have
constants that can be defined in the XML files and referenced in multiple
queries. Cuts down on the bloat and enables defining key SQL elements in
your apps in a single location.
REPLACEMENT Macros enable text substitutions with server providers beyond
what can be performed with standard SQL parameters
<Provider>
<Name>gdspGetDataByKeyField</Name>
<SQL><![CDATA[select #DisplayField,#KeyField from #ValidTable where
#KeyField = :KeyFieldValue]]></SQL>
<Params>
<Param Name="ValidTable" DataType="ftString"/>
<Param Name="KeyField" DataType="ftString"/>
<Param Name="KeyFieldValue" DataType="ftString"/>
<Param Name="DisplayField" DataType="ftString"/>
</Params>
<Macros>
<Macro>
<Name>ValidTable</Name>
<Type>REPLACEMENT</Type>
<ParamName>ValidTable</ParamName>
</Macro>
<Macro>
<Name>KeyField</Name>
<Type>REPLACEMENT</Type>
<ParamName>KeyField</ParamName>
</Macro>
<Macro>
<Name>DisplayField</Name>
<Type>REPLACEMENT</Type>
<ParamName>DisplayField</ParamName>
</Macro>
</Macros>
</Provider>
If you chose to do so, this provider would enable me to select a piece of
data from a DB table based on a KeyField. Let say I want the 'FULLNAME' from
a 'USERS' table for a given 'LOGIN'
I could perform the following from the client.
cds := OpenProvider('gdspGetDataByKeyField',['USERS','LOGIN',<some
name>,'FULLNAME']);
strValue := cds.FieldByName('FullName').AsString ;
I have not seen this available on other products. What about this
OpenProvider. With Other products, one would need to setup a client
datamodule drop a clientdataset on that, establish the providername and the
parameters on that dataset. then to user it, in code
cds.providername := 'gdspGetDataByKeyField';
cds.params[0].asstring := 'USERS' ;
...
cds.Params[3].Asstring := 'FULLNAME' ;
cds.open ;
cds.close ;
Our OpenProvider approach enables one to perform this activity in a single
line. The OpenProvider approach is interface based. The Openprovider returns
an interface that does not need to be destroyed. The interface takes care of
this for you. There is no need to setup a stub on the client to access a
server provider. This is crucial for applications with 1000 providers.
Need to perform more complicated actions. Extensions are simple DLL based
plugins that do not require COM style registration. Extension functions can
plugin where simple SQL cannot be utilized.
<Provider>
<Name>dspKStampStub</Name>
<Extension>KSTUBS</Extension>
<Function>STAMP</Function>
<Params>
<Param Name="KeyTask" Datatype="ftString" />
<Param Name="KeySubTask" Datatype="ftString" />
</Params>
</Provider>
Access this on the client simply as
Executeprovider('dspKStampStub',[strTask,strSubTask]);
Like XML files, extensions can be easily updated on the fly. Your client
needs an immediate fix or update. Build the DLL and update the remote
installation of the DDCAppService. How?
We have a client utility called DDCRAppManager (DDC Remote App manager) that
enables one to perform such activities remotely. Execute SQL queries
remotely against the client DB via the DDCRappManager.
How about logging. I dont see anything natively in the other products.
DDCAppService logs every request in a remote file. Need to track a bug.
Connect via the DDCRappManager, pull back selected logs, and analyze the
sequence of events. Run DDCRappManager from home and be able to support
clients while being away from the office.
Need to add new database connection to you application. Database connections
are defined in the XML as well. Update your XML file, reset the service, and
that connection is available. No need to rebuild a server application.
Define your owns thread pools so that long running processes do not hog the
primary application threads.
If you are still reading, the bottom line is that we have developed this
product to be efficient in delivering top notch solutions with relative
ease. The other products are great and provide features that may not be
available in ours. However, I believe we have some feature that make our's
and hopefully other's development tasks a little easier.
Thanks for your time and interest. I can provide more information for those
interested. Just drop me a line.
Mark
"Lauchlan M" <LMackinnonAT_NoSpam_ozemailDOTcomDOTau> wrote in message
news:4407cb7f@xxxxxxxxxxxxxxxxxxxxxxxxx
Add 'developer productivity' and you are describing RemObjects DataThere is no reason to "rain" on other vendors announcement. Even the
Abstract.
politician observe this simple rule.
That's true, and I therefore apologise. I think I even did wish him
explicitly good luck with his product.
I wasn't meaning to rain on his parade, I just thought that it would
really
help knowing how he intended to position his product in relation to
existing
products other than DataSnap. What are the advantages? As the marketers
might say, what is his 'unique selling proposition'?
But as you say, it's not my business to help him articulate his message so
.
. .
<. . .exits stage right . . .>
Lauchlan M
.
- Follow-Ups:
- Re: MIDAS/Datasnap Alternative
- From: Tom Klien
- Re: MIDAS/Datasnap Alternative
- References:
- ANN: MIDAS/Datasnap Alternative
- From: Mark Annulis
- Re: MIDAS/Datasnap Alternative
- From: Lauchlan M
- Re: MIDAS/Datasnap Alternative
- From: Femi Fadayomi
- Re: MIDAS/Datasnap Alternative
- From: Lauchlan M
- ANN: MIDAS/Datasnap Alternative
- Prev by Date: Re: ANN: 75% off on Database Workbench, only 3 days left!
- Next by Date: Re: XML parser components for Delphi 5
- Previous by thread: Re: MIDAS/Datasnap Alternative
- Next by thread: Re: MIDAS/Datasnap Alternative
- Index(es):
Relevant Pages
|
|