Re: Remobjects v KBM

From: C4D - Kim Madsen (kbm_at_components4developers.com)
Date: 02/19/04 

Date: Thu, 19 Feb 2004 12:25:40 +0100

Hi Lauchlan,

Thank you for your input which are valued highly!

> (Talkin' to Kim:)
>
> I'll give a slightly 'higher level' user-experience take on this than Brian,
> from my experience:

> I think RemObjects and DataAbstract is architecturally 'cleaner' in the
> sense in which you start with the relevant abstraction and work down to the
> components and coding. In RO you start with the definition of services, a
> bunch of stuff gets autogenerated, and then you handcode your implementation
> of the service definitions. I know you are going to tell me kbmmw does that,
> and I haven't seen the new wizard for this in kbmmw 2 yet (I downloaded 2.0
> but haven't installed it - I wanted to get my app out the door before
> changing things), but I find this to be crisper in RO.

As far as I have seen, the major difference is actually that RO generates a rather empty service object, which however
is strongly typed. The only code is the stub/skeleton generation and some marshalling code for streaming the properties.
I have however only been looking over other peoples shoulders, and may not have seen all.

kbmMW generates anything from simple service objects (services in kbmMW) which are not strongly typed to very complex
service objects which have lots of functionality in them, and for which the wizard allow the developer to setup all
sorts of things, not to have to code much or in many cases anything at all.

And as you also figured, I see that in both cases the point is to architecture the structure of the app. server, and to
abstract things. RO does it strongly typed, kbmMW generally not. However kbmMW automates lots of stuff even from the
designtime point.

We have screen shots available of the kbmMW v2 service and db adapter wizard on out site
(http://www.components4programmers.com/products/kbmmw/screenshots.htm) in which you will see that the wizard takes care
of rather many things.

Our wizard was from v.0.9x designed to be handling code reuse in an easy way.
Thus you will notice the service administration pane, in which services (service objects) are listed. New service
objects can register themself automatically to appear in the wizard and thus be easily reusable. In kbmMW v2 we extended
the wizard to allow for service plugins. That is a framework which allow the developer to easily add new automation
stuff for new custom wizards.
Hence if you have a situation where a new special service object has been created which should pose as a base for other
custom business objects within a company or department etc., and you want it to be easy to developers to fill out
properties, add needed components, links etc. and in general aid with creation of the new business object, you can make
a small plugin in an hour or so which will do that and thus ease the life of the fellow developers.
A couple of examples are shown in the screenshots - The file service, the java service and the query service.

> In DA, you start with
> defining the data connections and data definitions 'datasets' you are going
> to use. (Although I have not yet got my head around how to start with the
> abstract data definitions and map them to the actual data sources. At the
> moment I do it by dragging from actual sources in the schema modeller, so if
> anyone can tell me how to start with defining the data at an abstract level
> and _later_ map it to actual data sources I'd appreciate that!) and then the
> business processors (like kbmmw resolvers) and data tables (like kbmmw
> client query components) follow from that.

Ok.. I can see this as an interesting new designtime tool for kbmMW... drag and drop of queries etc. from a datasource
repository, automatically creating the components needed. Actually the wizard have a good part of that already, but it
doesnt let you define the SQL at that time. This is done at a later stage.

> Both the server side and client
> side things follow from the abstract definition you start with, whereas in
> kbmmw you choose appropriate server side and client side components and
> hook/code them up appropriately. So architecturally, it does not seem to me
> to be as driven by the central abstract definitions (of data, services).

Well.. in kbmMW I suggest people to not use client side SQL of abstraction reasons, but instead use what has been
defined on the server using the named query setup. The client can even poll the server to get information about what
named queries are available, and can then request their definitions. Hence its defined serverside, unless people
absolutely want to do it client side which kbmMW also supports. I can see however that I might want to create a couple
of pull down menus to make named query selection (by listing server side published named queries) easily available
during designtime. Noted.

> Another area where from a use-point-of-view the RO/DA architecture shines is
> in its 'wizards', particularly the service builder and the schema modeller,
> which allow you to specify your application on an abstract level very
> cleanly before diving in and coding.

As I mentioned I have only looked 'over shoulders' but isnt it basically a TLB type editor with a rather basic code
generator?

> I know kbmmw has wizards that one might say does similar things, but I think
> that there are differences. I think for example that in RO/DA abstraction
> tools allow you to specify the datasets at an abstract level, and this
> abstract definition drives the development of other parts of the app
> architecture in a very OO way, for example one can hang middle-tier business
> logic off these abstract definitions of the data.

Im not sure I understand. What exactly is the abstraction level of the dataset? Is it query statement placed in a
stringlist type of thing?
Then you select the appropriate query statement for the appropriate task for the appropriate components?

> FWIW, my experience is that there seems to be your (Kim's) support, which is
> excellent, and three or four power users who are also very helpful, but like
> Brian, I haven't noticed a formal 'team kbmmw' or 'team k' or specific kbmmw
> paid support employees on the kbmmw ng's. I'd be interested in more details
> here as well!

The C4D site specifies a team of kbmMW gurus. You will often see the majority of those people on the newsgroups.
Then we also have a partner team of which you occationally also see those in the NG's.
We dont have a rule that people have to add 'Team kbmMW' or something to their posting names and thus you may not notice
it.
The point is not if a 'label' can be put at specific people, but rather that support is given in a timely and competent
fashion,
and Im sure nobody can claim otherwise about all our very competent supporters on the NG's.

> Also, who is your person in Australia (if one of your 5 people is here) and
> where (which city) is he/she?

We unfortunately dont have any partners in Australia, although we have quite many customers from there.
Thus we would ofcourse seriously be interested in getting an Australian partner. 

-- 
best regards
Kim Madsen
kbm@components4developers.com
www.components4developers.com
The best components for the best developers
kbmMW - kbmMemTable - kbmWABD - kbmX10