Group items tagged

Modeling Service Oriented-Architectures: An Illustrated Example using Sparx Systems Enterprise Architect

Download the E-book in PDF format Download the E-book, Roadmap, Project Template and Rental Car example as a zip file

In our third E-book, author Doug Rosenberg (Founder and President of ICONIX Software Engineering, Inc) presents a practical approach to modeling Service-Oriented Architecture solutions from concept to code.

Entity-Control-Boundary (ECB) architectural pattern matches perfectly with our pattern language

domain structure is an Entity, the Control is a service, and the Boundary is realized with a facade

In simpler cases the facade and service can collapse, and a service would be realized only as a facade's method in that case

3 primary concepts:

DAOs aren't dead, but they cannot be considered as a general best practice any more. They should be created in a bottom-up, rather than a top-down, fashion. If you discover data-access code duplication in your service layer, just factor it out to a dedicated DAO and reuse it. Otherwise it is just fine to delegate to an EntityManager from a service. The enforcement of an empty DAO layer is even more harmful, because it requires you to write dumb code for even simple use cases. The more code is produced, the more time you must spend to write tests and to maintain it.

With JDK 1.5 and the advent of generics, it is possible to build and deploy a generic, convenient, and typesafe DAO once and reuse it from variety of services

key ingredients of a service-oriented component: Facade: Provides simplified, centralized access to the component and decouples the client from the concrete services. It is the network and transaction boundary. Service: The actual implementation of business logic. Domain structure: This is a structure rather than an object. It implements the component's persistence and exposes all of its state to the services, without encapsulation.

This convention not only standardizes the structure and improves maintainability, but also allows automatic dependency validation with frameworks like JDepend, Checkstyle,  Dependometer, SonarJ, or XRadar. You can even perform the validation at build time. If you do, the continuous build would break on violation of defined dependencies. The rules are clearly defined with strict layering: a facade may access a service, and the service a domain object, but not vice versa

BlazeDS client architecture

message-based framework

message-based framework

Technical debt; is it only technical?

“TechnicalDebtQuadrant“

distinguishes between reckless vs. rational behavior and  deliberate vs. carelessly/naively choices

powerful way of formalizing the recurring bean roles that often arise as a result of application architectural patterns

«Boundary»

Boundary is a stereotyped class or object that represents some system boundary

«Control»

deploy a EJB 3.1

and use e.g. CDI behinds behind.

EJB beans cannot be directly exposed to JSF or JSP without a little help from CDI

CDI doesn't provide any transactional, monitoring, or concurrency aspect out of the box

stateless EJB 3.1 bean as boundary (Facade)

GDS/Tide project represents the Data Services part of GDS

comparable to LiveCycle Data Services, which is neither open source nor free, as it provides similar features such as client container of managed entities, data paging, and integration with server components, but it is based on completely different principles:

strongly typed Hibernate/JPA detached objects