[
https://issues.apache.org/jira/browse/TUSCANY-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende resolved TUSCANY-1699.
--------------------------------------
Resolution: Invalid
Is this just a discussion, then it should be moved to dev/user list ?
Similar discussion available at :
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26462.html
> Tuscany vs ESB, how developers choose SOA platform
> --------------------------------------------------
>
> Key: TUSCANY-1699
> URL: https://issues.apache.org/jira/browse/TUSCANY-1699
> Project: Tuscany
> Issue Type: Test
> Components: Java SCA Assembly Model
> Affects Versions: Java-SCA-Next
> Environment: Muti platform, Tuscany, Java, SOA
> Reporter: gengshaoguang
> Fix For: Java-SCA-Next
>
>
> I'm not sure this is a right place to raise this issue, if not, just move it
> to another.
> Once I have been working on ESB for 3 months, it was a sub-task for me keep
> looking for answers of SOA.
> There ARE quite a lot of talks about SOA, and for a very long time,
> developers eye on SOA as a bright future, some one even see SOA as
> mysterious. In China, big software makers like to tell their customers they
> are SOA, it seems SOA has been a flag of technical pioneer.
> SOA starts from Web Service, but WS has been walking on the road for ages,
> SOA did no more works than integrators between systems. But now, definitly,
> SOA should play more roles than that.
> ESB came over on the bases of EAI, ESB improved EAI to SOA like, before, EAI
> not. ESB makes every thing into xml message driven, xml could be soap
> enveloped.
> from a developers point of view, ESB gives the following prospect:
> 1. A very common interface which makes every thing works as send+receive, but
> this just make things too loose, before, compile will find a lot of errors,
> but now not;
> 2. A single access point plus a message router, in these case, service
> consumer only need to post their request to this single point, and the router
> could analyse the requesting message, and deliver it to a right dealer /
> service;
> seems cool? Not really in fact, this could cause more jobs and errors,
> route map need define, some times messages changes and errors came out, you
> just don't know from whick sector;
> 3.Extension becomes easier with standard like JBI, developers could extend a
> ESB (if it is JBI compatible) with new feature on the bases of JBI, JBI is
> message bases, this extension work IS confortable;
> 4. ESB seems able to host a great deal of services, but the bigest problem is
> without a transaction support, (Tuscany too);
> 5. ESB has not give a solution of security, (Tuscany too)
> 6. I have tested ServiceMix, the performace is another headache, we got only
> 1/5 of a common tenology based system. I did not make such a comparison with
> Tuscany, but from the archtecture's view, Tuscany is faster of course. A ESB
> need to transfer xml for each sector to finish a process ring.
> 7. ESB is much more well known, and almost all the platform vender advertised
> their product "ESB enabled";
> to be continued...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
