Can anyone explain the relationship of ESB technology with EAI and SOA? and give me some examples.
EAI is an integration framework composed of a group of technologies and services which form a middleware/ESB to enable integration of systems and applications within an enterprise, and/or across enterprises.
ESB is software architecture model used for implementing communication between software applications in a service-oriented architecture (SOA).
Examples:
Oracle Services Bus (OSB)
http://www.oracle.com/technetwork/middleware/service-bus/overview/index.html
IBM WebSphere Enterprise Service Bus:
http://www-03.ibm.com/software/products/en/wsesb
SOA is an architectural pattern in which application components provide services to other components/clients via communication protocol (SOAP, REST).
SOA architecture is independent of any vendor, product or technology.
Related
Is it advicible to build the MSA based services on Oracle SOA or any other ESB suite for that matter? Is there any advantage or disadvantage?
If I am using Java, Spring and JPA over a message queue - say - RabbitMQ, I can achieve it in a more controlled environment with less recurring expenses. Of course will end up mixing tools like Drools or JBPM or similar to achieve things that may be OOTB (Out of the box) in the SOA Or ESB Suite. But scaling a specific service without paying licence fee for an additional environment should certainly be a good catch right?
Microservices architecture pattern applies to development of backend systems/services, whereas ESB (e.g. Oracle SOA Suite) is intended as an intermediary layer between consumers and backend services. Backend services contain rich application logic, whereas ESB services provide only intermediary functions like routing, transformation, orchestration etc.
ESB is not intended for rich application logic, though it's possible to do that.
Using ESB (e.g. Oracle SOA Suite) to host microservices is achievable, but you will get a big overhead comparing to limited functions and scalability. If you are looking for centralized API management (tracing, security etc.), you can put an API gateway into your architecture instead of full scale ESB.
What is the difference between Daas Data as Service and EAI Enterprise Application Integration ?
I understand that EAI is a framework designed to overcome the complexities of Enterprise Software integration (between ERP, SCM, CRM etc..) using ESB Enterprise Service Bus,
Would like to know where DAAS fits in the picture ?
Would also like to understand the difference between EAI and SOA
Data as a Service (DaaS) gives access to data or content collected and provided by some external service provider. Examples include post area codes, geospatial data, customer address data, market prices, economic trends, exchange rates, stock quotes and bank codes.
Enterprise Application Integration (EAI) is a general term which describes that applications in a (big) company are connected via a centralized facility rather than via a variety of proprietary point-to-point interfaces. To access a DaaS service, an application could use an EAI platform.
Applications can benefit from standardized EAI integration functions (connectivity, routing, data transformation, logging, monitoring, security, error handling ...) and do not have to implement these in themselves. Support and operation might also be more economic compared to point-to-point integration.
SOA as Service-oriented Architecture is a special architecture for integration. Rather than providing and consuming services, one could also send and receive messages or use a database as central information hub.
I study SOA and webservices for a science paper. My state of knowledge is, that every SOA architcture needs a service broker.
Webservices are concrete implementations of a SOA, so do they have a service broker after? For example I create a webservice in asp.net which returns "hallo world" By Creating it, do I create a service broker too?
Don't let fool you by answers which are copy paste from Wikipedia :-)
Webservices are concrete implementations of a SOA
This assumption/statement is wrong. At least there is no direct relationship between SOA and webservices. SOA is an architectural paradigm where a webservice is a concrete technology (stack) based on WSDL and its result, the SOAP-protocol. Nothing more. Webservices may help to establish loosely coupled service landscape, which the SOA paradigm expects. But you could also build up a SOA landscape with other technology stacks (self-written hacks, RMI, even based on REST for instance).
Repository
The thing is: When you start building up your SOA-landscape, you (or others) will code services (i.e. webservices) where your service will have a technical contract (WSDL, WADL, ..) as a base for the implementation. Your clients will ask for it and you want it to store somewhere. This somewhere is usually a service repository. You could develop your own one, use the UDDI-standard or just buy one of products by the big vendors (IBM, TIBCO, Oracle etc).
Broker
A message broker within the SOA context is some piece of software, which supports the decoupling of the connected partner systems. Commonly it's called ESB (enterprise service bus). Also one of the goals of the SOA paradigm is, that the services can be used by anyone (reusability). Therefore you don't want to connect your services by P2P-connections (aka spaghetti architecture) - just imagine that one of the service participants changes it's hardware/IP: this would be a nightmare for all the connected partner systems. That's why the ESB was invented which acts between the service consumer and the service provider.
Typically, these ESB-products support a lot of technologies or -stacks/APIs like HTTP, JMS, REST etc.
Source: I work with a self-claimed SOA landscape and thousands of different (web-)services for a big company for a long time now.
A Web service is a set of related application functions that can be programmatically invoked over the Internet. Businesses can dynamically mix and match Web services to perform complex transactions with minimal programming. Web services allow buyers and sellers all over the world to discover each other, connect dynamically, and execute transactions in real time with minimal human interaction.
Web services are self-contained, self-describing modular applications that can be published, located, and invoked across the Web.
A network component in a Web Services architecture can play one or
more fundamental roles: service provider, service broker, and service
client.
Service brokers register and categorize published services and provide search services. For example, UDDI acts as a service broker for WSDL-described Web services.
I am building a new Java EE application (thin client), and here is the application layers:
The application presentation will be with JSF2 / Spring webflow and RichFaces 4
The businees layer will be with EJB 3
The Persistance layer will be with JPA2 - Hibernate implementation
The application will run on Websphere Appliccation server.
The company owns Websephre Message Broker as an ESB.
I have got two choices, and i am trying to find out the best depending on the scalability, maintenance, performance, Best practices and entreprise architecture design, for each of them:
Deploy the business EJB3 Services on the ESB and deploy the presentation layer on a dedicated server: The presentation Layer will call the business services through the ESB
Deploy the EJB services on a dedicated WAS and deploy the presentation layer on a dedicated server: The presentation Layer will call directely the EJB services without using the ESB
It depends (as always :) ) If you plan to extend your application in the future and integrate it with other clients apart from the JSF client then ESB would be a viable solution. Else keep the things simple, i.e. everything in an application server. In case you proceed with the ESB I recommend you moving the EJB layer to the application server and exposing your application from the ESB as web services.
Here's my rec.... build your app on WAS using the architectural decisions you've made. For integration of your app to the ESB, I would vote for JMS or WebSphere MQ. You could opt for web services but as your enterprise architecture team would most likely say.... you need to have time independent communications with confirmed delivery.
If you want to also see how this all works, I would look at the IBM SOA Design Patterns or feel free to read my Redbook (IBM SOA Retail Design Patterns) for an idea of how to glue apps to the ESB.
I've been thinking about this idea and wanted to know if it's been implemented commercially. Just like there are (external) domain-specific programming languages (where instead of the int's and string's and classes you have business-specific entities and functions that are the primitive types in the language syntax/semantics), is there such a thing as a domain-specific enterprise service bus where instead of routing, orchestrating, and integrating different systems through standard protocols (SOAP/HTTP, JMS, JDBC...etc), you're actually working at more abstract layer of integrating commercial systems (in a specific industry) via their communication protocols? I'm wondering if this pattern has been used as a product for integrating different systems (of different domain standards) within a specific industry (e.g. healthcare, automotive).
Example, in healthcare. You have a central bus that commercial healthcare applications plug into and communicate to each other, get orchestrated, monitored through protocols like HL7, HIE, CCD...etc where the activities, integration, and workflows done through the bus are authored by business analysts (instead of IT staff), example: health quality officers at a hospital, clinical analysts, physicians....etc
Yes, there are many such custonized ESBs, e.g.
BridgeLink
by ISGN is a product for Real Estate Mortgage Domain.
JBoss ESB allows for the customization of transports. There is also the Redhat supported version in SOA-P
IBM has had that for years (and others like Microsoft and Oracle). It's called IBM WebSphere Transformation Extender product http://www-01.ibm.com/support/docview.wss?uid=swg27008337. They have it for several of industries.
In healthcare, this type of integration middleware is called Interface engine.
This is because this type of products are traditionally used by health IT vendors to expose standard-oriented interfaces such as HL7 messaing interfaces.
Consider a EHR vendor, who does not have HL7 expert to implement the interfaces but still wants to integrate with other systems using HL7 or IHE profiles. With an interface engine, along with the expertise provided by their service, the vendor can convert their database interface or SOAP interfaces into standard HL7 interfaces easily.
The market has several players, such as Corepoint, Ensemble, Mirth, etc.
However, these tools are quite focused on the technical level issues, including connecting endpoints, transforming data formats, and routing messages between interfaces, as what you can expect from an ESB. I don't think they are meant to be used by business analysts.