Database Reference
In-Depth Information
Service as an entity model
We will start by putting together the basic artifacts, most of which we already identified
when counting our lookup entities. It is obvious that everything begins with the Object and
that it is the most abstract entity in a hierarchy. Furthermore, we will see that on an enter-
prise level, we are really dealing with quite a limited number of truly unique things, usually
described in the earlier stages of a project's MDA exercises (in UML form). It is also obvi-
ous that the transportable (or serializable) form of an object is a message, which is a bit less
abstract, but it can still exist as a message. A
message
is commonly described as an XSD.
An Object does not exist alone. The Object and its context live and evolve within the ap-
plication, presented as a set of components and resources interfaced by the API (or con-
tract), which comprise a complex artifact called, in the old EDI times, a "trading partner ".
That's not exactly an SOA term, but it is quite capable of describing an application, applic-
ation user(s), and API (contract) with related protocol(s) and interchange pattern(s) as a
composite entity. A message, representing an application object, will be constructed and
propagated when a certain noticeable change in the object's state occurs, denoting an event.
This so-called basic or primitive event can be specific to this application, or can be taken in
the broader SOA context, that is, it can be an enterprise business event. Event filtering and
recognition, message construction, and mediating are usually controlled by a set of rules.
These rules play a significant role in every aspect of Service activities and composition's
policies. When combined together in a certain order, they represent rulesets.
The mentioned services are the essence of the SOA, and through their models and realiza-
tions, assume different roles in every framework of the SOA landscape. For this taxonomy,
it would be enough to say that the Service/Task is the executable module with a clearly
identified API (an API that is presented as a contract is separated for WS and implanted for
components) and a service engine responsible for the execution.
In this sense, the term "executable" means that every service or component must support
dynamic execution or invocation in the appropriate form—web services must be compos-
able (via the support of a standardized service contract, statelessness, and loose coupling),
Java components should support the IoC/dependency injection, PL/SQL packages should
be written to support NDS, and so on. The last common abstract thing is the Process—a
composition of the previously registered Services/Tasks.
Following the basic rule of the separation of abstract and concrete taxonomy parts (as in
the standard WSDL), we can initially assume that these seven entities are abstract, with the
following properties as exceptions:
Search WWH ::
Custom Search