You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "gengshaoguang (JIRA)" <tu...@ws.apache.org> on 2007/09/14 09:12:33 UTC
[jira] Created: (TUSCANY-1699) Tuscany vs ESB, how developers
choose SOA platform
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
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Resolved: (TUSCANY-1699) Tuscany vs ESB, how developers
choose SOA platform
Posted by "Luciano Resende (JIRA)" <tu...@ws.apache.org>.
[ 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org