Just one cent about DB partition, I think different types/brands/configurations of DBs can be used for different partitions, e.g., CouchDB for UI preference persistence, single server MySQL for admin log tracking, large DB2 farm for mission-critical app ...

BTW: some past experience from Telecom industry FYI. Over the years, operators have built lots systems for standalone services (call, messaging, push-to-talk, ...) Nowadays operators realize they need to roll out lots new value-add-services (VAS) with existing service systems (now called Silos) constantly to stay competitive. So lots custom inter-links between the Silos are created, which in the end create kind of "spaghetti" mess. So some vendors propose the idea of Service Delivery Platform (SDP) to remove the spaghetti with a kind of ESB like layer, on top of which you can build new apps smoothly. Simply put, SDP is like SOA for Telecom.

True experience from working with a large operator's SDP initiative: the specs took years for engineers and consultants from both sides to work out, numerous revisions, endless discussions, reviews and debates on data model, domain model, whatever model... The initiative's title changed several time meanwhile, since the requirements evolved overtime with different executives involved ... Finally the consultant phase is complete, and a new contract is signed for the prototype phase (no idea when's the actual implementation).

So I guess it is always a dilemma in the end for large complex system: too hard to draft an overall design satisfying all parties, needless to say implementing it; On the other hand, partitions (silos) are easier to design and build individually, but eventually hard to integrate together to support changing biz logic requirements.

Anyway, I think your approach is better -- at least we can get some working silos instead of piles of specs few can fully understand :)

There are several important aspects to integration. Perhaps foremost are the "pure data" issues that will help or hinder integration. Those are mostly independent of using a single integration DB, or integrating multiple DBs via conforming dimensions, or through other kinds of service or resource approaches.

There may be forces for then using more than one approach, each aided by good data integration.

"The argumentation is actually similar, although maybe not as strong, when it comes to the UI as with the integration database vs. application database. Instead of creating one UI on top of several services, why not let each service have its own UI and then integrate the different UIs with a UI container framework instead?"

I like this thought because it speaks of something that I find to be very powerful. The Jini ServiceUI mechanism defines the mechanism for registering one or more "UI" implementation with a service's registration in the Jini lookup service. These can be added by third parties based on security controls on the LUS. So, you can add a UI to something that you didn't write, but which you do know the service interface definition for.

A ServiceUI is a UI, not just a GUI. Because it is mobile code, it can be downloaded and instantiated on a client that needs a particular style of implementation. If you need XML document interactions, but the service just has java objects, you can do that. If you need JDBC access but the service just has XML you can do that too.

It encourages layered integration techniques by making it part of the system design, from the start, to enable such things.

Of course the ServiceUI documentation only speaks of GUI based details, but it can be used to recast a service from one interface model, into another for any "user" whether that's a chunk of code or a person etc.

So I guess it is always a dilemma in the end for large complex system: too hard to draft an overall design satisfying all parties, needless to say implementing it; On the other hand, partitions (silos) are easier to design and build individually, but eventually hard to integrate together to support changing biz logic requirements.

Anyway, I think your approach is better -- at least we can get some working silos instead of piles of specs few can fully understand :)

These words are the best to express our inability to deal with the complexities in large enterprise custom solution space. Nobody was able so far to provide a SOA-only programming paradigm which could have been the solution to this silo problem. It would have even beeen impossible to achieve the acceptance of such a one and the history is the best proof of that. ALGOL 60 was an absolutely forward looking programming paradigm nevertheless COBOL was the dominant one in the enterprise application space for not less than three decades.

There never was the kind of commercial support for algol 60, in the era it would have been most useful, like there was for cobol when it was needed. Cobols readability and support for reporting was what businesses needed. Algo 60 never had anything close to that.

In programming language development, we constantly have the problem that most languages are developed by individuals with bias and understanding of a very small minority of what the world uses computing power to do.

Languages like the C-language succeed because of simplicity, not because of complexity and large libraries. However, that also means that they create an environment for long lived applications, because you hardly ever can find another language with all the things you wrote, ready for you to just do some simple structured programming to recreate your application.

What cloud computing needs to do is decide on a machine standard and leave it at that. I personally would prefer that the machine be the Java virtual machine, because that would allow dynamic binding and portability and competition in machine performance that would help Java continue to improve with a purpose to serve the users.

If the machine was something like VMWare supported OSes or something else virtual, like that, than we'll continue to struggle with the need for all these crap data interchange mechanisms that completely overwhelm software development.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.