On 12/17/07, Mike Edwards <[EMAIL PROTECTED]> wrote: > Joshua, > > Let me see if I can help explain some: > > Joshua Jackson wrote: > > > Thanks for the article. I kind of get idea now. This is what I get from it: > > SCA is a kind of glue code for glueing pool of apps to be used by > > another apps. So our new apps will connect to SCA and SCA will connect > > to these pool of apps. CMIIW. > > Yes, SCA is at one level a way of connecting together sets of components > to build up your overall application. One of the great things is that > you don't have to code any information about what is connected to what > into your code. This is applied as configuration data - and so it > allows the data to be changed without changing the code - and it allows > the code to be reused in different configurations. > > > > > > I don't quite understand. People out there compares SCA with JBI, > > which is an ESB. :( And that's an insight that I get from those > > articles you gave me too. > > > > JBI is largely a way of putting a runtime together - where the runtime > involves components written using different technologies (eg BPEL and > Java). SCA is a way of putting applications together - where there are > potentially components written in different technologies and connected > by different technologies. > > It happens that you could envisage running SCA applications on a JBI > runtime - ie JBI can provide the sort of runtime that SCA applications > can use. > > HOWEVER, SCA does not depend on JBI at all - Tuscany, for example, does > not use JBI at all. Further - SCA can describe applications that aren't > written in Java and don't use a Java based runtime either (eg there is a > C++ runtime in Tuscany that can run components written in C++, Ruby and > other scripting languages). > > One way to look at SCA is that it CAN be used as a programming model for > ESBs. SCA describes the components that run on the ESB and their > connectivity. You can have components that are message transformations > or the selection of a target service based on some rule, for example. > These are the sorts of things that ESBs do. > > That doesn't mean that SCA is an ESB - just that it can be used to build > applications that run on an ESB. > > Is Tuscany an ESB? Well, it could be ;-) - a funny half-answer. > I can do some of the things that an ESB does. But ESBs usually have > specialized component types that do things like message mapping - > Tuscany only has some of these today. On the other hand, anyone can > write new component types for SCA, so that anything needed could be > added to SCA. > > One other point about SCA is that it is about distributed systems - most > ESBs are not like that. In other words, for SCA, different components > can run on different nodes in a network.
Wow. Very nice. Thank you so much Mike. A very insightful explanation that I didn't get after reading several articles. :) > > Is there anything I need to know in order for Tuscany to connect to AS400 ? > > > > You need to know which communication protocol(s) you can use to talk > with the AS/400 - plus the appropriate addresses of endpoints relating > to the AS/400. So, maybe you're using JMS over MQSeries, or Web > services, or ..... Yes. I'm doing a research on that now. I am going to use the Data Queue protocol. I might as well ask IBM for support regarding this. Thank you so much. -- I'm a coder not a drag-n-dropper Blog: http://joshuajava.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
