I happened to attend an interesting Webinar on Modular Services recently and it highlighted the importance of 'service components'. Here is an extract from the webinar:
This Webinar explains how modular "Service Components" enable the quickest path to an SOA maximizing reuse, without having to manage any complex framework for the development or management of the Components.Service Components also enable the development of coarse-grained service components as assemblies of fine-grained components. The webinar can be found at : http://www.fiorano.com/news/webinar_registration_list_110106.htm --- In [email protected], "Gervas Douglas" <[EMAIL PROTECTED]> wrote: > > For those of you who have not read it, here is an extract from an > interesting blog by Radovan: > > <<There has been some debate in the industry on the differences > between Service-Oriented Architecture (SOA) and Component-Based > Architecture (CBA). Differences between SOA and CBA such fine grained > vs. coarse grained, business vs. IT, or high-level vs. low-level are > probably good observations, but I think the main point lies elsewhere. > > At the end of the day, a component can be as high-level, 'business > level', and of the same 'granularity' as any service. Or a service can > be easily as fine-grained as a component. > CBA and SOA are indeed different as they address very different > issues. If you work with components you work with code; while if you > work with services you use some remote functionality over network > under some contract. Composing services into higher-level processes is > totally different story than linking some components together into an > application. A service contract is totally different from a component > interface. > > > Component-based architectures may be very relevant to service > providers, as they might be the way in which a particular service is > implemented. > > The following functions are part of CBAs: > > > Contracts: don't exist. > > Governance: project planning, internal architecture, compatibility of > interfaces, proper usage of open source libraries, testing, etc. > > Impact analysis works with code dependencies, versions - of interface, > language, runtime, etc. > > Policies: Few security and transaction settings within deployment > descriptors. > > Checkout from repository. > > Deployment descriptors parade. > > Compilation. > > Packaging linking into apps. > > Deployment.>> > > You can find this at: > > http://www.webservices.org/weblog/radovan_janecek/why_services_are_not_components_and_vice_versa > > Before you are tempted into irreverence, remember that he is a member > of this Group.... > > Gervas > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
