new 8 core concepts, with or without Siebel

This is a major update! I changed the order a little, to reflect Siebel thinking, and OR/OU mapping/binding thinking.
-------------------------------------------
-------------------------------------------

(Note: I merged "logging" together with aop logging, and moved it to aop logging)
1. "OR mapping" (including "UOW", Unit of Work, equiv. to Siebel's BO)

(Note: I moved UI here; I added two new items to it, to expand the concept of OU mapping: "O", "OUmapping")
2. ("O") "entity": rules in entities, rules engine, scripting in entities
3. ("U") "Web2 UI": ("ActiveX" and "Ajax")
4. "Data Binding" ("OU mapping")



5. "transaction" (and non-transaction, with "facsades" and "workflows") (business service and workflows, tasks)
----------(I merged "unit testing" together with "transaction")

6. "networking (at application level, as "connected applications")"

--i. async (it uses direct also) EAI (background) "messaging" for integration and need "user push notification" (activities? or an area on every screen???)

--ii. batch EIM

--iii. offline web client

--iv. reporting server

7. "logging (that is runtime-configurable)"

8. "security"("authorization" and "authentication")

Mashing up integration UI, service UI, and application UI -- the final reason why web is better than smart client and hence ajax is the key

Mashing up integration UI, service UI, and application UI -- the final reason why web is better than smart client and hence ajax is the key.

First of all, application UI means application itself!

As I pointed out in my previous posts, webmethods' philosophy is interesting but perhaps too radical: we should put application UIs in integration platform (e.g. webmethods), instead of application platform (e.g. M$'s Visual Studio).

I put some thinking about it. Actually, this does not need to be that either/or. As long as you use web, it is just a link away. So, I guess webmethods's philosophy is indeed unnecessarily radical. As long as it is web, who cares.

However, webmethods's philosophy does make it clear that web is the key; further, in order to make it interactive, you need to use ajax.

This also means, "service architecture" and "application architecture" are the same thing, exactly identical, synonym.

Getting deeper into Siebel while keeping everything in perspective

Getting deeper into Siebel while keeping everything in perspective

I am getting deeper into Siebel.

My focus is EIM ("Enterprise Integration Manager", Siebel's name for batched based integration, including the launch-eve initial data load) and EAI ("Enterprise Application Integration", for Siebel, it specifically means non-batch based integration).

This focus is good for me, because I tend to be curious (or ambitious -- or whatever) about the whole thing ("architecture" or whatever name you use to refer the holistic view).

To avoid getting lost in details, I need to set up the context so that the context will tell me the directions.

The "context" must be "native" to Siebel, as a result, "spring" is no good: I cannot mention "spring" to Siebel architects, or any Siebel experts in general. In the context of 5th-level-platform, techniques in 4th-level or 3th-level platform are not received.

However, some abstract concepts can be tolerated. for example, AOP and OR mapping. Also, Siebel experts can certainly tolerate concepts already used in Siebel, for example, UI-O mapping (data binding), rules engine, and workflows.

So, the rule is: do not use "spring" to talk about Siebel; however, do insist on using abstract concepts to talk about Siebel. I will update those items often, until they are stable -- I believe those are the keys for learning and applying Siebel. They are the base of my contributions to the design and spec of all Siebel activities.


"OR mapping" (including "UOW", Unit of Work, equiv. to Siebel's BO)
"Web2 UI": ("ActiveX" and "Ajax")
"Data Binding" ("OU mapping")
--
"aop entity rules": rules engine and other rules in entities (BC)
"aop scripting" (synonym for AOP in general, both entity and facade -- scripting is injected by AOP)
---------
"aop security"("authorization" and "authentication")
"aop logging"
"aop transaction" (more precisely, non-transaction, workflows)
"aop network" batch EIM and async EAI (background) "messaging" for integration and need "user push notification" (activities? or an area on every screen???)


The key is that for integration purpose, we need a common conceptual ground -- if we cannot even have a common "conceptware", how can we have a common software!