Java Reference
In-Depth Information
the service as the common unit of measure (just as an object-oriented system uses the object
or class as its common unit).
Without services, there is nothing to build on, monitor, or govern, and nothing to execute to
provide your business value. But at the other extreme, one can labor long and hard, produ-
cing a perfectly lovely set of architectural diagrams with little relation to the real world. If
you focus narrowly on cranking out a set of service implementations and forget the architec-
ture—or, more likely, leave it out on purpose while dismissing the “astronaut architects” with
their heads in the clouds—you will not only have no SOA, but you'll have something even
worse. You will have spent considerable time and money over-engineering a solution to the
wrong problem. There is actually a name for this sort of furious work: the anti-pattern known
colloquially as Just a Bunch of Web Services (JaBoWS). In addition, cowboy developers op-
erating without architectural guides can inadvertently cause the business to fall prey to another
SOA anti-pattern: Rogue Service, wherein there are services operating on the network that are
not part of the known, governed set of services in the catalog. So a bunch of services without
architecture or governance does not an SOA make.
In my view, it is debatable whether a “service” that is wholly outside the context of an archi-
tecture is actually a service at all. It is in part the contextual role within a supporting architec-
ture that elevates an operation to the level of a service. This status is afforded, but not directly
stated, by the last criterion in my definition of a service: it can be decorated with runtime ex-
tensions that handle certain technical non-functional requirements.
SOA facilitates integration
SOA represents a way of thinking about systems integration. An SOA serves to offer in-
creased or new business functionality or opportunities by connecting multiple systems togeth-
er. In its most straightforward form, this means that you can do B2B work more quickly.
CORBA, connector architecture, EDI, and point-to-point EAI efforts over decades have all
demonstrated the ability to integrate diverse systems. But such efforts can be costly and brittle.
They can distract developers and IT departments from addressing their real business prob-
lems, as they work for months getting systems to talk. These solutions all define their own
formats for message exchange. SOA, in general, reuses XML as a standard means of message
format, allowing integration efforts to leap into action more readily.
Some CIOs, in frustration with previous EAI projects and in an honest attempt to address their
problems quickly and decisively, have thrown in the towel, called up their favorite vendor,
and signed up for their entire stack in an attempt to avoid the integration problem altogether.
But this can be a very expensive proposition indeed and it has the drawback of tying your or-
ganization to that vendor, locking you into operating on their time tables, and you'll be able to
provide only the functionality they expose.
Search WWH ::




Custom Search