Java Reference
In-Depth Information
not want later. If you find yourself in this situation, consider using an orchestration technology
Also, it can be difficult without service-level agreement (SLA) monitoring software and met-
rics in place to keep track of how much traffic a service is receiving from where. If your ser-
vice crosses business domains, it becomes particularly important to consider that it could see
sudden, unexpected explosions in traffic due to compositions external to your current subject.
Another problem with direct invocation is that it adds complexity to your topography without
allowing visibility through tools. There are tools by the big SOA suite vendors that show de-
pendencies across the service-related resources stored in your enterprise repository, but they
can be very expensive.
The architectural solution to this problem is that when you want to have one service directly
invoke another, consider whether you can create an orchestration (or process service, as
defined in
Identifying Different Kinds of Services
) instead. As a service wraps a system or
subsystem, an orchestration wraps a set of services that together make a flow. But the orches-
tration is itself exposed as a service, so it looks just like any other service to the client.
Other considerations
An SOA will mean something different to different organizations, and I encourage you to con-
sider your specific definition and decide what elements to emphasize within your own busi-
ness context and its attendant constraints.
