The Vision of Enterprise SOA and BPM

Xpand IT Senior EAI Consultant

SOA, for Service Oriented Architecture, when used adequately and widely, can give a real boost to the development of new Applications and Processes within a company. With Web Services, Applications can access to each other in a simple and standard way, so data can be accessed, shared and exchange across all the enterprise.

The SOA architecture must first provide a repository (registry) of services (web services) from which a service can be invoked and executed. Before invoking a web service, its description or interface (WSDL) must first be shared and exchange to its consumers. Then a client can invoke the required service via a standard SOAP Request (XML documents sent over HTTP).

In order to achieve a real SOA architecture, services should all be implemented on the same service bus (ESB) from which participants can act as provider or consumer of services. A Consumer is typically an application which needs to access business information or send business requests to the Bus which is in charge to route the request to the appropriate target system or component. A Provider is typically an application which has some business information to share across the enterprise (read mode) but as well information to receive and process into its own system (write mode).

Benefits

With SOA architecture, it is now possible to develop new applications by building it using existing blocks of functionalities made available through a bunch of web services, instead of developing similar pieces of code over and over again across your solutions. Applications can also be developed in an agnostic way, where the platform and the language are independent from the actual web service implementation.

From an IT perspective, the key words of SOA are: reutilization, loosely coupled, discovery, abstraction, composition. Applications are built up from services made available to the enterprise, without having to worry to some technical details such as platform, OS, language. Application from any machine and OS can make use of the web services, but can as well expose new service to the service bus so the client.

With web services, IT is now getting closer and aligned to your business and vice-versa, ensuring a good reuse of your IT assets.

Governance

• Versioning: ability to run the same service with a different version, so different consumers can use a specific version. The coexistence of 2 versions of the same service allows a quick deployment of a new version without impacting applications still using the old one. This practice should be used as a transitory state of a service;
• QoS, SLA: Quality of Service and Service Level Agreement such as availability, response time and throughput are also some important features that must be managed by your ESB;
• Monitoring: monitor and provides some statics on the usage of your web services and ESB;
• Dependencies: manages and controls the service dependencies;
• Service ownership: it is important to assign a responsible for each web service, so a person, a team is in charge of its maintenance;
• Policy: defines policies, groups and roles to control your web service access;
• Service security: SAML, WS-Security.

INTRODUCING SOA TO BPM

The most important thing to remember when introducing SOA to BPM is to remember that both technologies are complementary. SOA offers some services, often business related but representing an atomic and encapsulated functionality. BPM is very much business oriented, where different services are actually called and orchestrated all together within the same model.

SOA architecture allows a much effective and quicker way to implement a BPM model since the services exposed as web services on the ESB are made available to a business analyst already familiar with their definition, meaning and use. BPM would then have the responsibility to transform, route, manage, orchestrate and dispatch the requests to the relevant components and systems, making use of the web services when applicable. A BPM Model can also become and be seen as an entity, a piece of code where the logic is not relevant to its consumer. In this case, it is possible to expose such BPM model as a web service.

We can now understand how much BPM and web services can work together and how much they are linked to each other, since a BPM model could use web services but a BPM model itself could also be exposed as a web service. BPM models are designed by business analysts and web services are often exposed and known by the business promoting their use and making the development of a process model more proficient and straightforward.

SOA & BPM by Xpand IT

Do you like this article?! Check out our solutions & services for Business Process & Integration