However lets look at a context of how SOA would generate business services which are in themselves - first class assets - I will try and leverage examples from my practical experience rather than focus on simple customer examples.
First and foremost, there is a notion of service layering which SOA governance board or an equivalent party has defined for you. In our case, we have been using what is classically referred to CBDI-SAE (www.cbdiforum.com) meta model for service layering.
| Layer/Main Role | Operations Are | Dependencies | More rules | Data Storage |
| Solution Logic: UI, channel and dialog-specific processing | Non-existent - this layer does not contain services | May call Process, Core Business & Utility services directly | Supplies user interface, validation, user messages, session management | Not normally, except for temporary session data |
| Process Services: orchestrate other services; apply business process-specific rules | UI-independent, but designed for a specific business process | May call Capability, Core Business & Utility services directly | May be called by solutions that support other business processes | Only where not stored by Core Business Services. Stored data likely more transient than for core services. |
| Capability Services: may be standalone, or utilize lower level services | UI- and process independent, and designed to support one particular ‘business capability’ | May call Core Business, Underlying & Utility services directly, unless it’s a standalone capability | Standalone capability services must not depend on shared services (but can be an assembly of non-shared services) | If standalone, stores own data; if integ-rated, may store any data not managed by core business & lower services. |
| Core Business Services: apply enterprise-wide business rules | UI- and business process- independent, so can be used in different contexts | May directly call other Core Business, Underlying and Utility Services | Cyclic dependencies not normally permitted, except for “call-back”. May not call Process Services | Normally maintains principal data stores, unless this delegated to Underlying Services |
| Underlying Services: apply the business rules, but not exposed as well-formed service | Highly generic or implementation-based, so its interface not ideal for exposing to solution developers | May call Utility Services, but normally would not | May not call Core Business or Process Services | Often maintains significant data stores, and core services call underlying services to access this data & its processing rules. |
| Utility Services: shared by Core Business Services | UI-, business process- and often domain- independent | May call other Utility Services directly. Some may use Underlying Services | Cyclic dependencies not normally permitted. | Often required — for directories, look up tables and logs for example. |
Now lets apply these sets of principles to a domain in area of Port Operations called "Marine". This is typically a department which is run by a port authoirty to service the container terminal or General cargo terminal and essentially guides the ships from high seas to the terminal berths. It uses very well qualified pilots (like airlines pilots), tugs (small boats which nudge and push big ships) as the main resources to get the ships coming in at a slotted time as per terminal's request. The planning algorithm is quite complex as it needs to take into account the distances between the high seas and various locations in the terminal. Also consider the impact of tide, weather (esp Visibility) etc on the same. Sometimes, there are exceptions to the rule - Military vessels just can barge in on high priority - the priority rules are a combination of which ships have been waiting for how long in high seas and where they are supposed to go etc.
With this brief background, lets start exploring how a service and event driven system is built around this domain.
The solution layer we can call "Marine app" is a combination of several UI channels - bunch of jspslenght of channel (dont expect network or even GPRS coverage to be there always) etc. Note that there are atleast 3-4 entry points to the app - some of the application logic is being serviced by non-reusable application logic specific to that channel.
The next layer - which we call process services - has three processes. Lets focus on most important ones - the "Request to Berth" - this can be submitted based on a terminal working schedule published and changed by terminals or through the external agent directly from portal.
This is an end to end process of accepting the request as tentative, communicating any changes during initial plan or during movements to the originator and finally closing the move by sending an invoicing event to billing system. Each intermediate callback can have a SLA esp when invoked externally
The second set of services called capability services will typically be what are the fundamental capabilities that exist in this domain - in most software service views, we dont show what is manual - but for clarity - the fundamental long lasting capabilities in this domain are about being able to plan the movement, being able to track the movement BUT NOT TO ACTUALLY MOVE THE VESSEL (THIS IS NON-AUTOMATED SERVICE). There is a tendency in SOA architects to map this layer to activities - our judgment has been on fundamental long lasting capabilities rather than just pure play activities. It is important to note the alignment of these services to business objectives and startegywrt to business rules but also to service differentiation within the rules - if 90% of my revenues come from CT - I give them preference in planning, I dont try and delay CT vessels, if CT's biggest customer is XYZ shipping line, my planning service recognizes the service context and tries to give it maximum attention.
On the core business service - a simplified view is presented - but these are major nouns with the marine boundaries where data stores are maintained and rules applied - Vessel, Voyage, Resources (pilots), and Agents making the requests as well as vessel movement plan itself.
Rather than confuse the picture with unpublished underlying services, we focus on utility services which are mostly around weather, tide, employee services shared across multiple domains.
Note the following with these services
1. We are talking to services (and not operations) - each service may have one or more operations
2. Each service has a business owner responsible for governance and evolution management
3. Each service is tied to business outcomes and goals that it needs to serve.
4. Each service incidentally has a service level on security, availability, response time specification, message delivery policies (once and only once, reliability of messaging), idempotency
5. Each service has a richer service specification than standard Input output protocol details of contacting the service and the end point reference, usually this will have a business name of service, technical name of service, pre-conditions, post-conditions, which business processes it serves, what is it dependent on (aka service assembly dependencies), commodization level (Core capability, specialty, innovation, treadmill)
6. Most of the services as show above are described and are discoverable either through UDDI spec or Reusable asset specification with in an enterprise registry/repository. The registry/repository is synced up to development asset library (EA tool or integrated service environment). Not unusual to have two sets of such registry/repository - one for all states of services before they get operational and one for all operational services in production
7. Each service has a lifecycle and governance associated with it. Each service transition involved either automated checks (like WSI interoperability check, performance tests, and automated functional tests) or manual tests and approvals.
Given all this, it should be evident that we are not just treating business service as a derived principle but as a first class concept and type which stands on its own.
No comments:
Post a Comment