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
posted by survic at
7:08 PM
2 Comments:
Hi Survic,
For five years, I held the belief that JMS/MSMQ(Messaging middleware) is the best SOA enabling technology because of its event driven ,asynchronous and networking fault tolerance characteristics.
Great. You are working on very advance SOA.
I went to Siebel and Web Method websites. Can you explain how you are using both?
Siebel seems to have workflow editors in place. Then how are you using the Webmothod products?
Thank you,
Vikas
It is not that interesting anymore :-) There is an "adapter" for webmethods-siebel. so, install that in siebel, and you can start to talk to webmethods. The real thing is to understand its async nature, so, if there is an error, it needs to be pushed to siebel user as an siebel's "activity". The problem is that because of its web-based nature, Siebel does not have a stronger notification system (e.g., outlook-like you-have-email notification). Actually, even for web-based nature, you can still do it (poll the server every five minutes -- you can make it server controlled, so that if it is too busy, server can make clients poll less frequent; or/and, for every transaction, you also poll a notification service ... there are many ways to do it. However, siebel is not that advanced of those very basic techniques!).
Webmethods are very advanced, more advanced than Siebel. However, you are not supposed to use webmethods too much, because it is only an integration tool.
However, I am thinking, perhaps we should really accept webmethods' philosophy, integration should really where the application (i.e. UI) happens -- i.e., UI should be in webmethods.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home