EDA/ESB is SOA2: Why fine-grained SOA is good and ESB-based UI is good

EDA/ESB is SOA2: Why fine-grained SOA is good and ESB-based UI is good

------SOA2: As I pointed out in my previous blog, the key of SOA is nothing but EDA/ESB/MOM. As a result, we should say that all those SOA hypes are just "warming-up round, or, round 1" of SOA. The real SOA, i.e., SOA2, is EDA/ESB/MOM.

ESB is MOM with a "service" interface, instead of "proprietary" interface (e.g. JMS. Note that JMS is a standard; however, it is too narrow, so, it is "proprietary" in the big schema of things).

------Fine-grained SOA: because at ESB level, we can do so many things, for free. So, we should make service fine-grained, that is, as fine grained as practically possible. Will that slow down things, like early days of COM or EJB? Ya, but that is where "practically possible" counts.


------ESB-based UI: Some ESB vendors (e.g. Webmethods) put UI support above ESB. It is a powerful concept; we should discard "proprietary UI" (M$'s VS or Java IDEs; of course, except the ones with ESB-based UI -- e.g., Webmethods uses Eclipse for its ESB-based UI), and replace them with ESB-based UI.

(a) Advanced web2/Ajax based controls for free (if you buy the product, of course!).
(b) It makes look-and-feel more consistent.
(c) It enforces SOA: you have to use SOA2 now.

(d) However, note that a good ESB can support using proprietary UI, and still provide all ESB benefits. Actually, it is more an issue of the IDE of the proprietary UI: you can put the service in ESB, and then, in your proprietary UI, you call the API from the ESB. As you can see, there is no reason not using ESB-based UI!

SOA, EDA, JMS, ESB, webmethods

SOA, EDA, JMS, ESB, webmethods

The real deal of SOA is not XML, contracts etc. crap. The real deal of SOA is JMS (MQSeries etc). Messaging is fine, but people say email is messaging, and also all other web service as messaging. You can say async messaging, but in JMS you can use sync. Some new name is EDA (event driven architecture), ESB (enterprise service bus) EMB (enterprise messaging bus).

WebMethods is the only company that has been working on this and ONLY working on this, as a result, it is a good source for this vision.

The key, however, is from JMS practices (and in turn, MQSeries practice): if you push, then, you need to consider push failure, so, you need async messaging.

Just in case, I am not trying to sell webmethods. As a matter of fact, above I just pointed the way to avoid the expensive stuff: as long as you have a simple queue (either database table, a file, or MSMQ) to handle failure, and you have a mechanism to recover the failures (either automatic or manual), then, you are fine. Who needs expensive software packages! -- I study them because they are "free" to me (I mean, the company bought it!), and also, I learn those full-fledged stuff simply to see how I can accomplish the same thing with plain old code, perhaps just 10 lines!!!

--------------
Great people think alike and the same time :-) Here is a link to Vikas's blog:

http://vikasnetdev.blogspot.com/2007/09/soa-and-business-intelligence.html

more siebel notes later

My previous blogs are just the first round of my Siebel notes.
I will put more siebel notes later. As I explained before, I used spring to see internals of Siebel and to see how siebel can work with other systems; and I use siebel as the source of architecture best practices (like OR mapping, rules engine, etc.).

siebel internals and integration: spring

siebel internals and integration: spring

This post is really short: why we need to think about spring when we do siebel? because siebel is "third-party", we do not know its internals. Spring can provide insights.

Spring is the "standard" best-practice framework on both C#/.net and java, so, it is the best reference for integration also.

stored procedures on oracle -- more words

stored procedures on oracle -- more words

-----------------how (this should be a very simple system, because we do not use them that often -- but when we use them, we really need them immediately, so, the how should be lightweight and can be done everywhere! see "when" below)


For Oracle SP, the key is how to debug or test a sp easily:

1. It is crucial that we develop sp using both sqlplus and other query tools (e.g. toad, even the "simplified" toad). --- More secifically, we need to get used to test-run a sp in "simplified" toad.

2. It is also crucial to "print out" things, using exception and a adhoc table.



-----------------when
1. They should not be used in routine, ordinary, everyday-practice situations.

2. If you really want them (for consistency sake, or, for people who are used to use sp as a managerial control tool), only use simple CRUD. Do not try to use "data logic" to cover up putting "business logic" in sp. "Data logic" is only an optimization issue; so, there is no such a thing as "data logic".

3. SP can and should be used to optimize some logic when necessary.

4. Also, for some aspect of business logic that is already well-isolated (i.e., will not likely to be re-used), and it is pretty low-level, then, we can say they are "data logic" -- but again, there is no such a thing that is wide-spread layer of data-logic!, and we can do it in sp.

A pragmatic piecemeal route towards Ajax and silverlight

A pragmatic piecemeal route towards Ajax and silverlight

1. No third-party controls, e.g. no ComponentOne
--If really need it, just use the a few controls in a limited places that you really need them (e.g. calendar).

Why? because they simply trouble. Up-front trouble, in development trouble, support trouble, and upgrade trouble. Trouble.

2. Instead, continue to use M$ "build-in" controls.
(a) However, use more "check boxes" to increase user interactivity features (so that it is obvious that we need ajax!
(b) Also, begin to use javascripts: do not use them all at once; however, use them seriously. Do not just hack them. Before you know it, you will have a lot of javascripts, and people get used to it.

-------------------
3. Introduce M$ Ajax server controls; however, use them judiciously, not large scale and systematically. Use them only to make people used to ajax.

4. Use client side library (the best, ext and yahoo), but wrap them using server controls yourself.

5. If you can use alpha in some environments (i.e. not "mission critical"), use silverlight as the primary technology (hence, javascript is only the glue, not the primary language).