Re: WebObjects, EOModels, and EAI
Re: WebObjects, EOModels, and EAI
- Subject: Re: WebObjects, EOModels, and EAI
- From: Clark Mueller <email@hidden>
- Date: Sat, 1 Oct 2005 15:26:22 -0600
to achieve such a system you need a lot of time and a lot of
resources. For what do you want to create such a sophisticated
architecture? I mean, sure, its would cool to have something like
this but this is very complex. I know some people, formerly worked
for apple with webobjects who had such an architecture in mind,
with enough money and such things but they stopped working on the
idea after 1 or 2 years.
I figured as much - however, I'm going to give it a shot anyway. I
definitely don't have Apple's kind of resources to devote to my
attempt. Time I do have, as this is more of an experiment, at the
moment, to see what I can achieve, and to hopefully make it easier
for me to re-use code I've written in different contexts, as opposed
to just wrapping great globs of dependent code into Frameworks and
taking them from project to project.
That having been said, I don't really *need* something huge here.
Perhaps even something like what you describe below - building
relationships at runtime; if module X is registered, relate entity X
to entity Y in module X instead of in its own module, or something
like that.
Separating the eomodels means you need to build the relationships
at runtime. No big deal but it makes things more complex.
Can you point me to where I might find some documentation on that? I
see some things pertaining to relationship in the EOEnterpriseObject
docs, but I don't see how it would be modified.
You could start with D2W: create a framework for each module, write
the rule system and add components. Create a basic architecture in
your database for lets say menus, use XSLT in order to get more
flexibility for the layout.
This is an interesting idea - I like it; I'll have to research that a
little bit. I have only limited D2W experience so far.
I've created such an architecture for an asset management system.
It works pretty well but its not cross language. But the more
deployed platforms the more complex it gets to create the updaters
for the database structure and such things. Its really hard to keep
everything up and running.
Well, to be fair, I think most of what I would build would be WO-
based. I would just like to leave the window open for primarily a)
Java-based adaptors to other systems (i.e. the adaptor would be the
module), and b) a SOAP-based interface to the message bus would
probably be sufficient, allowing an interface to it from basically
any other language.
If you want, describe in more detail what you want to achieve,
maybe i can give you more hints.
I think the above refines my thoughts a little bit more. I'm not
*exactly* sure what I'm *looking* for, but I think that better
outlines what I want to achieve. Do you have any thoughts on what the
message bus architecture might look like?
regards, David
Thanks, you've confirmed some of my thoughts thus far.
Clark
Am 01.10.2005 um 21:15 schrieb Clark Mueller:
Hello all,
I am curious as to some of the suggested means of approaching the
particular task I am currently tinkering with. In a nutshell, I'm
attempting to design something that presents complete and total
modularity amongst itself. As I see it, my requirements are
something like the following:
- Complete modularity; any new module can be developed on the basis
- A message bus should be used; the bus would probably be written
in WO.
- Compatibility among many programming languages should be
supported by the design (although an API for individual
programming languages would be acceptable); the architecture
should not be *specific* to Java or WebObjects.
- I'd like to not sacrifice the elegance of Enterprise Objects and
its relationships - between the models - if possible.
The last point above is what I view as the biggest obstacle to
what I actually want to do. The premise behind the architecture
I'm trying to build is that I should be able to swap out different
modules to build a custom system as the situation dictates. For
example, to build a complete POS, I would put together a customer,
invoicing, accounting, and inventory module. Theoretically, each
should be capable of interacting with one another as if you
entered them all into one EOModel. However, I would like to
separate them for extensibility (suppose I later want to build a
work order system that does no accounting, for example; I can drop
the accounting module and insert one to manage work orders).
Now, in the interest of preserving the power of Enterprise
Objects, I'd really, really like to be able to separate these
things, but retain a relationship between modules' EOModels as
appropriate. Naturally, the main obstacle to this as I see it is
preserving compatibility with non-Java modules (via web services,
or something like that).
I'm reasonably familiar with the mechanics of integrating systems,
and the means used, and the theory behind it. I've also had some
limited experience with actually integrating systems, but only in
*specific* environments. The other thing that is unique about what
I am trying to build now is that I don't want to tie it down to
building the EAI for a specific environment and specific existing
applications; I'd like to make it somewhat generic.
So, I am kind of at a loss as to exactly how I might proceed. Can
anyone give me a bit of insight? Am I SOL when it comes to
preserving EO among modules with this design?
Thanks,
Clark
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40cluster9.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden