Re: Remobjects v KBM

From: Lauchlan M (LMackinnon_at_NOSPAMHotmail.com)
Date: 02/19/04 

Date: Thu, 19 Feb 2004 11:01:38 +1000

> > Again curious :) In what respect is it cleaner?
>
> Things like: Invoker/Dispatch architecture for RPC, use of factories for
> service creation, ability to support multiple transports simultaneously
and
> easily. In general, looser coupling with the same or greater degree of
> cohesion. These things are hard to quantify as they are due to aesthetics
> rather than hard/fast things. I didn't take notes when I was looking, but
I
> certainly can if you'd like me too. =)

I am curently using kbmmw for a commercial product and have spent some time
learning Remobjects/Data Abstract, which I also intend to use in a future
commercial application.

(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. 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. 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).
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.

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.

(back to talkin' to the group in general:)

Anyway, like I said in other posts, I think kbmmw and RO/DA are both great
products that will probably do most of what anyone wants them to do. Some of
the strengths of kbmmw include the way it explicitly handles resolving
(although I would like to see additional documentation on this going into
the resolving whitepaper or the kbmmw help file! <g>) and its pricing, while
I think that as Brian says some of the core strengths of RO/DA include how
it prediposes itself to excellent abstraction, and the thought and
innovativeness in its design and architecture.

At the end of the day I think the two products can be thought off as doing
the same thing from different perspectives. kbmmw could be described as
being primarily a dataset oriented n-tier framework, with RO/DA being
differentiated by focusing on a level of abstraction from the actual
physical datasources and having that abstraction drive the app development
in an OO way. I think both products will appeal to groups with different
ways of thinking, ie someone who wants to stay with a traditional dataset
focus will find kbmmw easy to jump into and it will meet their needs,
someone with an OO focus and interested in web services, remoting et will
probably find RO/DA immediately very attractive. The products are also
differentiated in pricing. I think the products are significantly different
so that people should evaluate both themselves, and go for the product that
suits them and their way of thinking and their needs the best.

> > Actually C4D have a support team of 5 people and further have partners
in
> > different places of the world who can handle on site support, training,
> > consultancy etc.
>
> Paid employees or just product advocates/experts (i.e. Team XYZ people)?

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!

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

Anyway, all of the above is just my opinion based on what experience I have
had with the products.

HTH

Lauchlan M

Relevant Pages

  • Re: Extreme!!! Special timelimited competive upgrade offer
    ... I was asked a direct question about why I think a RO user should look at kbmMW, ... Im never going to tell you how you are to run your business, Im sure you know that much better than me. ... have to do all the coding themselfs to support something. ... > customers expect and pay for on top of the technology. ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: RemObjects, kbmMW, Midware or dotNET?
    ... to kbmMW license holders with the next kbmMW minor release. ... Server side Java integration. ... Cross platform support over Linux, Win32 and dotNet including both server ... > I have also started getting into Remobjects with Data Abstract, which is an> excellent product, IMO. ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: What multi-tier components to use
    ... Kim's support and the newsgroups were very helpful in moving ... > framework doesn't do things exactly like you want. ... > feels very comfortable to go "under the covers" with kbmMW. ... > near as familiar with RO/DA, but its level of abstraction feels higher ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: Extreme!!! Special timelimited competive upgrade offer
    ... Surely the documentation can always be better and we are continously working on it. ... However the documentation we do have do describe how to use kbmMW in different facets. ... > support the development of their product. ... Actually kbmMW doesnt _just_ have a transport. ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: Remobjects v KBM
    ... > likely find it faster than SOAP. ... but I found that to be a PITA in KBMMW. ... > support dotNet. ... We can only guess about planned dotNet support from the Norse Mythology ...
    (borland.public.delphi.thirdpartytools.general)