You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Ahmad Khalifa <ah...@khalifa.ws> on 2008/01/22 15:20:43 UTC
Business Framework Project
Hello,
I wanted to propose a new project idea. This is not a formal proposal,
this just an attempt to see if such a project has a place at the ASF,
and if anyone would be interested in participating.
Note, The project has a working codebase.
The application is a framework for creating business applications.
Unlike some business application frameworks, this one does not generate
Java code or XML, instead it has a repository to store object
definitions, and the runtime interprets those object definitions to
views, records, logic, SQL, etc...
The main advantage to this framework is customization. It is highly
customizable. There are several CRM/ERP/etc. applications out there but
they usually lack in customization features as most of those
applications have hard coded entities with some extra customization
features added on top. What I mean by customization is the ability to
change something via an easy to use GUI. Most of the available
applications can be changed, but they require this to be done by
changing php, xml, jsp, etc.. which is a development effort. What I am
proposing is something at a higher level that gets you thinking only
about entities, fields, views, application logic, user access, etc.. and
IMHO this is important in a business application where your main focus
should be on the business logic rather than 'Did I terminate that last tag?'
Basically, you use this application to define objects that represent
entities, fields, views, picklists, database tables, etc... through the
application's development section, then you instantly go to those views
to see your changes. The definitions are stored in the application database.
The development section itself is developed using the application
itself, i.e. the development section is stored in the database
repository and at runtime its interpreted to views, fields, SQL, etc...
There is also an incomplete CRM-like implementation.
Some key features:
* 3-Tiered object architecture allow re-use
+ Object definitions are separated into 3 main tiers, which are:
--> User interface objects
--> Business Entities
--> Database Tables
+ You can, for example:
--> Reuse UI components in multiple places without extra effort.
--> Reuse Business Entities in multiple UI objects.
--> Reuse database tables in multiple entities.
* Business logic can be implemented in multiple ways.
+ Through object attributes, you can for example:
- Define read only fields.
- Define field data types.
- Define field pick lists.
+ Through formulas (using JSP-EL syntax), you can for example:
- Define field Readonly status conditions, interpreted at runtime.
- Define field value validation formulas. Regex can be used.
- Define field default values.
+ Through Scripting (currently using Rhino JS), you can for example:
- Override events in data lifecycle to perform any business task.
- For example, you can overide when the /Loan Approval/ field gets
set to 'Approved' to verify that the user has enough quota.
* Aggregate entities
+ Define which field to 'Group By' and which one to 'Count' and you
have an entity that retrieves aggregate data.
+ Charts can be displayed from aggregate data (through jfreechart).
* Interactive javascript client, or stripped down wireless interface
+ Through different templates (JSPs created with the framework) the
objects can be made to render javascript-intensive views, or
stripped down versions that are suitable for wireless devices.
+ Both versions would re-use the same entity objects defined.
Ultimately, what this would be good for, is to offer several
pre-built applications along the lines of CRM, ERP, Accounting, POS,
etc... just like some already available applications, but the extra
customization features would make it much more adaptable/extendable to
organizations, and much easier to extend to more business domains.
Well, this is my first stab at it. Comments?
Regards,
Ahmad
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 29 January 2008 07:13, Ahmad Khalifa wrote:
> Well, is there anything I need to know before making the source
> available online? I mean, license-wise?
Are you the only author and owns all Copyright to the material?
If Yes, you have the right to license the code anyway you want.
If No, you need to seek the active approval from all Copyright
owners to license in a particular way.
Assuming that you resolve the above; You should state in source files which
license applies, and preferably provide some form of NOTICE and/or LICENSE
file with the actual license text...
If you choose Apache License ver 2.0, then you can peek into the layout of any
ASF project for more info.
I.e. the most important part is whether you (and any buddies of yours) are the
creator(s) of the original work, and not 'borrowed' without following
licensing restrictions.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 30 January 2008 01:42, Ahmad Khalifa wrote:
> I did what I think is appropriate, but I think there would be a need for
> further review by someone else. Some cases that I'm sure might need
> extra attention would be:
> 1. I'm using GPL javascript html-editor (Tiny MCE). As far as I can
> tell, It's OK to use it, as it resembles dynamic linking.
> 2. I'm using commons-el in source form and performed some changes to
> it. I'm confused as to wether the 2-liner NOTICE file suffices here?!
> Or do I need to remove the apache name from it?!
> 3. I include the MySQL/Oracle JDBC driver. Not sure what to do here.
For review this is good enough I think, and as you mention if/when the project
enters incubation these issues will be dealt with accordingly.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by Ahmad Khalifa <ah...@khalifa.ws>.
The source is available with some instructions on how to build and use.
http://www.khalifa.ws/files/mechanix/mechanix-0.1.zip
Remeber, this is an actual working application, but some features might
be broken for now because I changed the folder structure a little.
Niclas Hedhman wrote:
>> I.e. the most important part is whether you (and any buddies of yours) are the
>> creator(s) of the original work, and not 'borrowed' without following
>> licensing restrictions.
I did what I think is appropriate, but I think there would be a need for
further review by someone else. Some cases that I'm sure might need
extra attention would be:
1. I'm using GPL javascript html-editor (Tiny MCE). As far as I can
tell, It's OK to use it, as it resembles dynamic linking.
2. I'm using commons-el in source form and performed some changes to
it. I'm confused as to wether the 2-liner NOTICE file suffices here?!
Or do I need to remove the apache name from it?!
3. I include the MySQL/Oracle JDBC driver. Not sure what to do here.
Regards,
Ahmad
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 29, 2008 12:13 AM, Ahmad Khalifa <ah...@khalifa.ws> wrote:
> ....Well, is there anything I need to know before making the source
> available online? I mean, license-wise?...
Licensing your code under the Apache License [1] might make it easier
to incubate it later on.
-Bertrand
[1] http://www.apache.org/licenses/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by Ahmad Khalifa <ah...@khalifa.ws>.
Alex Karasulu wrote:
> On Jan 26, 2008 3:50 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>> On Tuesday 22 January 2008 22:20, Ahmad Khalifa wrote:
>>> Note, The project has a working codebase.
>> Perhaps a good first step is to make it publicly available ;o)
> Niclas makes an excellent point, then we can start looking and kicking the
> tires.
Well, is there anything I need to know before making the source
available online? I mean, license-wise?
Regards,
Ahmad
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by Alex Karasulu <ak...@apache.org>.
On Jan 26, 2008 3:50 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Tuesday 22 January 2008 22:20, Ahmad Khalifa wrote:
> > Note, The project has a working codebase.
>
> Perhaps a good first step is to make it publicly available ;o)
>
Niclas makes an excellent point, then we can start looking and kicking the
tires.
Alex
Re: Business Framework Project
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 22 January 2008 22:20, Ahmad Khalifa wrote:
> Note, The project has a working codebase.
Perhaps a good first step is to make it publicly available ;o)
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by Ahmad Khalifa <ah...@khalifa.ws>.
David E Jones wrote:
>> As you mentioned, yes, there *are* various commercial vendors doing
>> this, but no open source has this capability.
> I'd be interested to hear more of what you had in mind for "this
> capability".
The ability to customize anything and everything in the application
at a higher level than Java and XML.
>> Consider a small-medium business that has an ERP system, and one day
>> decides that they want to get a CRM system to track their sales force.
>> Which would be the best scenario of those?
>> (A) - A typical CRM implementation with data migration/integration work,
>> user training, More systems to support.
>> -OR-
>> (B) - A small CRM implementation with no data migration/integration, not
>> much user training, no more systems to support.
>
> You've lost me a bit here.... It is definitely nice to avoid things like
> data migration and integration and user training and support of systems.
I certainly didn't mean that scenario (B) will make the costs Zero. I
meant that with the second system -- CRM -- there will be much less
work to do outside of the implementation of the CRM itself.
>> What do you mean by 'start looking at data modeling'?
> What I mean is actually designing how to store information for things
> like products, orders, invoices, payments, shipments,
> customers/employees/suppliers/etc, quotes, requests, and so on.
Well, thats already done. I have looked at how exactly to model and
extend several business scenarios. Remember, in my first post I
mentioned:
> Note, The project has a working codebase.
> Or is your intent to just create a framework and not get into business
> level artifacts? Don't read too much into that question: that's a very
> common and valid approach and I don't mean to suggest that you should if
> it's not your intent.
Remember, in my first post I mentioned:
> There is also an incomplete CRM-like implementation.
It *is* my intent to build several apps on top of this framework, to
make is easier to implement. That is what I think that this project
could benefit from OFBiz.
>> Are you still skeptical about using database to store application
>> objects? Consider moving the component-load.xml file to the database
>> and having a load-on-demand button somewhere. How much easier would it
>> be for users to activate/deactivate/upgrade components? and no downtime!
>> This would be exactly like Drupal's Module management system.
> I am still skeptical about it, yes. It definitely sounds nice at first,
> but I've been through cost/benefit comparisons for doing this with all
> sorts of different types of data and even tried a number of these
> things. Some things just seem to work better in files and other things
> seem to work better in database records.
Perhaps more details into how this framework does things would help
convince you??
> I think you're looking at going in the same direction that we are with
> OFBiz. That's a great thing to see even if, or rather especially if, the
> approach for getting there is very different.
Yup, same direction.
I'm trying to propose a different approach to doing things that IMO
would be much easier than OFBiz. If you're not sure that the approach
itself would be able to deliver the same functionality, then we need to
discuss that before getting into which is best.
Regards,
Ahmad
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by David E Jones <jo...@undersunconsulting.com>.
I'm not sure if this is the best forum for this discussion, but it's a
good discussion and I also can't really think of a better forum!
So....
On Jan 22, 2008, at 5:31 PM, Ahmad Khalifa wrote:
>> There are various commercial vendors doing this sort of thing. Most
>> are aimed at having doing infrastructure for a centralized ASP-
>> style environment, ie where there is one big application and people
>> build or extend apps through web-based interfaces and everything
>> lives on the server. The ultimate in lock-in, and an nice enabler
>> of over-centralization (which I think most open source proponents
>> realize the danger and downside of...). That's a good motivation
>> for database driven business data structures, logic, screens, etc.
>
>
> What could be considered as lock-in or over-centralization from one
> perspective, could be looked at as being simplifying things or
> reducing
> costs from another perspective.
Yes, the siren song.... From a due diligence perspective the promise
of ease causes a good investigator to be all the more wary of what is
lost in order to get that ease. It's easy to forget that compromises
made in the name of ease often lead to more compromises and eventual
full compromise.
> Think of CRM/ERP/Accounting/Payroll/HR/etc.. just compressed into one
> system, this would certainly promote less Excel sheet usage :)
Agreed, very valuable. This is one of the very important things we are
doing with OFBiz.
> The basic model of having 1 repository of customers is inherently
> better
> than having multiple repositories at several systems, with data
> fragmented allover, and backend migration/integration processes
> running.
This is another thing we are doing with OFBiz. The focus is on a
single architecture and set of lower level business artifacts that you
can build anything with. For companies that can afford the
customization this means they have the ERP/CRM/ecommerce/etc/etc that
they want. For companies that can't afford the customization there is
already a growing set of vertically oriented solutions that are more
tuned for out-of-the-box usage.
> As you mentioned, yes, there *are* various commercial vendors doing
> this, but no open source has this capability.
I'd be interested to hear more of what you had in mind for "this
capability".
> Consider a small-medium business that has an ERP system, and one day
> decides that they want to get a CRM system to track their sales force.
> Which would be the best scenario of those?
> (A) - A typical CRM implementation with data migration/integration
> work,
> user training, More systems to support.
> -OR-
> (B) - A small CRM implementation with no data migration/integration,
> not
> much user training, no more systems to support.
You've lost me a bit here.... It is definitely nice to avoid things
like data migration and integration and user training and support of
systems.
- Realistically you have to pay someone to support systems even if you
don't do it yourself (and this is a good thing to pay someone to do...
hosting companies that have expertise for different apps are a genius
business model).
- The only way to reduce user training that I know of is to have
applications that are built to guide users through the processes the
business wants. That means the applications must be tuned to the
specific business and if that business wants to change it must change
its apps, or at least written for a particular type of business and
leave in a bit of flexibility and require a little bit of training.
- If you have a good, complete system you don't need too many
integration efforts, but some are almost always needed. For example
very few companies do payment processing or shipping on their own, but
fortunately once you have a small set of integrations in place
additional work is not needed.
- If you can find clients that don't need data migration count
yourself lucky! Usually unless you have a new company or a company
that has serious budget limits and can't afford it, you'll need to get
the data from the old system(s) into the new system (hopefully
singular there...).
>> BTW, Compiere actually works more or less this way. Ie, things are
>> heavily database-driven.
>
> Yup, but they're mainly ERP, and they work with Oracle databases and
> some postgreSQL fork. Plus, they don't have the extreme customization
> abilities discussed.
Yeah, Compiere is an "interesting" project. The architecture is mostly
old-school client-server style (ie client apps talking to a database,
the only centralized logic is in stored procedures). There are also
many quirks, as is natural when the design and development is mostly
done by one person. It is admittedly impressive given its background
though.
>> If you get to the point where you start looking at data modeling
>> and the logic tier stuff, feel free to collaborate with us at
>> OFBiz. More eyes on this stuff is always a good thing! Okay, well
>> 98% of the time. ;)
>
> What do you mean by 'start looking at data modeling'?
What I mean is actually designing how to store information for things
like products, orders, invoices, payments, shipments, customers/
employees/suppliers/etc, quotes, requests, and so on.
Or is your intent to just create a framework and not get into business
level artifacts? Don't read too much into that question: that's a very
common and valid approach and I don't mean to suggest that you should
if it's not your intent.
> Are you still skeptical about using database to store application
> objects? Consider moving the component-load.xml file to the database
> and having a load-on-demand button somewhere. How much easier would it
> be for users to activate/deactivate/upgrade components? and no
> downtime!
> This would be exactly like Drupal's Module management system.
I am still skeptical about it, yes. It definitely sounds nice at
first, but I've been through cost/benefit comparisons for doing this
with all sorts of different types of data and even tried a number of
these things. Some things just seem to work better in files and other
things seem to work better in database records.
Of course, with enough design an engineering I have strong faith that
we as humans can make anything work, and work well. In other words it
should be possible to build tools and such so that you get all of the
benefits that are inherent with files (and all of the tools we have
for working with them) with your data stored in the database. BTW, I'm
using the term "data" very loosely there to include code, data
structure info (meta-data), templates, etc.
> Anyway, I really hate the idea of having /Yet Another Framework/,
> but as
> we discussed, there is no open source alternative. This is only
> found in
> commercial applications.
In spite of my biases I am VERY for diversity in approaches and good
efforts to explore the viability of each. I'd love to see other
frameworks developed in the open source world that compete with the
OFBiz Framework. There certainly are many out there, but I mean really
compete and give the tools we're using a good drubbing when evaluated
for productivity in design, implementation, maintenance, and
customization. One of the big metrics there is the volume and
complexity of the business level artifacts. That's where using tools
that are special purpose for business applications provides a huge win
over generic tools, like making everything a Java class.
Eventually one starts feeling something like: "if I have to map one
more thing to an object that isn't anything like an object just to
make it possible for that to work with all of these other things that
are mapped to objects but really aren't anything like an object, I'm
going to lose it!" In that case losing it could mean sanity, but if
often also means flexibility and understand-ability because as
concepts are mapped to something that is not the same, some things
don't make it through the mapping and the capabilities are simply
"lost in translation".
I think you're looking at going in the same direction that we are with
OFBiz. That's a great thing to see even if, or rather especially if,
the approach for getting there is very different.
I don't know about others in the OFBiz community, but for my part if I
see technology that does lead to smaller and less complex business
level artifacts I'll take a close look at it and evaluate other things
related to efficiency and productivity for development, maintenance,
customization, et cetera and if it beats the OFBiz Framework then it's
time to replace the OFBiz Framework.
So, whatever you do, please don't let my comments discourage you, and
I hope they don't come across as too confrontational. I really wish
you the best success with your efforts and I hope that you'll be able
to succeed where so many have failed in really designing and building
something that delivers on this intent.
And I'm guessing you'll agree that doing so in the Apache way with a
focus on collaboration through community building is the route most
likely to get your there.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by Ahmad Khalifa <ah...@khalifa.ws>.
David E Jones wrote:
> The idea of putting all business level stuff in the database is
> interesting, but I'm still a skeptic. You can certainly build revision
> control around it, but how do you get the same combination of off-line
> and remote work along with team collaboration and group effort
> synchronization? I guess you could build that too, ie some sort of
> database sync/merge. I have never done this formally, but based on
> discussions and informal cost/benefit comparison... well... I guess it
> is enough to say that I'm still a skeptic. ;)
Basically object definitions are grouped together in /Projects/. For an
application developer to start working on any object definition, he has
to have the project that they reside in locked. Add to that a 'Project'
import/export feature, and you can have team collaboration.
A typical scenario would be developer A wants to work on the /Contact/
objects. First he locks the project on the DEV server, imports latest
version to his local environment, works on it, exports working copy back
to the DEV server, unlocks the project.
This is also how you would migrate between different environments.
i.e development to production.
Import/Export operations are saved as files on the server
automatically, but in the future, there could be some sort of revision
control integrated with it.
The import/export files are readable XML files :)
> There are various commercial vendors doing this sort of thing. Most are
> aimed at having doing infrastructure for a centralized ASP-style
> environment, ie where there is one big application and people build or
> extend apps through web-based interfaces and everything lives on the
> server. The ultimate in lock-in, and an nice enabler of
> over-centralization (which I think most open source proponents realize
> the danger and downside of...). That's a good motivation for database
> driven business data structures, logic, screens, etc.
What could be considered as lock-in or over-centralization from one
perspective, could be looked at as being simplifying things or reducing
costs from another perspective.
Think of CRM/ERP/Accounting/Payroll/HR/etc.. just compressed into one
system, this would certainly promote less Excel sheet usage :)
The basic model of having 1 repository of customers is inherently better
than having multiple repositories at several systems, with data
fragmented allover, and backend migration/integration processes running.
As you mentioned, yes, there *are* various commercial vendors doing
this, but no open source has this capability.
Consider a small-medium business that has an ERP system, and one day
decides that they want to get a CRM system to track their sales force.
Which would be the best scenario of those?
(A) - A typical CRM implementation with data migration/integration work,
user training, More systems to support.
-OR-
(B) - A small CRM implementation with no data migration/integration, not
much user training, no more systems to support.
> Anyway, the two commercial companies that come to mind who are doing
> things this way are Tenfold Software and Bungee Labs.
Tenfold is similar, they have the same concept of a repository
stored in a database, with multiple applications residing in that
repository.
Bungee labs, are doing something that is somewhat different. From what I
understand, It's a tool that is similar to what MS Visual Studio gives
you when developing ASP.NET applications.
> BTW, Compiere actually works more or less this way. Ie, things are
> heavily database-driven.
Yup, but they're mainly ERP, and they work with Oracle databases and
some postgreSQL fork. Plus, they don't have the extreme customization
abilities discussed.
> If you get to the point where you start looking at data modeling and the
> logic tier stuff, feel free to collaborate with us at OFBiz. More eyes
> on this stuff is always a good thing! Okay, well 98% of the time. ;)
What do you mean by 'start looking at data modeling'?
Are you still skeptical about using database to store application
objects? Consider moving the component-load.xml file to the database
and having a load-on-demand button somewhere. How much easier would it
be for users to activate/deactivate/upgrade components? and no downtime!
This would be exactly like Drupal's Module management system.
Anyway, I really hate the idea of having /Yet Another Framework/, but as
we discussed, there is no open source alternative. This is only found in
commercial applications.
Regards,
Ahmad
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by David E Jones <jo...@undersunconsulting.com>.
On Jan 22, 2008, at 8:41 AM, Ahmad Khalifa wrote:
> J Aaron Farr wrote:
>> Ahmad Khalifa <ah...@khalifa.ws> writes:
>>> Ultimately, what this would be good for, is to offer several
>>> pre-built applications along the lines of CRM, ERP, Accounting, POS,
>>> etc... just like some already available applications, but the extra
>>> customization features would make it much more adaptable/
>>> extendable to
>>> organizations, and much easier to extend to more business domains.
>> I understand it's technically different from OFBiz, but have you
>> looked at Apache OFBiz? Would it be something that team could use?
>> http://ofbiz.apache.org/
>
> I have taken a look at OFBiz. From what I understand in OFBiz you
> create
> your entities, views, db table mappings, and business logic in Java,
> and
> XML.
>
> This approach is much different. It defines those things in the
> database
> and interprets them at runtime from the database. i.e. there is no
> such
> thing as 'Accounts.xml' or 'Employees.java', etc...
>
> I don't see OFBiz benefiting from this at all. Unless they're
> willing to
> do a huge re-write. On the other hand, what this project could use
> from
> the OFBiz project, is the already developed logic they have. It is
> much
> more mature in terms of the already created business functionality.
Being one of the architects of the OFBiz Framework I'm obviously
biased toward that approach in general. It sounds like it would share
some of the same ideals, like working with higher level artifacts and
avoiding code generation. OFBiz is definitely XML-heavy (intentionally
for now... ie until a better alternative surfaces), and has touch
points all over the place to use lower level tools like Java classes/
methods and templating tools.
The idea of putting all business level stuff in the database is
interesting, but I'm still a skeptic. You can certainly build revision
control around it, but how do you get the same combination of off-line
and remote work along with team collaboration and group effort
synchronization? I guess you could build that too, ie some sort of
database sync/merge. I have never done this formally, but based on
discussions and informal cost/benefit comparison... well... I guess it
is enough to say that I'm still a skeptic. ;)
There are various commercial vendors doing this sort of thing. Most
are aimed at having doing infrastructure for a centralized ASP-style
environment, ie where there is one big application and people build or
extend apps through web-based interfaces and everything lives on the
server. The ultimate in lock-in, and an nice enabler of over-
centralization (which I think most open source proponents realize the
danger and downside of...). That's a good motivation for database
driven business data structures, logic, screens, etc.
Anyway, the two commercial companies that come to mind who are doing
things this way are Tenfold Software and Bungee Labs.
BTW, Compiere actually works more or less this way. Ie, things are
heavily database-driven.
If you get to the point where you start looking at data modeling and
the logic tier stuff, feel free to collaborate with us at OFBiz. More
eyes on this stuff is always a good thing! Okay, well 98% of the
time. ;)
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by Ahmad Khalifa <ah...@khalifa.ws>.
J Aaron Farr wrote:
> Ahmad Khalifa <ah...@khalifa.ws> writes:
>> Ultimately, what this would be good for, is to offer several
>> pre-built applications along the lines of CRM, ERP, Accounting, POS,
>> etc... just like some already available applications, but the extra
>> customization features would make it much more adaptable/extendable to
>> organizations, and much easier to extend to more business domains.
>
> I understand it's technically different from OFBiz, but have you
> looked at Apache OFBiz? Would it be something that team could use?
>
> http://ofbiz.apache.org/
I have taken a look at OFBiz. From what I understand in OFBiz you create
your entities, views, db table mappings, and business logic in Java, and
XML.
This approach is much different. It defines those things in the database
and interprets them at runtime from the database. i.e. there is no such
thing as 'Accounts.xml' or 'Employees.java', etc...
I don't see OFBiz benefiting from this at all. Unless they're willing to
do a huge re-write. On the other hand, what this project could use from
the OFBiz project, is the already developed logic they have. It is much
more mature in terms of the already created business functionality.
Regards,
Ahmad
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by J Aaron Farr <fa...@apache.org>.
Ahmad Khalifa <ah...@khalifa.ws> writes:
> Ultimately, what this would be good for, is to offer several
> pre-built applications along the lines of CRM, ERP, Accounting, POS,
> etc... just like some already available applications, but the extra
> customization features would make it much more adaptable/extendable to
> organizations, and much easier to extend to more business domains.
I understand it's technically different from OFBiz, but have you
looked at Apache OFBiz? Would it be something that team could use?
http://ofbiz.apache.org/
--
J Aaron Farr jadetower.com [US] +1 724-964-4515
馮傑仁 cubiclemuses.com [HK] +852 8123-7905
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Business Framework Project
Posted by Ahmad Khalifa <ah...@khalifa.ws>.
Antonio Petrelli wrote:
> 2008/1/22, Ahmad Khalifa <ah...@khalifa.ws>:
>> The application is a framework for creating business applications.
>> Unlike some business application frameworks, this one does not generate
>> Java code or XML, instead it has a repository to store object
>> definitions, and the runtime interprets those object definitions to
>> views, records, logic, SQL, etc...
>
> It seems a lot like Naked Objects:
> http://www.nakedobjects.org/home/index.shtml
> Or "Roma Framework":
> http://romaframework.xwiki.com/xwiki/bin/view/Main/WebHome
AFAIK, both frameworks require you to create a POJO, and edit an XML
here or there. Thats what this application tries to avoid.
I mentioned /this one does not generate Java code or XML/ but, I really
should've said /does not generate, or require you to write Java code
or XML/
Regards,
Ahmad
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
[OT] Re: Business Framework Project
Posted by Antonio Petrelli <an...@gmail.com>.
2008/1/22, Ahmad Khalifa <ah...@khalifa.ws>:
>
> The application is a framework for creating business applications.
> Unlike some business application frameworks, this one does not generate
> Java code or XML, instead it has a repository to store object
> definitions, and the runtime interprets those object definitions to
> views, records, logic, SQL, etc...
It seems a lot like Naked Objects:
http://www.nakedobjects.org/home/index.shtml
Or "Roma Framework":
http://romaframework.xwiki.com/xwiki/bin/view/Main/WebHome
Antonio