Doorgaan naar hoofdcontent

Cordys projects in the enterprise

Introduction

Cordys is used in small, medium as well as enterprise organisations. Within the Cordys Wiki you can find guidelines and best practices for the Folder structures and CWS environment (see [1]). When you want to use Cordys within the Enterprise I think these best practices are not recommended. In this Blog i will try to explain why.

BPM/SOA 5-layering Architecture

Every enterprise architect knows the 5-layering SOA enterprise architecture pattern:
  1. GUI - In this layer in which thin and thick clients are using the Business Services.
  2. Business Services - In this layer the Composite Services, like the enterprise business processes are implemented.
  3. Services - In this layer the Services are implemented.
  4. Applications - This layer is the integration layer towards the encapsulated applications.
  5. Data - This layer contains the data
Most Cordys projects (at least that i have seen) uses Cordys (solutions and projects) like this:


The solutions and projects are divided vertically, so in fact this way you get Application Silo's again, which you want to avoid with SOA and BPM principles. I understand that WS-AppServer integration is nicely integrated with XForms but i doubt if this is the way to go for the enterprise.

For the enterprise I would recommend:

In this case projects and solutions are defined horizontally. 

GUI
In this layer projects are defined that contain the Portals, Web Clients, Mobile applications etc that can only use the Business Services layer to execute business functionality.

Business Services
In this layer projects are defined that only implement the business processes. This layer will use the Services layer to compose the processes and composite Services.

Services
This layer contains the Domain Services solutions and projects. Note that these Services only use Common Data Model data and not applications specific data.

Applications
This layer contains the projects that actually encapsulate the applications with webservices.

Data
This layer contains the encapsulation of data, i.e. databases or shared files on directories. Here you will see WS-AppServer projects.

Conclusion

For small and medium sized organisations and projects you can use the solution/project constructions mostly described. However within big enterprises this does not suffice.
The question is of course what the consequences are when you are using the projects horizontally.

Are there any Cordys perfomance penalties? Of course because layering always causes overhead.

What are your experiences with large Cordys projects?

References

Labels:

Reacties

  1. Anoniem12 juni 2012 om 23:51

    Appreciate your thoughts about organizing the Cordys CWS projects in a different way for Enterprise applications.

    I do understand that in enterprises adopting SOA and ESB would like to have a decoupling between the 5 layers is a way that these layers can be implemented independently in which case your approach to project in CWS might make sense.

    However, I do not think it is a good idea to club the UI functionality for all business solutions in one big Cordys project and Business Services for all business solution in another large project. For large enterprises the number of artifacts in each project which are horizontally defined will be difficult to manage mainly for 2 reasons: 1) the solutions normally undergo different project life cycles and change frequencies, 2) the size of the horizontal project will keep growing to reach a very large size.

    I would still recommend to develop these layers vertically for each specific business solution. Nonetheless, common generic components required for multiple business solutions could still be defined using the horizontal approach.

    Moreover, the layering of solutions in 5 layers is more relevant from runtime point of view which can still be maintained even if you organise your projects vertically. Just my thoughts...

    BeantwoordenVerwijderen
  2. Roger van de Kimmenade13 juni 2012 om 08:27

    First of all thank you for your response !

    In fact it is not meant to define just one project for (for example) the UI functionality. There can be several workspaces and projects for each layer. That is why i draw several projects in each layer.

    The layering concept is relevant not only from a runtime point of view but also (mainly) from a design time (and governance) point of view.
    (See also http://www.soapatterns.org/service_layers.php

    So the layering is about:
    * Abstracting
    * Governance
    * Loose Coupling and Strong Cohesion
    * Reusability of Services

    Hope this clarifies a bit why i think about structuring the Cordys projects.

    B.t.w. What is your experience of structuring Cordys projects within large enterprises?

    BeantwoordenVerwijderen

Een reactie posten

Populaire posts van deze blog

OSB 10gR3 and SWA and MTOM

This blog is about using soap with attachments and the use of MTOM within the OSB (10gR3). A service is created that accepts a soap with attachment (DocumentService) and translates it to a service that accepts a binary element. MTOM is used for performance reasons for the second. Some notes: * For the use of attachments you need RPC-style document instead of the usual document-style. This due to the fact that the document-style limits a message to a single . * A service can not have both SWA and MTOM within OSB. First a WSDL is setup for the DocumentService: The $attachments variable holds the attachments and the body holds the attachment data. Also other data is stored within the attachment element (see h
12 reacties
Meer lezen

Microservices mindmap

"The tree" - See also   my photo page When you are fairly new within the Microservices land, there are a lot of terms fired at you. So also for my own understanding i have made a mindmap. I think it has a good status now, so that i can share it with you. As always feedback is very welcome ! You can download the mindmap here .
48 reacties
Meer lezen

Book review: Data Management at Scale (Piethein Strengholt)

 This blog is a review of the book "Data Management at Scale (See also at bol.com ) Data Management is a hot topic nowadays and this book does a fantastic job at adding value to this topic. It is a must read and one of the few technical books I finished reading in a weekend. The book gives a fantastic overview on how to implement a Data Mesh data architecture. The Data Mesh concept is explained by Martin Fowler here . The book is a good mix between conceptual and implementation architecture level. It gives a lot of examples of how this architecture at scale can work, for both small and big companies. It is practical and I used it to implement it at one of my customers. The book describes an architecture in which the focus is on the DIAL (Data- and Integration Access Layer).  On a high level the book covers the following topics: The key principles for data management at scale - Domain-Driven Design  - Domain Data Stores - Meta data management Ready Data Store The concept of servin
5 reacties
Meer lezen