Java Reference
In-Depth Information
UNDERSTANDING INTENTS AND CONFIGURATION
To u n d e r s t a n d i n t e n t s a n d c o n f i g u r a t i o n i t 's u s e f u l t o c o n s i d e r t h e a c t u a l m e c h a n i c s
of how
OSG
i distribution providers publish a service remotely. This process follows the
classic whiteboard pattern, where the distribution provider waits around listening for
services to be registered with the
service.exported.interfaces
service property.
This is the cue for it to make the corresponding service available remotely.
Given no other information, a distribution provider can pick any number of ways to
make the service available remotely. It can use various protocols (
SOAP
,
REST
,
RMI
, and
so on). It can use a range of different
security or authentication mechanisms
(such as
SSL
,
DSA
, Blowfish,
LDAP
, or
Kerberos). There are even many differ-
ent transport technologies (
HTTP
,
JMS
,
Unicast, Multicast, and
P2P
). This
dilemma is shown in figure 15.7.
There's no single best choice for any
of these options. When you're building
distributed applications, as with most
applications, one size doesn't fit all. Dif-
ferent techniques are appropriate in dif-
ferent scenarios. Having said that, it
doesn't make sense for business-level
services to specify the minute details of
how they should be made available remotely. Coming back full circle to the theme from
chapter 2, this is another area where separation of concerns is applicable.
Intents and configurations provide a layer of indirection between the service pro-
vider and the distribution provider. They allow the service provider to specify just
enough information to ensure that the service behaves as expected, yet still allow the
distribution provider to optimize communications for the environment in which
they're deployed. Now that you understand what intents and configuration are in the
abstract, let's look at them in concrete terms.
service.exported.interfaces=*
LDAP
SOAP
Service
RMI
Distribution provider
SSL
Figure 15.7
When making remote services
available, the number of options is bewildering:
protocols, transports, authentication schemes,
and encryption algorithms all play their part.
INTENTS
Intents are a pattern borrowed from the Service Component Architecture (
SCA
) spec-
ification. An
intent
is a string value with agreed-on distribution-level semantics. To
make this concept less abstract, let's look at an example of an intent you might attach
to a registered service:
props.put("service.exported.intents",
new String[] { "propagatesTransaction", "authentication" });
In this case, you're communicating two different intents to the distribution provider.
The first,
propagatesTransaction
, says the service should be made available in such a
way that transactional boundaries are transmitted to the service. The second,
authen-
tication
, says the client application should be authenticated prior to using the service.
