I think that it is beneficial to differentiate two levels of reuse: SW level and Service level. SW reuse is SW implemented functionalities and best technology is Component technology for requirment of being in network computing environment. Service reuse is business processes enabled by service technology accessible to a wide audience. Data access/mamangent, for example, should be treated as reuse at SW level not at service level.
Therefore Service technology built upon component technology will provide the convenience to classifying different levels of reuse and improve performance. As for nonreusable services, my question is that are the services reusable in the future? if not, can SW instead of service component do the job? Jerry --- Brian Mikesell <[EMAIL PROTECTED]> wrote: > Thank you both for your feedback. I think we're > mostly in-line with > what you say. Our approach has been top-down and > bottom-up meeting > somewhere in the middle where we'll use flexible > layers to marry up > business services to technology-enabled service > components, probably > using BPEL in that flexible layer. We have a group > that's focusing > on business modeling at the top which leads to a > solid business > service portfolio. This portfolio is viewed as the > sweet spot as it > should provide us the most reuse and benefit to the > business. At > the same time, we're determining how to enable > existing assets for > reuse (which is what my original post was > targeting), knowing that > these cannot always be considered services. > > This discussion has initiated more questions in my > mind which I'll > pose under a new subject. Thanks for the feedback. > > Brian > > > > --- In > [email protected], > "Anne Thomas > Manes" <[EMAIL PROTECTED]> wrote: > > > > A big +1 to Steve's comments. > > > > Keep in mind that not everything needs to be a > service. Only > reusable > > functionality should be implemented as a service. > Also keep in > mind that > > integration is not the same thing as > service-orientation. > > > > Integration focuses on bridging application silos > and, in the > process, it > > reinforces the silos. Service-orientation focuses > on refactoring > duplicate > > functionality into shared services, which breaks > down application > silos. > > > > Obviously you can't refactor your entire > environment overnight, so > you will > > be forced to do a fair amount of integration while > you are on the > path to > > SOA. But it's important to establish some > enterprise-level > oversight to > > shepard the SOA initiative. You shouldn't leave it > to individual > project > > teams to make enterprise-wide strategic decisions > regarding what > services > > the business needs. The SOA oversight group should > conduct a > number of > > enterprise architecture activities (e.g., > application > rationalization and > > business capability mapping) to get a better > understanding of the > business > > and its requirements, and it should establish > priorities for SOA > projects. > > > > Anne > > > > On 9/27/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > > > Stage 1: Work out what the business services > should be > > > > > > Too often I've seen companies go at SOA as a > technology solution > and > > > either really struggle or fail with aplomb. > > > > > > Once you understand what you want your IT estate > to look like in > 3-5 years > > > time, the business services it will supply, > their heirachy and > their owners > > > you can then look both at the technical and > integration services > required to > > > support this and the appropriate mechanisms for > communication > between the > > > various different service areas. > > > > > > Doing this creates the big picture and vision > for your > Enterprise SOA and > > > gives a firm base for the technology questions. > It also > shouldn't take a > > > long time (normally upto 2 months). The most > important element > is what you > > > expose, not how you expose it. > > > > > > That said there are a couple of CSFs I've > observed (beyond the > > > anti-patterns > http://www.infoq.com/articles/SOA-anti-patterns) > > > > > > Clearly split into different domains, don't try > and have one ESB > that does > > > everything. In domain elements (often > transactional) need to be > split from > > > across domain (non-transactional) and at least > kept them > separated from a > > > modelling perspective but maybe even from a > technology > perspective too. > > > > > > If you are doing Async, have a big think about > using BPEL as a > > > co-ordinator as Java is pretty poor at Async. > > > Steve > > > > > > > > > > > > > > > > > > On 27/09/06, Brian Mikesell <[EMAIL PROTECTED]> > wrote: > > > > > > > > I'd like to get some opinions on when web > services are most > > > > appropriate in an SOA. > > > > > > > > A little background....I've been charged with > defining an > enterprise > > > > SOA for my company. We're currently defining > the best ways to > > > > enable legacy mainframe apps for participation > in SOA. We have > an > > > > integration architecture in place now for > legacy enablement > that is > > > > a MOM-based solution. > > > > > > > > Our environment is primarily made up of... > > > > > > > > J2EE consumers and providers > > > > Mainframe (CICS, IMS) and COM providers > > > > > > > > So here's my question: As we're maturing up > the SOA stack > > > > (currently at composite services), when do we > expose services > as web > > > > services vs. jms or rmi interfaces? > > > > > > > > My thoughts are: > > > > > > > > - Use standards-based solutions where possible > (eg. SOAP vs. > > > > proprietary message model) > > > > - For synchronous request/response, > non-transactional, use > SOAP/http > > > > - For synch request/response, transactional, > use rmi interface > > > > (through an esb - app server-based) > > > > - For asynch, use SOAP/jms (j2ee is the > strategic direction at > my > > > > company) > > > > > > > > I would appreciate your thoughts. > > > > > > > > Brian > > > > > > > > > === 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/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> 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/
