--- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > Please, define "Practical SO solutions" vs. unpractical solutions.
Practical vs. theoretically pure. Accepting that not everything will perfectly fit the guiding principles. Pure SO doesn't allow an unwrapped legacy application to participate in a system solution. Practical SO allows that a legacy application can be a useful component, even if might require more management attention (just an example). The wrapping of a legacy application, to "service enable" it, is an integration exercise--essentially creating an adapter. Another example. Data relationships are often taken to 3NF (or further) when modelling. A pure approach would implement the 3NF. A practical approach will violate 3NF for operational efficiency purposes. Such an approach requires more diligence so that the model doesn't fall into a mess. > Iwould not call service aggregation an integration of services. > Service do NOT NEED to be integrated. This gets into defintions I suppose. Strictly speaking, two services that interact are "integrated." An ERP application is often referred to as "an integrated applications" consisting of modules and components that are integrated. This isn't to say I have an extreme view that one method of a class calling a method of another method within an application means they are integrated. *Really strictly* speaking, they are, but noone thinks of it that way. SO is a way to formalize and make more consistent the approach to integration of capabilities. "Separately standing interfaces" is an integration principle, IMO. Services are designed and constructed with integration in mind *up front* instead of as an after thought. -Rob
