Applying SOA to CA 2E Web Services

The web service implementation of our customer project sought to adopt established principles of service orientated architecture (SOA) and use them with the CA 2E development tool.  Following these principles is proven to create services with the potential to provide business benefits, both in terms of efficient software development and being flexible to adapt to business processes changes.

In researching the topic we knew that we didn't need to reinvent the wheel when it came to adopting SOA.  Our many years of working with 2E and Plex has taught us the value of software patterns, so the book SOA Design Patterns by Thomas Erl became a our principle reference.  As well as being a source of ideas and examples, the book supplied a concise narrative about what it means for software to be service oriented.  Using this provided us with a frame of reference for the application which we wanted to write, and allowed us to express these as part of the requirements documentation.  The following are modified sections of the requirements we defined, we grouped together SOA principles which we suspected had common solutions.

Services should operate in a common manner

Multiple services will be created within the application making use of the CA 2E Web Services feature, these services will be published to users outside of the corporate network.

The services will require a method of authenticating with the application in order to control which services they are allowed to use.  Having a common point of security which is shared by all of the services will allow flexibility for client applications to manage a single set of security credentials which can be used by the server to control access to all the published services.  User/function level security will need to be implemented as part of the application code within the 2E action diagram.

Each service created as part of the service layer will support the passing of a security token to allow the application code to perform a security check prior to the execution of any data retrieval or update.

Feeding back error messages from the server to the client software is another important area.  With the technical implementation available for publishing the 2E created services we have no control over the inbuilt error handling of the SOAP messages, known as fault contracts.  In order to control error information from within 2E each service will need to make use of the standard program return code (7 ALPHANUMERIC) and include an additional parameter field to relay the error description as text.  The inclusion of a meaningful error message gives the user of the service the opportunity to display the error message to their user or in an error log.  Implementation of message text with CA 2E action diagram can leverage i Series message file processing.

Interoperable, single responsibility & encapsulation

Services should be interoperable & have a single responsibility and encapsulate business rules.

Provided that a client program which is calling the 2E published web services has authenticated with the application to obtain a security token, they should be able to make use of any combination of services which they are authorised to.  Key to this is the notion that services are constructed to perform a very specific task, described within SOA as the principle of single responsibility.

As an example, consider the business process of updating a database record on an imaginary entity named "Order" with the aim of changing field "Order Status" to a new value.

It is possible to create and publish a service which allows the client software to change the status of any database record to a value of its own choosing. We could name the service “ChangeOrderStatus”.  Whilst such a service is doubtless interoperable, this breaks the purpose of single responsibility because the service in question can now be used for a number of different purposes; furthermore, the business rules which control what the acceptable status values could be are unknown to the user of the service making it less clear about when and how they should make use of the service.

A more useful encapsulation of the service would be to describe the name of it as “SetOrderStatusShipped” and then implement validation to apply the business rules which will determine the current status of the Order and then determine what the allowed new values are.  Should there be a need to change the business logic, for example the literal value of the status field changes, this is encapsulated and does not impact the user of the service.  If business rules are not met, then the standard error handling can be used to report this to the service users.

Services should serve any authorised client platform

This service layer is being designed with the knowledge that the client technology will be the SalesForce platform.  However, the services should be able to be called by any client platform in the future.  The security implementation ensures that control over the origin of web service calls can be carried out at the application level.  Once setup as a trusted client, platforms other than Force will be able to use the web services without modification.

The architecture of service orientation
When designing a 2E web service we used the following checklist of 8 points from chapter 4 of the book to score how service oriented the 2E functionality was.

1. Standardized service contract
2. Service loose coupling
3. Service abstraction
4. Service reusability
5. Service autonomy
6. Service statelessness
7. Service discoverability
8. Service composability

Our goal would always be to try and tick off all 8 of these items for each 2E service which was created.  If not, we would look again to understand whether the service had been correctly abstracted and what compramises were preventing the functionality from being described as truly service oriented.

Further posts on the adoption of SOA and creation of web services using CA 2E will follow.
Look at this page for updates

Matthew Morris is a developer and director at Desynit.  Desynit works with companies around the world, looking to improve the business benefits of their existing systems, with lower costs and less risk.  If you are interested in knowing more about this topic, or have comments, contact the author via email matthew.morris@desynit.com