<<There are very few tools today that cater to the needs of SOA and
Web services development. I am not here referring to design tools, of
which there are many— albeit not terribly useful. Rather, I am
thinking of true development products. At every step—coding,
debugging, implementation—the unique aspects of Web services are
poorly supported.

Take, for example, coding. Even today there are promoters of Visual
Studio and other tools who still delight in pointing out that a single
line of code can transform a function into a Web service. This
unreasonable trivialization of the difficulty of writing Web services
clouds the issue and makes the problems far more difficult for
managers to appreciate.

Really, saying you can write Web services by sticking a function
between qualifying statements is like calling a celery stalk a
sandwich because you've placed it between two slices of bread. It's
the content that makes the sandwich, and not the other way around.

These functions must be designed and implemented from the get-go as
stateless entities whose design anticipates and accommodates future
changes in such ways that the need for signature modification is
greatly minimized. Services are much like reusable objects and
components in this sense. And while no one doubts how difficult it is
to write reusable classes and components, this same perspective is
still not yet applied to Web services.

The challenge is, in fact, greater with Web services due to the
coarser level of granularity. Rather than small, atomic functions
(compare two strings), whose interface can be worked out in
comparative isolation, Web services not only must integrate with the
current needs of the SOA, but also must anticipate how things will
change. The need to anticipate and preclude change at the signature
level must be deeply respected for fear of falling into Web services
hell—where there are thousands of services that are all slightly
different due to the evolution of the architect's understanding of
business needs.

Debugging is another neglected problem. With monolithic programs, you
can step through code, review the calling stack and do all kinds of
things to find out why a value is incorrect. In SOA, the error often
occurs on a remote system, possibly even a system several hops away
from the service interface you're accessing. Debugging now requires
capture of a tremendous amount of state information and visibility
into remote systems. And that visibility often entails the
participation of developers working on those systems to help track
down the problem. Oh, joy!

One company that is addressing some of these issues is Mindreef,
developer of the widely admired SOAPscope Web services testing and
diagnostic software. Its recently released Coral development platform
attacks many of these development issues head-on. It's definitely
worth evaluating for nearly all shops working SOA.

There is an additional problem, though, that Mindreef does not
address. How do you know what a Web service does behind that
signature? Putting aside the trivial examples, Web services in IT can
be segregated into two broad categories: data fetching and
transformation and decision services. The latter category refers to
services that, for example, accept a mortgage application and return a
yes/no decision or other evaluation result.

Often, these services are highly complex and rule-based. The question
is, how does the owner of the service know what it does exactly?
Likely, he or she can't know the details without consulting the
developer. So then, how is this service properly described in a
directory? Moreover, how are updates to the inner workings handled,
and how are those changes reflected in directory entries?>>

You can read the entire article at:

http://www.sdtimes.com/article/column-20060401-01.html

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/
 


Reply via email to