I have a business requirement to transform the business processes which are currently manual and require human interventions to automated using automation platform.
We have chosen Camunda as our BPaaS (Business Process as a Service) platform, for the primary reason of making organisation go towards Event driven + SOA (Service Oriented Architecture).
Challenge I have are related to adopting integration pattern:
Although Workday has enhanced web services to support real time integration, but i have no idea how it can effectively integrate with SAP Concur for bi directional data integration.
I am looking for any reference (in the form of low level design or architecture) which is proven
Related
As per Service-Oriented Architecture (SOA) definition, an architectural style that supports service-orientation.
Does that mean only web services (SOAP and REST) are treated as part/backbone of SOA? What about messaging services?
No and yes.
A webservice can be designed in a service orientated way, but a "service" (SOA) describes functionality, a bundle of business logic.
Service orientated architecture means, you have different systems, different users, and the way you implement your business focuses on the whole beeing a service.
The former (SOA) is something abstract, a paradigm, a commitment on how to implement something, the latter is technology (REST, SOAP, ...).
In conjunction with webservices, the "how to" is often described using WS-Business Process Execution Language (short: BPEL). It is used to orchestrate providers and consumers and allows high-traffic processes to scale in the cloud.
Consider your bank, processing many business steps per second in a very standardized fashion; using standard services like transfering money from one account to another.
Talking about Java and JMS, Oracle has a tutorial up: This example shows the steps to create a simple JMS queue in WebLogic Server 11g for testing purposes.
Service-oriented architecture (SOA) is a software architecture design pattern based on distinct pieces of software providing application functionality as services to other applications.
Key elements of a Service Oriented Architecture are, application fronted, service, service repository and service bus.
Uses open standards to integrate software assets as services, Standardizes interactions of services, Services become building blocks that form business flows, Services can be reused by other applications, thus increased Reusability, Legacy leverage, Agility, Loose coupling
and Interoperation.
The project I'm currently involved requires that business logic must be implemented in Web Service that will be consumed by the Presentation Tier Components (i.e. Web Applications).
The company has an Enterprise Service Bus, and up-to-date almost every Web Service developed is exposed through this bus. I asked some colleagues around about when to expose Service through ESB and I got this answers:
If there's an ESB, expose everything through it: There are several benefits like Load-Balancing and location transparency
If the ESB will only act as a Proxy -i.e no message transformation- just don't use it: You'll overload the ESB and lose performance. You'll better do a point-to-point connection.
You should expose a component through ESB if there's a protocol transformation (like exposing a Stored Procedure as a SOAP Service). If this isn't present you better go Point-to-Point.
So I'm curious if there's a general agreement or best-practice of when to expose a Web Service through it or not. Any reading/reference would be a great help.
From my point of view and after 4 years of experience with SOA technologies, using an ESB will always overload the system since you are adding a new layer and making all your communications go through it. Transformation (either messaging or protocol) and routing aren't to hard to accomplish without an ESB and point to point communication will have a bit higher throughput. Same happens also with business process automation, there are ways to get there without the need of an ESB.
In the other hand, the use of an ESB has several benefits in the scope of a corporation but it must be within a vision and strategy. One of the best examples is a company that has been working for a long time with a wide range of tools, each of them for a specific purpose and that made the company be distributed in teams which work in silos, ones isolated from the others. After a long time that makes interaction between teams complex and slow. A well planned SOA strategy will help to integrate all those tools and start replacing them for more meaningful lightweight items.
So, IMHO, Using an ESB just to solve a couple of "issues" in a single project without a corporate strategy isn't a good idea and, eventually, the word SOA will be banned in your company, when the problem isn't SOA by itself by rather the lack of vision and corporate strategy.
The only rule of thumb that I found regarding the use of ESBs is: The requirement of transformation, routing, business process automation (with or without human interaction), etc. in a single project is not a symptom of going SOA (almost every project has to perform transformations, routing and business process automation), but when those needs are the ones for a whole corporation then it's worth to think about it from a business point of view, never a technical one. If there isn't a business perspective, then SOA will fail.
This is a really wide topic and discussion can last for ages, I will suggest you a couple of links for further reading:
Some SOA Case Studies
Top 10 Reasons why SOA fails
What exactly is web service composition?
Composition refers to the way something is build, the new term at the moment is mash-up which basically means utilising a variety of different services in a composite application. So that functionality of disparate application can be used in one application.
I think your referring to service granularity - which means how much functionality a service exposes. a coarse grained service will expose a whole process as a consumable unit whereas a fine grained service will expose a specific unit of logic from a larger process. Obviously, it is up to the service architects to determine what granularity of service works best in the given environment.
This also, in a way has to do with the style of SOAP message you are using whether it is RPC style or document and that a service should be atomic and not hold external state. Meaning it does not need to know any more information other than that in the SOAP message to perform its function.
Hope this gives you a good starting point. The trouble with service-orientation is that it differs depending on who you read, but the main points stay the same!
Jon
Some web services which are provided for clients are abstract and composition of some smaller web services and it's called web service composition.
Sometimes there are more than one web service in order to use as the mentioned small web services, so we choose them based on QoS (Quality of Service) and many researches have been done on this subject.
Web service composition involves integration of two or more web service to achieve more added value of business functionality. A work flow composer is responsible of aggregating different web services to act as a single service according to functional requirements as well as QoS constrains. BPEL is one of the popular composers uses XML language to perform service composition. Fine-grained services perform single business task and provides higher flexibility and reusability. However, coarse-grained service involves performing complex business functionality leading to lower flexibility
The basic client-server model (even when implemented using questionable interfaces) had a presentation layer, a business layer, and a data layer. Are the directory and discovery methods using webservices models considered a entirely new layer? I would argue that the discovery layer is actually just expanding the role of the data layer to include information on where a service can be found. I am struggling to understand the interplay between webservices and the MVC framework and I am trying to understand the bigger picture as to where the directory and discovery components fit into that framework.
I would say that there is an additional layer -- the service layer -- that sits between your business layer and the presentation layer or your business layer and the data layer depending on whether you're doing a thin- or thick-"client" implementation. This layer would encapsulate service discovery and delivery, including marshaling/unmarshaling data for transfer. See Fowler's Principles of Enterprise Application Architecture Service Layer description. In his concept the service layer sits between the business layer (domain model) and the presentation layer (UI). This concept would apply to a thin-client or web-based client implementation.
I would say there are not basically 3 tiers in the web services model.
Web services is essentially SOA (Service Oriented Architecture), which can imply a multi-tier (n-tier) model. It refers to distributed computing and could be scaled up to a massive system with hundreds of "tiers".
I would agree with you that conceptually, getting your data from a service as compared to a database, could be similar to getting data from other data sourced like databases, etc., and that this could be conceived of as an additional function of the data access layer.
Of course it also depends on semantics. Often "tiers" refers to discreet parts of the overall system (i.e. front-end, middle-tier, back-end data sources, other tiers such as integration with web services, etc.); while "layers" often refers to the vertical layers in the code such as presentation, controller, business logic, data access, etc.