Service-Oriented Architecture

The decision to make service-oriented architecture the leading architecture principle has a number of consequences. Middleware is still fairly new at NOPERU. Teams used to be organized around applications – around the silos discussed above. The Business Layer at the heart of the layered architecture will be the new focal point for all teams. This layer is made up of a number of different types of services that bring together all data from the Data Layer – structured and unstructured, across databases, document repositories, LDAP instances and mail servers – and expose access to this data in a standardized, unified way. Moreover, these services make business logic available to applications – both user interfaces and programmatic channels.

Part of the foundation of the Business Layer is the Enterprise Data Model (or “Canonical Data Model”) and, more specifically, an XML representation of that model, expressed in terms of a heavily annotated XSD (XML Schema Definition). All data structures handled by the services – both input and output – are defined using business objects in this canonical XSD. The five data domains are recognizable through the namespace structure used in the XSD definitions.

The architecture team came up with a service classification scheme that helps organize the services as well as the teams working on those services. Following this scheme, the Business Layer is subdivided into these types of services:

  • Elementary Services: provide atomic functionality within a domain; their reuse potential is high, their added value usually low
  • Composite Services: combine two or more elementary services into business functions with higher added value; composite services come in two flavors:
    • within a domain
    • across domains (typically introducing the need for either global transactions or transaction compensation)
  • Process Services: asynchronous and longer running (up to minutes, hours or even days) and usually contain state while running Presentation Services: not meant for general reuse; instead, they cater to specific needs of an application or channel – either a user interface or a programmatic interface – and speak the specific language of that application
  • Utility Services: generic, domain-independent, highly reusable services, frequently of an almost infrastructural nature (e.g., logging, sending emails, value translation, geocoding, etc.)

Service design and implementation guidelines are created per service category. Governance, ownership, testing and many other aspects of the services also depend on the type of service.

refences :

No Comments

Leave a Comment