2. Next, one defines the abstract model, or how to view the information in the context of the SOA. This means taking the physical representations and structures, and turning them into an information layer that makes better logical sense within SOA. This approach and its enabling technology has clear advantages when considering agility, since the visible structures for use within the services are configurable.
3. Next, one defines the services, or behaviors, and how the underlying information models that- just created - are bound to those services. Typically, one creates two types of services—data services and transactional services—but one can easily extend them. Services can be bound into processes and composites as well later.
4. Finally, one defines how all of the services below exist within a process or orchestration model, or a place where business processes are defined and redefined, thus providing the core benefit of SOA—agility.
5. The core idea here is to place volatility into a single domain, or a place where the use of services (and thus the information) can be defined, and redefined, according to the requirements of the business.
There are also ancillary needs to consider:
- A monitoring & event management layer that exists above the business processes to keep an eye on the architecture during operations,
- A governance model,
- A security model,
- The ability to create & enforce policies around the use of the services,
- The ability to bind security down to core granular components, typically through a federated security model.
No comments:
Post a Comment