Monolithic applications are applications where the code that implements the business rules, data access, and user interface are all tightly coupled together as part of a single, large computer program. A monolithic application is typically deployed on a single platform, often a mainframe or midrange computer. There are, however, examples of monolithic applications running on smaller systems - or even distributed across multiple machines. The determining characteristic of a monolithic application is that the code is tightly coupled and highly interdependent. Object-orientation divides the application into the units of the logic based on the functionality and data. In a 2-tier model, the desktop user connects directly to a database. All processing is done in the client application—the database serves only as a repository for data. Then the tiered applications came into play. Here we include a middle layer for the application logic. This middle layer can also be multiplied to constitute the n-tiers. The web sites actually falls into this category. The thin clients , I mean the browsers, and the Web sites actually falls into this category. You have browsers, an application server hosting the logic and the database.
In further cases, the objects are distributed in the environment. Actually this gain attention with the introduction of the Wide Area Networks and the Internet. Remote Method invocations actually falls into this category. After that the component orientation came into play. Here we see the concept component which … Ali Hocanin Dokumana Bak Service : Capabilities performed by one for another to achieve a desired outcome Orientation : Functionally aligning architecture to enable a collection of independent services to be linked together to solve a business problem Architecture : The fundamental organization of a system embodied in its capabilities, their interactions, and the environment
The core of the SOA involves the Services. I will mention what a service is in a few slides soon. Loose Coupling. Changing in time. Can be implemented in different platforms and with different technologies. Each service should be described. The description defines the service and the requirements you have to have to use that service. In ws world, this is achieved through WSDL. In addition, Policies are also important to specify the requirements such as security. Once the description is achieved services are published, discovered, selected and binded. The discovery phase achieves this through registries. The service registries such as ebXML, UDDI, which will be mentioned soon, currently achieves discovery syntatically. It is mostly supported with taxonomies. However, fully automated discovery, the current trend is to use the ontologies such as WSMO approach. One thing to note in SOA is that it is fully message oriented. Therefore, there has to be mechanism to achieve the
According to the Business Rules Group , “a business rule is a statement that defines and constraints some business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules which concern the project are atomic, that is, they cannot be broken down further.” Modeling business rules as separate entities offers great flexibility. Especially in the e-commerce domain, this can be a valuable advantage, since the business analyst, who ideally authors the business rules, does not need to have programming knowledge to change the rules. Typically, changing the business rules happens more often than changing the large e-commerce applications. Moreover, extracting the business rules from the business logic leads to a better decoupling of the system, which, as a consequence, increases maintainability. One of the most important facts about business rules is that they are declarative statements, they specify what has to be done and not how .
Unlike Object Oriented Programming paradigms, where the focus is on packaging data with operations, the central focus of Service Oriented Architecture is the task or business function getting something done.
Service : A mechanism to enable access to one or more capabilities using a prescribed interface and consistent with constraints and policies as specified by the service description. Visibility is the relationship between service participants that is satisfied when they are able to interact with each other Awareness: Service description, Discovery Willingness: Policy & contract Reachability: Communication Interacting with a service involves performing actions against the service Behaviour Model , Information Model : The extent to which one system can effectively interpret information from another system is governed by the semantic engagement of the various systems. The semantic engagement of a system is a relationship between the system and information it may encounter. The real world effect is couched in terms of changes to the state shared by the participants and stakeholders in a service interaction Policy : Constraint representing the intention of a participant in a service Contract : Constraint representing an agreement between two or more participants. The service description represents the information needed in order to use, manage or provide a service. The execution context is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interaction, and thus forms a path between those with needs and those with capabilities Actually this reference model can be regarded as an ontology if extended. Currently it is in the draft version but can be used as a tool for discovery. The process is ongoing…
SCA provides an assembly model to simplify and standardize the development of the services for SOA. This is achieved by using a series of the artifacts referenced by an XML File. The control file provides the associations to the related documents to implement a service. The pragmas on the other hand achieves the same functionality through inline comments. The interfaces provide the external view of the service. Such as WSDL The implementation relates the service to an implementation such as Java, .NET or BPEL Policy specifications for the container to configure itself. The services required Support for WS-ResourceFramework. Not going into details. The specification of the valid sequence of the invocation of the methods the service provide. This is machine readable syntax. For example, for healthcare domain, a modifyLabOrder method must follow createLabOrder method but not be later than the submitLabOrder method.
Module: Largest composition of tightly-coupled components developed and deployed together Basic unit of loosely-coupled composition Includes components, external services, entry points, wires Components: Instances of implementations Configurable aspects of a component are defined as Component Type Component Type: Specifies the interfaces component provides The other component interfaces that the service references Properties that can be set to configure component Component Implementation: Default implementation types are Java, BPEL, C++… Provides an extension mechanism Referenced by components Interfaces: Referenced by component types, components… Java, WSDL 1.1/2.0
Client : Objectives that a client wants to achieve by using Web Services Web Services : Semantic description of Web Services: Capability (functional) Interfaces (usage) Mediators : Connectors between components with mediation facilities for handling heterogeneities Ontologies : Provide the formally specified terminology of the information used by all other components
Define the requirements Decompose the system Identify the business processes Identify the rules Identify the services Implementation
What is SOA ? Security Trans. & Reliabil. Discovery Description Choreography Business Rules Applications Services Composition Mediation
What is SOA ? SaaS Business Processes Application Logic (Server) Application Logic (Client) UI Mobile Client HIS RIS/ PACS Billing EMR LIS Internet National ID Management Electronic Claim Processing Internet Internet Mashup Services I P Archetype Repository
“ The wrong approach is to look at the silos, identify interesting data and plant a service on it. The right direction is to lay out the scenarios you want to carry out, and see where they touch silos. A point of tangency is where there might be an opportunity for a service. Services should not be driven bottom up from technology, as DHS folks are proposing, but rather from the top down—with the use cases.”
Grady Booch on an interview about SOA
“ This is not to say SOA is a bad thing. Like any technology, you have to approach it in meaningful ways. SOA is very useful for gluing systems together, but it does not address the internal architectures of systems”
A few words from SODSL Ontology Ontology Parser Reasoning Engine Rule Engine Domain Analysis Feature Model Feature Classification Feature Modularization Feature Constraints Domain Design Partitioning Strategy Coordination Model COSEML SOA (WSMO) Domain Implementation SODSL SODSL Generator Process Generator Services
A few words from SODSL Platform Service Process Rules Code Generation COSEML & DSL Feature Model