Re: [service-orientated-architecture] Kelly on SOA Reuse

[Eric Newcomer]

Yes, this is right, but how many services do you need to have to justify the investment in registry/repository technology based on UDDI?

 

Certainly you can prove the benefits of reuse with a single service, especially something core to a business such as a rating or pricing engine, currency exchange calculation function, or customer data consolidation. 

 

If you start small, identify an important service to reuse, and check the number of applications that actually reuse the service, you can get a good handle on the potential benefits of a larger SOA without having to invest a lot up front.

 

At a certain point a registry/repository becomes important, but it is not actually or specifically required to prove the value of reuse.  Reuse is something much more fundamental than a registry/repository. 

 

To put it another way, just having a registry/repository to list services does not mean those services are being reused or will be.

 

Eric

----- Original Message ----
From: Gervas Douglas <[EMAIL PROTECTED]>
To: service-orientated-architecture@yahoogroups.com
Sent: Friday, November 3, 2006 10:36:50 AM
Subject: [service-orientated-architecture] Kelly on SOA Reuse

<<With SOA, the work begins when a development team starts to create a
new service—but the work actually starts once that service is
successful and the team needs to find efficient ways to support that
service across multiple applications and across different projects
throughout a company, coordinating updates, providing support, and
ensuring consistency and quality over time and over different forms of
deployment.

As a result, SOA development isn't just about development. It's also
about collaboration and lifecycle support. Doing SOA right requires
taking the longer view with an understanding to not just how services
will be used, but re-used. You also need to understand what it will
take to actually support, service and upgrade those services as they
fan out across a distributed organization.

For example, a developer or business user may be using a service that
was created by another department or IT group. What happens when they
want to report a problem with it—theoretically they would contact a
support engineer who would help them capture the environmental
artifacts that can reproduce the problem for the developers or testers
to verify against and fix. The service developer would come in and fix
the service, run it through testing, and then release an updated
version. The challenge is capturing all the relevant information for
that process (and others) in a consistent and usable manner so that
different production teams and users are operating effectively and
efficiently.

In other words, it's the SOA lifecycle and reuse challenge. Let's look
at what it takes to meet the SOA lifecycle challenge and make services
reusable. Service oriented architectures require services, and to use
more than one service you need to have a way of keeping track of
services. Reusing services requires the ability to find, identify and
use pre-existing services. Hence the rise of SOA service registries.
SOA registries are services which themselves keep track of other
services. Organizations can use service registries based on web
services standards such as UDDI to help them identify and connect to
appropriate services for their needs. It's the initial step toward
creating an environment where services can be re-used.>>

You can read this blog in full at:

<http://www.ebizq. net/topics/ soa/features/ 7394.html>

Gervas

__._,_.___

SPONSORED LINKS

Computer software	Computer security software	Computer software program
Computer fax software	Computer virus software

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___