But should services that are part of an aggregated
structure be allowed to exchange messages directly with outside service-oriented software
assets? If not, how should messages be propagated? The following sections on design relationship
methods address these questions.
238 Ch. 12 Service-Oriented Logical Design Relationship
Customer
Profile
Atomic
Service
Customer
Profile
Consumer
EXHIBIT 12.2 PUBLIC DESIGN RELATIONSHIP
PUBLIC DESIGN RELATIONSHIP. Public relationships are formed when message exchange participating
consumers and services communicate directly without any interference. These relationships
are enabled because the message paths connecting these entities do not have any barriers
or roadblocks. In large and complex computing environments, it is rare to have software assets
conversing without any intervening intermediaries. In more confined and smaller deployed service
and consumer landscapes, however, public associations are commonplace.
Consider Exhibit 12.2, which depicts a simple form of public relationship between the
consumer profile atomic service and its counterpart, the customer profile consumer. In this case,
the service design apparent bidirectional relationship icon denotes that this association is direct
and no intervening proxies are involved.
When providing a design blueprint that depicts public access to services, be aware that
the cons often outweigh the pros of this design.
Pages:
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417