Fundamental concepts
SOP concepts provide a robust base for a semantic approach to programming integration and application logic. There are three significant benefits to this approach: * Semantically, it can raise the level of abstraction for creating composite business applications and thus significantly increase responsiveness to change (i.e.Encapsulation
In SOP, in-memory software modules are strictly encapsulated through well-defined service interfaces that can be externalized on-demand as web service operations. This minimal unit of encapsulation maximizes the opportunities forService interface
A serviceService invoker
A service invoker makes service requests. It is a pluggable in-memory interface that abstracts the location of a service producer as well as the communication protocol, used between the consumer and producer when going across computer memory, from the SOP runtime environment such as an SVM. The producer can be in-process (i.e. in-memory), outside the process on the same server machine, or virtualized across a set of networked server machines. The use of a service invoker in SOP is the key toService listener
A service listener receives service requests. It is a pluggable in-memory interface that abstracts the communication protocol for incoming service requests made to the SOP runtime environment such as the SVM. Through this abstract layer, the SOP runtime environment can be virtually embedded within the memory address of any traditional programming environment or application service.Service implementation
In SOP, a service module can be either implemented as a Composite or Atomic service. It is important to note that Service modules built through the SOP paradigm have an extroverted nature and can be transparently externalized through standards such asSemantic-based approach
One of the most important characteristic of SOP is that it can support a fully semantic-based approach to programming. Furthermore, this semantic-based approach can be layered into a visual environment built on top of a fullyService implementation: composite service
A composite service implementation is theProgramming constructs
SOP supports the basic programming constructs for sequencing, selection and iteration as well as built-in, advance behavior. Furthermore, SOP supports semantic constructs for automaticSequencing
A service inside of the definition of a composite service (an "inner service") is implicitly sequenced through the semantic connectivity of built-in success or failure ports of other inner services with its built-in activation port. When an inner service runs successfully, all the inner services connected to its success port will run next. If an inner service fails, all the services connected to its failure port will run next.Selection
Logical selection is accomplished through data-driven branching constructs and other configurable constructs. In general, configurable constructs are services built into the SOP platform with inputs and outputs that can assume the input/output shape of other connected services. For example, a configurable construct used for filtering output data of services can take a list of Sales orders, Purchase orders or any other data structure, and filter its data based on user declared filter properties stored on the interface of that instance of the filter construct. In this example, the structure to be filtered becomes the input of the particular instance of the filter construct and the same structure representing the filtered data becomes the output of the configurable construct.Iteration
A composite service can be declared to loop. The loop can be bound by a fixed number of iterations with an optional built-in delay between iterations and it can dynamically terminate using a "service exit with success" or "service exit with failure" construct inside of the looping composite service. Furthermore, any service interface can automatically run in a loop or " foreach" mode, if it is supplied with two or more input components upon automatic preparation. This behavior is supported at design-time when a data list structure from one service is connected to a service that takes a single data structure (i.e. non-plural) as its input. If a runtime property of the composite service interface is declared to support "foreach" in parallel, then the runtime automation environment can automatically multi-thread the loop and run it in parallel. This is an example of how SOP programming constructs provide built-in advanced functionality.Data transformation, mapping, and translation
Exception handling
Exception handling is a run-time error in Java. Exception handling in SOP is simply accomplished by connecting the failure port of inner services to another inner service, or to a programming construct. "Exit with failure" and "exit with success" constructs are examples of constructs used for exception handling. If no action is taken on the failure port of a service, then the outer (parent) service will automatically fail and the standard output messages from the failed inner service will automatically bubble up to the standard output of the parent.Transactional boundary
A composite service can be declared as a transaction boundary. The runtime environment for SOP automatically creates and manages a hierarchical context for composite service objects which are used as a transaction boundary. This context automatically commits or rollbacks upon the successful execution of the composite service.Service compensation
Special composite services, called compensation services, can be associated with any service within SOP. When a composite service that is declared as a transaction boundary fails without an exception handling routing, the SOP runtime environment automatically dispatches the compensation services associated with all the inner services which have already executed successfully.Service implementation: atomic service
An atomic service is an in-memory extension of the SOP runtime environment through a service native interface (SNI) it is essentially a plug-in mechanism. For example, if SOP is automated through an SVM, a service plug-in is dynamically loaded into the SVM when any associated service is consumed. An example of a service plug-in would be aCross-cutting concerns
SOP presents significant opportunities to supportService instrumentation
The SOP runtime environment can systematically provide built-in and optimized profiling, logging and metering for all services in real-time.Declarative & context-sensitive service caching
Based on declared key input values of a service instance, the outputs of a non time-sensitive inner service can be cached by the SOP runtime environment when running in the context of a particular composite service. When a service is cached for particular key input values, the SOP runtime environment fetches the cached outputs corresponding to the keyed inputs from its service cache instead of consuming the service. Availability of this built-in mechanism to the SOP application developer can significantly reduce the load on back-end systems.Service triggers
SOP provides a mechanism for associating a special kind of composite service, trigger service, to any other service. When that service is consumed, the SOP platform automatically creates and consumes an instance of the associated trigger service with an in-memory copy of the inputs of the triggering service. This consumption is non-intrusive to the execution of the triggering service. A service trigger can be declared to run upon activation, failure or success completion of the triggering service.Inter-service communication
In addition to the ability to call any service, Service Request Events and Shared Memory are two of the SOP built-in mechanisms provided for inter-service communication. The consumption of a service is treated as an Event in SOP. SOP provides a correlation-based event mechanism that results in the pre-emption of a running composite that has declared, through a "wait" construct, the need to wait for one or more other service consumption events to happen with specified input data values. The execution of the composite service continues when services are consumed with specific correlation key inputs associated with the wait construct. SOP also provides aService overrides
In SOP, customizations are managed through an inventive feature called Service Overrides. Through this feature, a service implementation can be statically or dynamically overridden by one of many possible implementations at runtime. This feature is analogous to polymorphism inConsumer account provisioning
Select services can be deployed securely for external programmatic consumption by a presentation (Security
The SOP runtime environment can systematically provide built-inVirtualization and automatic multithreading
Since all artifacts of SOP are well-encapsulated services and all SOP mechanisms, such as shared memory, can be provided as distributable services, large-scale virtualization can be automated by the SOP runtime environment. Also, the hierarchical service stack of a composite service with the multiple execution graphs associated to its inner services, at each level, provides tremendous opportunities for automated multi-threading to the SOP runtime environment.History
The term ''service-oriented programming'' was first published in 2002 by Alberto Sillitti, Tullio Vernazza and Giancarlo Succi in a book called "Software Reuse: Methods, Techniques, and Tools." SOP, as described above, reflects some aspects of the use of the term proposed by Sillitti, Vernazza and Succi. Today, the SOP paradigm is in the early stages of mainstream adoption. There are four market drivers fueling this adoption: *See also
*External links
* http://nextaxiom.com