Skip to end of metadata
Go to start of metadata

Core Services

Core Services
Core Services is basically data services. Typically they evolve to become the master repository for the most important business objects in the enterprise. Typical examples are Customer and Product. You will also fint that it often makes sense to split a service for a domain object into a CRUD (master) service and a accompanying Query Service to keep the complexity to a manageable level, and to allow a more feature rich query interface.


  • Data access services
  • Domain object repositories
    • SOA as an integration strategy
    • Single repository of domain objects
    • Decoupling the client from persistence technology and strategy
  • Granularity
    • <MyDomainObject>DomainRepository
    • <MyDomainObject>QueryService
  • Stable long term contracts

Code-Patterns for Core Services

  • [Enterprise Domain Repository Pattern]
  • [Evolving Service Endpoint Pattern]
  • [Recording Command Pattern]
  • [Recording Proxy Pattern]
  • [Smart Service Proxy Pattern]

Technology/Implementation strategy (Java)


  • Code-centric ESB/integration products (connectors & mapping)
  • Space-Oriented Architecture
  • EDA products
  • Open-ended mapping of Core Domain Objects and Integrated Applications

Implementation and products

  • Java code
  • Use mobile code if you can
    • XML/XSLT mappings
    • Jini/ JavaSpaces
  • Repository with code-centric integration products
    • OpenESB/Glassfish
    • Mule
    • Esper (EDA)

Technology/Implementation strategy (.NET)


  • .NET 1.0/2.0 ASMX
  • .NET Remoting
  • Windows Communication Foundation (WCF)
  • IIS Hosted
  • Windows service / Self-hosted
  • In-proc

Implementation and products

  • .NET code
  • BizTalk orchestrations can do a good job for mapping and high throughput

Design Rules

  • [Design-time Governance for CS]

Other technical details

Focused on getting an agile architecture to support both the complexity in today's deliverance and infrastructure, and also to build a platform that will give faster time-to-market than the competitors. Central in this architecture lays the concept of Master strategy. Per today the following central domain objects have been planned implemented using the master-service-strategy:

  • CustomerMaster (including customer relation an contact persons)
  • MarketProductMaster (including mastering of instantiated products/services towards ordering and delivery track)
  • ServiceMaster (both CustomerFacing and ResourceFacing - technical building blocks that connects product to resource/provisioning)
  • ResourceMaster (management and control on all components in the infrastructure that there will be an shortage off/expense to scale further)
The Master strategy works like this:
A Master-Service is established and made available for all systems in our enterprise
  • The Master-Service has the responsibility to collect and aggregate master-domain-objects across the under laying systems
  • The Master-Service will master merging of elements in e.g. customer objects on the field level, based on a rule set of which changes are allowed in the different systems (a contact person with invoicing responsibility is 'owned' by the order system, and will not be updated by a mistake by the portal or the CRM system).
  • The Master-Service can be expanded with its own persistence/storing to make sure of optimal uptime, so SLA will not be impaired if one or several of the systems falls out.
  • The Master-Service will establish triggers in the different systems, and will there for detect by them self out-of-bounds updates and merge this by applying the same rule set as described above.

See EDR and EDR-MDS for more in-depth of the mastering strategies.

Content is moved to Service Categories

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.