Todd - Absolutely. Another good way I've heard it explained about when it's best to use a service vs. an object or other mechanism for sharing/reuse is when the goal is to share data across or among disparate applications or software domains (by domain I mean something like Java/JEE or C#/.NET, CICS, CORBA, Tuxedo, Forte, etc.).
If what you're doing is building an application using software all in the same domain it makes more sense to reuse things using that domain's artifacts than try to use something designed more as generic data definition and interface/interop technology (i.e. XML and Web services). Makes sense to me. Eric --- Todd Biske <[EMAIL PROTECTED]> wrote: > One challenge I've faced when discussing reuse is > that not everything > that is reusable should be a service. In fact, most > of the reusable > items that come to mind fall into two categories: > 1) Things that belong in a reusable class library. > After all, two of > the best examples of reuse are the rich > functionality provided by > the .NET and Java EE frameworks. > 2) Things that should be externalized from the > application and be > implicitly executed through declarative policies. > As a later post > already pointed out, this gets into the world of > aspect-oriented > programming. It also is well suited for SOAP > mediation, as Anne > points out. > > SOA doesn't necessarily have to be about reuse, > although it is a > benefit. I'm a huge proponent of reuse, but I also > think the more > important factor is to place interfaces at the right > places so that > the units of work can be combined in new ways in > response to business > change, which may imply turning the old ways off. > The logic still > remains, we've just combined it in a new, > interesting ways, however > it may still only be used in one place. > > The items that Anne called out are all good starting > points. Just > don't automatically assume they should all be > implemented as > services. In some cases, these infrastructure > capabilities should be > external services, in other cases, an > aspect-oriented approach or a > class library may be the best choice. > > -tb > > > On Mar 2, 2006, at 6:25 AM, Anne Thomas Manes wrote: > > > The advice I give to my clients is to start their > reuse efforts > > with infrastructure functionality -- things like > authentication, > > authorization, auditing, cryptography, logging, > monitoring, > > caching, etc. One of the things I like best about > SOAP is that it > > enables clean separation of infrastructure from > business logic via > > the SOAP mediation model. > > > > This approach brings two advantages: it is > something that can be > > done reasonably well by an IT group without a huge > amount of > > collaboration with all business groups that will > use the services, > > and it gives the IT group more control over policy > enforcement. > > > > One of my clients (a Fortune 50 financial > conglomerate) estimates > > that 30% of its current IT budget is spent on > infrastructure > > functionality -- which currently is reimplemented > in every > > application. By externalizing this functionality > into reusable > > services, they could potentially save hundreds of > millions of > > dollars a year. They would also have much better > control of > > security and management, and they would ensure > much more consistent > > enforcement of policy. > > > > Another sweet opportunity for reuse is in response > to government > > regulations. For example, anytime someone requests > to open an > > account, a financial institution is required to > check a government > > database to ensure that the person is not a known > financeer of > > terrorists. Rather than implement this code in > every line of > > business for every type of account, this code > should be implemented > > as a shared service. > > > > Anne > > > > On 3/2/06, Keith Harrison-Broninski > <[EMAIL PROTECTED]> wrote: > > Alexander Johannesen wrote: > > On 3/2/06, Keith Harrison-Broninski > <[EMAIL PROTECTED]> wrote: > > > You read a lot about enabling service re-use, > but very little > > about organizations that > > > actually achieve it on anything beyond a trivial > scale. > > > > I guess for this sentance to work, you need to > define that scale. > > Number of applications using the service? > Transactions per second? > > Business importance? > > I was thinking about the first of these, which I > would rephrase as > > the "number of services that are used in more than > one process". > > As I wrote in the last email: > > > >> are many services ever used in more than one > process without > >> significant change? > > Some more on this theme ... > > > > I spent some time in 2001 working with a software > house that was > > building a life insurance application out of > components, which > > interacted via Web services. This application > had to be generic - > > i.e., in principle be usable by any company > selling life > > insurance. So it was a testbed not only for SOA > technology (since > > this was early days for SOAP etc) but also for SOA > principles (in > > particular, enabling service reuse). > > > > What they ended up with is a set of services that > were > > fantastically complex to invoke. To hook them up > into a useful > > process, you needed not only to have a very strong > grasp of life > > insurance (the sort of understanding an actuary > has) but also of > > their particular approach to application design > (what all the > > complex types were for, and what their various > nested fields meant). > > > > Now, I didn't have much to do with the design of > their application > > (I was building a particular one of the > components, for process > > modelling and execution, not specific to life > insurance, that > > eventually became RADRunner), so I am not > qualified to say whether > > or not they could have done things differently. > But I suspect that > > there may be a general problem here - particularly > since my > > experience with ERP, described in the last email, > shows the same > > forces at work. > > > > Stepping back for a moment, the use of patterns > and refactoring has > > been revolutionizing software design across the > board for about 10 > > years now. But these techniques do not help make > software simpler, > > just better structured. And perhaps software > cannot be made > > simpler, since in the end it has to reflect the > real-world uses to > > which it will be put. So I think it is very hard > to build services > > that are genuinely re-usable in many different > processes - not > > impossible, just hard - and I wonder: > > How many organizations are doing it on more than > an ad-hoc basis > > What sort of services they have made re-usable - > are they very > > simple? very complex? somewhere in the middle? > > Whether the financial investment in making these > services re-usable > > was worth it. > > Anyone got any figures? Or tales to tell of > service re-use in > > unconnected processes? To my mind, there is a > fundamental axiom of > > SOA that needs examining - that service re-use > gives ROI. I > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 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/
