Loading ...
Sorry, an error occurred while loading the content.

Re: SOA, ESB, and BPEL

Expand Messages
  • dyar
    Dear Ashraf Galal thank so much for your replay , but in my case i want to use both, BPEL for orchestrate web service in the business process layer and ESB
    Message 1 of 18 , Oct 1, 2012
    • 0 Attachment
      Dear Ashraf Galal
      thank so much for your replay , but in my case i want to use both, BPEL for orchestrate web service in the business process layer and ESB
      for integration in the integration layer of SOA architecture framework.
      So is that possible to use both ESB and BPEL in same project? and which tool is the most proper for my case?
      thanks again
      regards.

      --- In service-orientated-architecture@yahoogroups.com, Ashraf Galal <ashrafwg@...> wrote:
      >
      > When designing an SOA solution, it's not always clear whether you should
      > use a Web services BPEL process or an ESB mediation flow.
      >
      > There are use cases where either Process Server or an ESB could be used.
      >
      > For example, suppose three existing services need to be called, using a
      > two-phase commit./(composite service) /
      >
      > You could use a mediation flow in an ESB to call the services.
      >
      > Mediation flows are committed as a transaction, or rolled back.
      >
      > You could use a WS-BPEL micro-flow to call the three services, also
      > providing transaction as well.
      >
      > In this case, you could use both products as the solution.
      >
      > So you need to decide which run-time you use
      >
      > Because there is some functional overlap between Process Server and an
      > ESB. Both can work with adapters.
      >
      > Both can transform data.
      >
      > Both can support the composite service pattern.
      >
      > When faced with deciding the best software to use for a given business
      > problem, you need to decide which to use.
      >
      > The first order of business is to look through the requirements, and
      > decide if one of the choices is a better fit.
      >
      > For example, if a stateful process is required, you can immediately rule
      > out the ESB.
      >
      > If on the other hand the requirement is to process a message
      > transformation in under 0.2 seconds, clearly the ESB would be the choice.
      >
      > Although, not all projects in the real world are so cut and dried. Often
      > times, you need to examine several criteria in order to determine the
      > best option.
      >
      > Please look for both ESB and BPEL strength
      > ESB Strength
      >
      > One of the main strengths of an ESB is processing messages.
      >
      > Message in, message out, perhaps with protocol or format mediation applied.
      >
      > *_When the requirements clearly call for message processing_*, an ESB is
      > going to have several advantages, including the ability to handle
      > greater complexity in the transformations.
      >
      > *_If the requirements call for one of the basic ESB functions_*, such as
      > message routing, transformation or protocol mediation, an ESB would be
      > the clear choice.
      >
      > Another strength of an ESB is performance.
      >
      > An ESB is designed to be able to handle large volumes of messages. If,
      > for example, the requirements say that there will be 300,000 messages
      > per day, the ESB would clearly be the better choice.
      >
      > If the requirements are data-centric, an ESB is the clear choice.
      >
      > BPEL Strength
      >
      > The main strength of a BPEL engine is the ability to orchestrate a
      > business process.
      >
      > *_If the requirements call for a process with complex logic_*, BPEL will
      > be a better choice.
      >
      > WS-BPEL has container activities, such as while loops and scopes that
      > ESBs don’t support.
      >
      > The logic in an ESB is normally straightforward, while WS-BPEL can
      > handle more complex cases.
      >
      > Another strength of a WS-BPEL engine, is the ability to have a
      > long-running business process where state is maintained.
      >
      > *You should not use an ESB when state is required*, since it would take
      > a lot of custom code to maintain the state.
      >
      > *_If the requirements call for stateful processing_*, you can rule out
      > the ESB as your choice.
      >
      > If the requirements are process-centric, WS-BPEL is the clear choice.
      >
      > This is not all the story but just a guidelines, look for more details
      > in IBM sites, HP, SAP or Oracle sites.
      >
      > All the best
      >
      > Ashraf Galal
      >
      >
      >
      > > > > From: dyar <akodyar@>
      > > > >To: service-orientated-architecture@yahoogroups.com
      > > <mailto:service-orientated-architecture%40yahoogroups.com>
      > > > >Sent: Saturday, September 29, 2012 3:15 AM
      > > > >Subject: [service-orientated-architecture] SOA, ESB, and BPEL
      > > > >
      > > > >
      > > > >Â
      > > > >Hello everyone,
      > > > >I am doing research on banking system integration I will use
      > > SOA with ESB at the same time I want to use BPEL for business
      > > process, How can I use both ESB and BPEL in one project and which
      > > tool proper with this? I will be thankful for your help.
      > > > >
      > > > >Note: English is my second language, sorry for any inaccuracy
      > > sentences
      > > > >
      > > > >AKO JAAFAR
      > > > >
      > > > >
      > > > >
      > > > >
      > > > >
      > > >
      > >
      > >
      > >
      > >
      >
    • dyar
      Hello Michael Thanks so much for your replay it will be very helpful regards
      Message 2 of 18 , Oct 1, 2012
      • 0 Attachment
        Hello Michael
        Thanks so much for your replay it will be very helpful
        regards

        --- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@...> wrote:
        >
        > Hi Aco,
        >
        > I think that an ESB and your task of integration have very little in common with SOA. In essence, ESB systems are designed exactly for your task. Do not worry about SOA - you will not need it if your task is just integrate applications in different domains using a standardised interface like Web Service.
        >
        > To my knowledge, many ESB systems provide BPEL engines (sometimes, they claim BPEN, which can run BPEL scripts). Check your ESB documentation or talk to your vendor.
        >
        > You are right - BPEL can effectively orchestrate invocation of integration data flows. The only advice I can give you - never stop designing orchestration for a "sunny day"; always consider all possible ( and not possible) exceptions and alternative scenario. Starting last year, IBM promotes an design where orchestration logic is physically extracted from BPEL and placed onto an external Rule Engine (another Web Service invocation). This will give a a great flexibility in changing integration rules while reusing the same integration channel/mechanism. However, this flexibility comes for cost of additional system to deal with.
        >
        > Good luck,
        > - Michael
        >
        >
        >
        >
        >
        > >________________________________
        > > From: dyar <akodyar@...>
        > >To: service-orientated-architecture@yahoogroups.com
        > >Sent: Sunday, September 30, 2012 6:09 AM
        > >Subject: [service-orientated-architecture] Re: SOA, ESB, and BPEL
        > >
        > >
        > > 
        > >Hello Michael
        > >I plan to use ESB to integrate banking application for example retail banking with corporate banking, I am trying to implement current account service and loan service and integrate them using ESB also BPEL for orchestrate web services
        > >
        > >--- In service-orientated-architecture@yahoogroups.com, Michael Poulin <m3poulin@> wrote:
        > >>
        > >> Hi Aco,
        > >>  what you use/plan to use the ESB for?
        > >> - Michael
        > >>
        > >>
        > >>
        > >>
        > >> >________________________________
        > >> > From: dyar <akodyar@>
        > >> >To: service-orientated-architecture@yahoogroups.com
        > >> >Sent: Saturday, September 29, 2012 3:15 AM
        > >> >Subject: [service-orientated-architecture] SOA, ESB, and BPEL
        > >> >
        > >> >
        > >> > 
        > >> >Hello everyone,
        > >> >I am doing research on banking system integration I will use SOA with ESB at the same time I want to use BPEL for business process, How can I use both ESB and BPEL in one project and which tool proper with this? I will be thankful for your help.
        > >> >
        > >> >Note: English is my second language, sorry for any inaccuracy sentences
        > >> >
        > >> >AKO JAAFAR
        > >> >
        > >> >
        > >> >
        > >> >
        > >> >
        > >>
        > >
        > >
        > >
        > >
        > >
        >
      • Ashraf Galal
        For sure you can use both of them together in one solution context. In this case your are thinking about reusability as I guess. you can have an ESB gateway
        Message 3 of 18 , Oct 1, 2012
        • 0 Attachment
          For sure you can use both of them together in one solution context.

          In this case your are thinking about reusability as I guess.

          you can have  an ESB gateway in your solution to perform Aspect Oriented capabilities of virtualization, security, visibility, and traffic management required for mature exposition of services.

          Second you can use the ESB with the business process to "Standardized exposure" Requestors, in this case,  no longer require a connector. 

          I think it should be done according to the service integration maturity model.
          what was described here is more about advanced SOA, and you might not need it in the beginning of any SOA.
          Please consider your requirements first, then you will be guided accordingly.

          All the best

          Ashraf Galal

          On 10/1/2012 10:05 AM, dyar wrote:
           

          Dear Ashraf Galal
          thank so much for your replay , but in my case i want to use both, BPEL for orchestrate web service in the business process layer and ESB
          for integration in the integration layer of SOA architecture framework.
          So is that possible to use both ESB and BPEL in same project? and which tool is the most proper for my case?
          thanks again
          regards.

          --- In service-orientated-architecture@yahoogroups.com, Ashraf Galal <ashrafwg@...> wrote:
          >
          > When designing an SOA solution, it's not always clear whether you should
          > use a Web services BPEL process or an ESB mediation flow.
          >
          > There are use cases where either Process Server or an ESB could be used.
          >
          > For example, suppose three existing services need to be called, using a
          > two-phase commit./(composite service) /
          >
          > You could use a mediation flow in an ESB to call the services.
          >
          > Mediation flows are committed as a transaction, or rolled back.
          >
          > You could use a WS-BPEL micro-flow to call the three services, also
          > providing transaction as well.
          >
          > In this case, you could use both products as the solution.
          >
          > So you need to decide which run-time you use
          >
          > Because there is some functional overlap between Process Server and an
          > ESB. Both can work with adapters.
          >
          > Both can transform data.
          >
          > Both can support the composite service pattern.
          >
          > When faced with deciding the best software to use for a given business
          > problem, you need to decide which to use.
          >
          > The first order of business is to look through the requirements, and
          > decide if one of the choices is a better fit.
          >
          > For example, if a stateful process is required, you can immediately rule
          > out the ESB.
          >
          > If on the other hand the requirement is to process a message
          > transformation in under 0.2 seconds, clearly the ESB would be the choice.
          >
          > Although, not all projects in the real world are so cut and dried. Often
          > times, you need to examine several criteria in order to determine the
          > best option.
          >
          > Please look for both ESB and BPEL strength
          > ESB Strength
          >
          > One of the main strengths of an ESB is processing messages.
          >
          > Message in, message out, perhaps with protocol or format mediation applied.
          >
          > *_When the requirements clearly call for message processing_*, an ESB is
          > going to have several advantages, including the ability to handle
          > greater complexity in the transformations.
          >
          > *_If the requirements call for one of the basic ESB functions_*, such as
          > message routing, transformation or protocol mediation, an ESB would be
          > the clear choice.
          >
          > Another strength of an ESB is performance.
          >
          > An ESB is designed to be able to handle large volumes of messages. If,
          > for example, the requirements say that there will be 300,000 messages
          > per day, the ESB would clearly be the better choice.
          >
          > If the requirements are data-centric, an ESB is the clear choice.
          >
          > BPEL Strength
          >
          > The main strength of a BPEL engine is the ability to orchestrate a
          > business process.
          >
          > *_If the requirements call for a process with complex logic_*, BPEL will
          > be a better choice.
          >
          > WS-BPEL has container activities, such as while loops and scopes that
          > ESBs don’t support.
          >
          > The logic in an ESB is normally straightforward, while WS-BPEL can
          > handle more complex cases.
          >
          > Another strength of a WS-BPEL engine, is the ability to have a
          > long-running business process where state is maintained.
          >
          > *You should not use an ESB when state is required*, since it would take
          > a lot of custom code to maintain the state.
          >
          > *_If the requirements call for stateful processing_*, you can rule out
          > the ESB as your choice.
          >
          > If the requirements are process-centric, WS-BPEL is the clear choice.
          >
          > This is not all the story but just a guidelines, look for more details
          > in IBM sites, HP, SAP or Oracle sites.
          >
          > All the best
          >
          > Ashraf Galal
          >
          >
          >
          > > > > From: dyar <akodyar@>
          > > > >To: service-orientated-architecture@yahoogroups.com
          > > <mailto:service-orientated-architecture%40yahoogroups.com>
          > > > >Sent: Saturday, September 29, 2012 3:15 AM
          > > > >Subject: [service-orientated-architecture] SOA, ESB, and BPEL
          > > > >
          > > > >
          > > > >Â
          > > > >Hello everyone,
          > > > >I am doing research on banking system integration I will use
          > > SOA with ESB at the same time I want to use BPEL for business
          > > process, How can I use both ESB and BPEL in one project and which
          > > tool proper with this? I will be thankful for your help.
          > > > >
          > > > >Note: English is my second language, sorry for any inaccuracy
          > > sentences
          > > > >
          > > > >AKO JAAFAR
          > > > >
          > > > >
          > > > >
          > > > >
          > > > >
          > > >
          > >
          > >
          > >
          > >
          >


        • Michael Poulin
          To Ashraf, I provide an e-course on Bad Practice for the use of ESB on my Web Site (www.mpoulin.com/?page_id=13 ; you will need to scroll the list of courses
          Message 4 of 18 , Oct 2, 2012
          • 0 Attachment
            To Ashraf,

            I provide an e-course on Bad Practice for the use of ESB on my Web Site (www.mpoulin.com/?page_id=13 ; you will need to scroll the list of courses to find this one). I  explain the NON-service-oriented practice for an ESB systems that mistakenly called SOA and "virtualization, security, visibility" are among the most outstanding examples of it.

            I make such conclusions in line with OASIS SOA RM standard and OASIS SOA Reference Architecture Foundation. BTW, you can read this last specification in the public review available till mid-October on OASIS' Site.

            I concern about technocratic "Aspect Oriented capabilities". All service capabilities offered to the consumer must be described in the Service Description and Service Contracts. For example, if a service digitally signs its messages (which is implemented via injections), you have to describe in the Service Descriptionall conditions and policies in when this feature is applicable and when not.  In SO ecosystem, public service behaviour may not depend on your immediate wish - to insert signing or not.

            Also, please, explain what in the world  is an 'exposition' of service? Who own ESB - service? Then I can guess what this mean. If it is not a service, an 'exposition' of service does not make sense in context of ESB because it is the service provider (or steward, or owner) decide what is an exposition of the service with or without ESB. You are pushing technology into SO architecture, which is incorrect, IMO.

            What is "Standardized exposure" Requestors and where connectors came from?

            What does mean: " it should be done according to the service integration maturity model"? If a service maturity model has, for example, 5 layers (5 is the top) and an organisation is at the layer 3, does your comment mean that nobody in the organisations may design and build services for the layer 4?

            I think that the service maturity model is the derivative from the real state of service architecture and development, not the other way around: maturity model indicates but does not lead.

            Thanks,
            - Michael



            From: Ashraf Galal <ashrafwg@...>
            To: service-orientated-architecture@yahoogroups.com
            Sent: Monday, October 1, 2012 8:19 PM
            Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

             
            For sure you can use both of them together in one solution context.

            In this case your are thinking about reusability as I guess.

            you can have  an ESB gateway in your solution to perform Aspect Oriented capabilities of virtualization, security, visibility, and traffic management required for mature exposition of services .

            Second you can use the ESB with the business process to "Standardized exposure" Requestors, in this case,  no longer require a connector. 

            I think it should be done according to the service integration maturity model.
            what was described here is more about advanced SOA, and you might not need it in the beginning of any SOA.
            Please consider your requirements first, then you will be guided accordingly.

            All the best

            Ashraf Galal

            On 10/1/2012 10:05 AM, dyar wrote:
             
            Dear Ashraf Galal
            thank so much for your replay , but in my case i want to use both, BPEL for orchestrate web service in the business process layer and ESB
            for integration in the integration layer of SOA architecture framework.
            So is that possible to use both ESB and BPEL in same project? and which tool is the most proper for my case?
            thanks again
            regards.

            --- In service-orientated-architecture@yahoogroups.com, Ashraf Galal <ashrafwg@...> wrote:
            >
            > When designing an SOA solution, it's not always clear whether you should
            > use a Web services BPEL process or an ESB mediation flow.
            >
            > There are use cases where either Process Server or an ESB could be used.
            >
            > For example, suppose three existing services need to be called, using a
            > two-phase commit./(composite service) /
            >
            > You could use a mediation flow in an ESB to call the services.
            >
            > Mediation flows are committed as a transaction, or rolled back.
            >
            > You could use a WS-BPEL micro-flow to call the three services, also
            > providing transaction as well.
            >
            > In this case, you could use both products as the solution.
            >
            > So you need to decide which run-time you use
            >
            > Because there is some functional overlap between Process Server and an
            > ESB. Both can work with adapters.
            >
            > Both can transform data.
            >
            > Both can support the composite service pattern.
            >
            > When faced with deciding the best software to use for a given business
            > problem, you need to decide which to use.
            >
            > The first order of business is to look through the requirements, and
            > decide if one of the choices is a better fit.
            >
            > For example, if a stateful process is required, you can immediately rule
            > out the ESB.
            >
            > If on the other hand the requirement is to process a message
            > transformation in under 0.2 seconds, clearly the ESB would be the choice.
            >
            > Although, not all projects in the real world are so cut and dried. Often
            > times, you need to examine several criteria in order to determine the
            > best option.
            >
            > Please look for both ESB and BPEL strength
            > ESB Strength
            >
            > One of the main strengths of an ESB is processing messages.
            >
            > Message in, message out, perhaps with protocol or format mediation applied.
            >
            > *_When the requirements clearly call for message processing_*, an ESB is
            > going to have several advantages, including the ability to handle
            > greater complexity in the transformations.
            >
            > *_If the requirements call for one of the basic ESB functions_*, such as
            > message routing, transformation or protocol mediation, an ESB would be
            > the clear choice.
            >
            > Another strength of an ESB is performance.
            >
            > An ESB is designed to be able to handle large volumes of messages. If,
            > for example, the requirements say that there will be 300,000 messages
            > per day, the ESB would clearly be the better choice.
            >
            > If the requirements are data-centric, an ESB is the clear choice.
            >
            > BPEL Strength
            >
            > The main strength of a BPEL engine is the ability to orchestrate a
            > business process.
            >
            > *_If the requirements call for a process with complex logic_*, BPEL will
            > be a better choice.
            >
            > WS-BPEL has container activities, such as while loops and scopes that
            > ESBs don’t support.
            >
            > The logic in an ESB is normally straightforward, while WS-BPEL can
            > handle more complex cases.
            >
            > Another strength of a WS-BPEL engine, is the ability to have a
            > long-running business process where state is maintained.
            >
            > *You should not use an ESB when state is required*, since it would take
            > a lot of custom code to maintain the state.
            >
            > *_If the requirements call for stateful processing_*, you can rule out
            > the ESB as your choice.
            >
            > If the requirements are process-centric, WS-BPEL is the clear choice.
            >
            > This is not all the story but just a guidelines, look for more details
            > in IBM sites, HP, SAP or Oracle sites.
            >
            > All the best
            >
            > Ashraf Galal
            >
            >
            >
            > > > > From: dyar <akodyar@>
            > > > >To: service-orientated-architecture@yahoogroups.com
            > > <mailto:service-orientated-architecture%40yahoogroups.com>
            > > > >Sent: Saturday, September 29, 2012 3:15 AM
            > > > >Subject: [service-orientated-architecture] SOA, ESB, and BPEL
            > > > >
            > > > >
            > > > >Â
            > > > >Hello everyone,
            > > > >I am doing research on banking system integration I will use
            > > SOA with ESB at the same time I want to use BPEL for business
            > > process, How can I use both ESB and BPEL in one project and which
            > > tool proper with this? I will be thankful for your help.
            > > > >
            > > > >Note: English is my second language, sorry for any inaccuracy
            > > sentences
            > > > >
            > > > >AKO JAAFAR
            > > > >
            > > > >
            > > > >
            > > > >
            > > > >
            > > >
            > >
            > >
            > >
            > >
            >




          • Ashraf Galal
            Sorry I don t have the time to look at your web site or your e-course! If you speak about OASIS RM and OASIS RA which stated the following: A *reference
            Message 5 of 18 , Oct 2, 2012
            • 0 Attachment
              Sorry I don't have the time to look at your web site or your e-course!

              If you speak about OASIS RM and OASIS RA which stated the following:

              "A reference architecture models the abstract architectural elements in the domain of interest independent  of the technologies, protocols, and products that are used to implement a specific solution for the domain. It differs from a reference model in that a reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain; a reference  architecture elaborates further on the model to show a more complete picture that includes showing what  is involved in realizing the modeled entities, while staying independent of any particular solution but  instead applies to a class of solutions."

              It does not address any technologies, protocol, or products.
              Please read the purpose of those documents.

              the RAF also stated:

              "The Reference Architecture has three main views: the Business via Service view which lays the
              foundation for conducting business in the context of Service Oriented Architecture; the Realizing
              Services view which addresses the requirements for constructing a Service Oriented Architecture; and and the Owning Service Oriented Architecture view which focuses on the governance and management of SOA systems."

              If we understand the difference views presented in this document I don't think that you would have asked your questions.

              Technology is a must to implement SOA.
              Without it you cannot have SOA even if you called it SO.
              It is consider SOA best practice to use ESB gateway to improve the performance of SOA implementation.
               
              All the best

              Ashraf Galal




              On 10/2/2012 4:01 AM, Michael Poulin wrote:  
              To Ashraf,

              I provide an e-course on Bad Practice for the use of ESB on my Web Site (www.mpoulin.com/?page_id=13 ; you will need to scroll the list of courses to find this one). I  explain the NON-service-oriented practice for an ESB systems that mistakenly called SOA and "virtualization, security, visibility" are among the most outstanding examples of it.

              I make such conclusions in line with OASIS SOA RM standard and OASIS SOA Reference Architecture Foundation. BTW, you can read this last specification in the public review available till mid-October on OASIS' Site.

              I concern about technocratic "Aspect Oriented capabilities". All service capabilities offered to the consumer must be described in the Service Description and Service Contracts. For example, if a service digitally signs its messages (which is implemented via injections), you have to describe in the Service Descriptionall conditions and policies in when this feature is applicable and when not.  In SO ecosystem, public service behaviour may not depend on your immediate wish - to insert signing or not.

              Also, please, explain what in the world  is an 'exposition' of service? Who own ESB - service? Then I can guess what this mean. If it is not a service, an 'exposition' of service does not make sense in context of ESB because it is the service provider (or steward, or owner) decide what is an exposition of the service with or without ESB. You are pushing technology into SO architecture, which is incorrect, IMO.

              What is "Standardized exposure" Requestors and where connectors came from?

              What does mean: " it should be done according to the service integration maturity model"? If a service maturity model has, for example, 5 layers (5 is the top) and an organisation is at the layer 3, does your comment mean that nobody in the organisations may design and build services for the layer 4?

              I think that the service maturity model is the derivative from the real state of service architecture and development, not the other way around: maturity model indicates but does not lead.

              Thanks,
              - Michael



              From: Ashraf Galal <ashrafwg@...>
              To: service-orientated-architecture@yahoogroups.com
              Sent: Monday, October 1, 2012 8:19 PM
              Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

               
              For sure you can use both of them together in one solution context.

              In this case your are thinking about reusability as I guess.

              you can have  an ESB gateway in your solution to perform Aspect Oriented capabilities of virtualization, security, visibility, and traffic management required for mature exposition of services .

              Second you can use the ESB with the business process to "Standardized exposure" Requestors, in this case,  no longer require a connector. 

              I think it should be done according to the service integration maturity model.
              what was described here is more about advanced SOA, and you might not need it in the beginning of any SOA.
              Please consider your requirements first, then you will be guided accordingly.

              All the best

              Ashraf Galal

              On 10/1/2012 10:05 AM, dyar wrote:
               
              Dear Ashraf Galal
              thank so much for your replay , but in my case i want to use both, BPEL for orchestrate web service in the business process layer and ESB
              for integration in the integration layer of SOA architecture framework.
              So is that possible to use both ESB and BPEL in same project? and which tool is the most proper for my case?
              thanks again
              regards.

              --- In service-orientated-architecture@yahoogroups.com, Ashraf Galal <ashrafwg@...> wrote:
              >
              > When designing an SOA solution, it's not always clear whether you should
              > use a Web services BPEL process or an ESB mediation flow.
              >
              > There are use cases where either Process Server or an ESB could be used.
              >
              > For example, suppose three existing services need to be called, using a
              > two-phase commit./(composite service) /
              >
              > You could use a mediation flow in an ESB to call the services.
              >
              > Mediation flows are committed as a transaction, or rolled back.
              >
              > You could use a WS-BPEL micro-flow to call the three services, also
              > providing transaction as well.
              >
              > In this case, you could use both products as the solution.
              >
              > So you need to decide which run-time you use
              >
              > Because there is some functional overlap between Process Server and an
              > ESB. Both can work with adapters.
              >
              > Both can transform data.
              >
              > Both can support the composite service pattern.
              >
              > When faced with deciding the best software to use for a given business
              > problem, you need to decide which to use.
              >
              > The first order of business is to look through the requirements, and
              > decide if one of the choices is a better fit.
              >
              > For example, if a stateful process is required, you can immediately rule
              > out the ESB.
              >
              > If on the other hand the requirement is to process a message
              > transformation in under 0.2 seconds, clearly the ESB would be the choice.
              >
              > Although, not all projects in the real world are so cut and dried. Often
              > times, you need to examine several criteria in order to determine the
              > best option.
              >
              > Please look for both ESB and BPEL strength
              > ESB Strength
              >
              > One of the main strengths of an ESB is processing messages.
              >
              > Message in, message out, perhaps with protocol or format mediation applied.
              >
              > *_When the requirements clearly call for message processing_*, an ESB is
              > going to have several advantages, including the ability to handle
              > greater complexity in the transformations.
              >
              > *_If the requirements call for one of the basic ESB functions_*, such as
              > message routing, transformation or protocol mediation, an ESB would be
              > the clear choice.
              >
              > Another strength of an ESB is performance.
              >
              > An ESB is designed to be able to handle large volumes of messages. If,
              > for example, the requirements say that there will be 300,000 messages
              > per day, the ESB would clearly be the better choice.
              >
              > If the requirements are data-centric, an ESB is the clear choice.
              >
              > BPEL Strength
              >
              > The main strength of a BPEL engine is the ability to orchestrate a
              > business process.
              >
              > *_If the requirements call for a process with complex logic_*, BPEL will
              > be a better choice.
              >
              > WS-BPEL has container activities, such as while loops and scopes that
              > ESBs don’t support.
              >
              > The logic in an ESB is normally straightforward, while WS-BPEL can
              > handle more complex cases.
              >
              > Another strength of a WS-BPEL engine, is the ability to have a
              > long-running business process where state is maintained.
              >
              > *You should not use an ESB when state is required*, since it would take
              > a lot of custom code to maintain the state.
              >
              > *_If the requirements call for stateful processing_*, you can rule out
              > the ESB as your choice.
              >
              > If the requirements are process-centric, WS-BPEL is the clear choice.
              >
              > This is not all the story but just a guidelines, look for more details
              > in IBM sites, HP, SAP or Oracle sites.
              >
              > All the best
              >
              > Ashraf Galal
              >
              >
              >
              > > > > From: dyar <akodyar@>
              > > > >To: service-orientated-architecture@yahoogroups.com
              > > <mailto:service-orientated-architecture%40yahoogroups.com>
              > > > >Sent: Saturday, September 29, 2012 3:15 AM
              > > > >Subject: [service-orientated-architecture] SOA, ESB, and BPEL
              > > > >
              > > > >
              > > > >Â
              > > > >Hello everyone,
              > > > >I am doing research on banking system integration I will use
              > > SOA with ESB at the same time I want to use BPEL for business
              > > process, How can I use both ESB and BPEL in one project and which
              > > tool proper with this? I will be thankful for your help.
              > > > >
              > > > >Note: English is my second language, sorry for any inaccuracy
              > > sentences
              > > > >
              > > > >AKO JAAFAR
              > > > >
              > > > >
              > > > >
              > > > >
              > > > >
              > > >
              > >
              > >
              > >
              > >
              >





            • David Chappell
              Nice writeup. BTW Ako, I m surprised that anyone would be performing an ESB/BPEL evaluation for a bank these days. Usually there s an enterprise architecture
              Message 6 of 18 , Oct 3, 2012
              • 0 Attachment
                Nice writeup.
                BTW Ako, I'm surprised that anyone would be performing an ESB/BPEL evaluation for a bank these days.  Usually there's an enterprise architecture group that has already standardized on a platform, and that platform is Oracle or IBM, and that's what your stuck with using for better or for worse.

                I can highly recommend the products from 2 of my former employers, Progress and Oracle.  Both have an ESB that will suit your needs, and both have process modeling companion products.  Both have them integrated such that you can freely use the ESB for doing integration, data transformation, and routing, while you can use the orchestration engine for more complex long-running processes.

                The other products mentioned in this thread would probably do you just fine.  I have been using Websphere ESB on a recent project and its not bad.  However, I caution you that every ESB is different once you pull it out of the box, and you should spend a bit more time evaluating what you need.  If you don't have time to go through Michael's course, or do a proper ESB evaluation based on your requirements, then I suspect the rest of the project might be prone to that kind of problem as well.

                Doing a proper integration project and getting it right requires lots of up-front requirements definition, mostly around data mapping, that have nothing to do with selecting an ESB.  I do hope you are spending lots of time on that.
                Cheers,
                Dave

                On Sun, Sep 30, 2012 at 11:27 PM, Ashraf Galal <ashrafwg@...> wrote:
                 

                When designing an SOA solution, it's not always clear whether you should use a Web services BPEL process or an ESB mediation flow.

                There are use cases where either Process Server or an ESB could be used.

                For example, suppose three existing services need to be called, using a two-phase commit. (composite service)

                You could use a mediation flow in an ESB to call the services.

                Mediation flows are committed as a transaction, or rolled back.

                You could use a WS-BPEL micro-flow to call the three services, also providing transaction as well. 

                In this case, you could use both products as the solution.

                So you need to decide which run-time you use

                Because there is some functional overlap between Process Server and an ESB. Both can work with adapters.

                Both can transform data.

                Both can support the composite service pattern.

                When faced with deciding the best software to use for a given business problem, you need to decide which to use.

                The first order of business is to look through the requirements, and decide if one of the choices is a better fit.

                For example, if a stateful process is required, you can immediately rule out the ESB.

                If on the other hand the requirement is to process a message transformation in under 0.2 seconds, clearly the ESB would be the choice.

                Although, not all projects in the real world are so cut and dried. Often times, you need to examine several criteria in order to determine the best option.

                Please look for both ESB and BPEL strength
                ESB Strength

                One of the main strengths of an ESB is processing messages.

                Message in, message out, perhaps with protocol or format mediation applied.

                When the requirements clearly call for message processing, an ESB is going to have several advantages, including the ability to handle greater complexity in the transformations.

                If the requirements call for one of the basic ESB functions, such as message routing, transformation or protocol mediation, an ESB would be the clear choice.

                Another strength of an ESB is performance.

                An ESB is designed to be able to handle large volumes of messages. If, for example, the requirements say that there will be 300,000 messages per day, the ESB would clearly be the better choice.

                If the requirements are data-centric, an ESB is the clear choice.

                BPEL Strength

                The main strength of a BPEL engine is the ability to orchestrate a business process.

                If the requirements call for a process with complex logic, BPEL will be a better choice.

                WS-BPEL has container activities, such as while loops and scopes that ESBs don’t support.

                The logic in an ESB is normally straightforward, while WS-BPEL can handle more complex cases.

                Another strength of a WS-BPEL engine, is the ability to have a long-running business process where state is maintained.

                You should not use an ESB when state is required, since it would take a lot of custom code to maintain the state.

                 If the requirements call for stateful processing, you can rule out the ESB as your choice.

                If the requirements are process-centric, WS-BPEL is the clear choice.

                This is not all the story but just a guidelines, look for more details in IBM sites, HP, SAP or Oracle sites.

                All the best

                Ashraf Galal



                > > From: dyar <akodyar@...>
                > >To: service-orientated-architecture@yahoogroups.com
                > >Sent: Saturday, September 29, 2012 3:15 AM
                > >Subject: [service-orientated-architecture] SOA, ESB, and BPEL
                > >
                > >
                > > 
                > >Hello everyone,
                > >I am doing research on banking system integration I will use SOA with ESB at the same time I want to use BPEL for business process, How can I use both ESB and BPEL in one project and which tool proper with this? I will be thankful for your help.
                > >
                > >Note: English is my second language, sorry for any inaccuracy sentences
                > >
                > >AKO JAAFAR
                > >
                > >
                > >
                > >
                > >
                >







                --
                David A. Chappell
                Chappell Consulting Corp.
                Service Orientation and Architecture

                author, "Enterprise Service Bus" (O'Reilly)  | "Modern SOA Infrastructure" (Prentice-Hall) |
                "SOA Design Patterns" (Prentice-Hall) | “Java Web Services” (O'Reilly) |
                "The Java Message Service" (O'Reilly) | "Professional ebXML Foundations", (Wrox Press)


                617-510-6566 (mobile)
                http://www.linkedin.com/in/davidchappell
                http://twitter.com/davechappell
              • Michael Poulin
                Ashraf, OASIS deliberately stay s away from any particular technology because it distinguished between Architecture and Implementation of an Architecture.
                Message 7 of 18 , Oct 3, 2012
                • 0 Attachment
                  Ashraf,

                  OASIS deliberately stay s away from any particular technology because it distinguished between Architecture and Implementation of an Architecture. Implementation may use any available technologies and it should not impact the architecture.

                  Reference Architecture may be implemented in two ways -  as a framework applicable 'as is' and a s a set of definitions of architectural elements and relationships between them. OASIS has chosen the latter one.

                  No one objects that "Technology is a must to implement SOA", though if one implements service-oriented solution via manual operations, then technology is not needed. This, however, is the future understanding of SOA implementation.

                  That is, I disagree with "Without it you cannot have SOA even if you called it SO": SOA is about ARCHITECTURE and a technology is about one of its possible implementations.

                  As of ESB and SOA best practice, I also believe that this is just a vendor's buzz. A company can implement the same ESB functionality using existing messaging systems and application servers. This was and still is a major problem for CFOs in many companies - nobody can explain why they need to spend money on ESB is they have all technical capabilities in the company already. Moreover, many modern EAI systems can do the ESB's job. This is proved by the fact that IBM and ORACLE have more than 3 product offerings each that can replace ESB.

                  ESB is not a SOA implementation Best Practice but a convenient system if your company does not anything in the integration area.

                  - Michael


                  From: Ashraf Galal <ashrafwg@...>
                  To: service-orientated-architecture@yahoogroups.com
                  Sent: Wednesday, October 3, 2012 2:41 AM
                  Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

                   
                  Sorry I don't have the time to look at your web site or your e-course!

                  If you speak about OASIS RM and OASIS RA which stated the following:

                  "A reference architecture models the abstract architectural elements in the domain of interest independent  of the technologies, protocols, and products that are used to implement a specific solution for the domain. It differs from a reference model in that a reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain; a reference  architecture elaborates further on the model to show a more complete picture that includes showing what  is involved in realizing the modeled entities, while staying independent of any particular solution but  instead applies to a class of solutions."

                  It does not address any technologies, protocol, or products.
                  Please read the purpose of those documents.

                  the RAF also stated:

                  "The Reference Architecture has three main views: the Business via Service view which lays the
                  foundation for conducting business in the context of Service Oriented Architecture; the Realizing
                  Services view which addresses the requirements for constructing a Service Oriented Architecture; and and the Owning Service Oriented Architecture view which focuses on the governance and management of SOA systems."

                  If we understand the difference views presented in this document I don't think that you would have asked your questions.

                  Technology is a must to implement SOA.
                  Without it you cannot have SOA even if you called it SO.
                  It is consider SOA best practice to use ESB gateway to improve the performance of SOA implementation.
                   
                  All the best

                  Ashraf Galal




                  On 10/2/2012 4:01 AM, Michael Poulin wrote:
                   
                  To Ashraf,

                  I provide an e-course on Bad Practice for the use of ESB on my Web Site (www.mpoulin.com/?page_id=13 ; you will need to scroll the list of courses to find this one). I  explain the NON-service-oriented practice for an ESB systems that mistakenly called SOA and "virtualization, security, visibility" are among the most outstanding examples of it.

                  I make such conclusions in line with OASIS SOA RM standard and OASIS SOA Reference Architecture Foundation. BTW, you can read this last specification in the public review available till mid-October on OASIS' Site.

                  I concern about technocratic "Aspect Oriented capabilities". All service capabilities offered to the consumer must be described in the Service Description and Service Contracts. For example, if a service digitally signs its messages (which is implemented via injections), you have to describe in the Service Descriptionall conditions and policies in when this feature is applicable and when not.  In SO ecosystem, public service behaviour may not depend on your immediate wish - to insert signing or not.

                  Also, please, explain what in the world  is an 'exposition' of service? Who own ESB - service? Then I can guess what this mean. If it is not a service, an 'exposition' of service does not make sense in context of ESB because it is the service provider (or steward, or owner) decide what is an exposition of the service with or without ESB. You are pushing technology into SO architecture, which is incorrect, IMO.

                  What is "Standardized exposure" Requestors and where connectors came from?

                  What does mean: " it should be done according to the service integration maturity model"? If a service maturity model has, for example, 5 layers (5 is the top) and an organisation is at the layer 3, does your comment mean that nobody in the organisations may design and build services for the layer 4?

                  I think that the service maturity model is the derivative from the real state of service architecture and development, not the other way around: maturity model indicates but does not lead.

                  Thanks,
                  - Michael



                  From: Ashraf Galal <ashrafwg@...>
                  To: service-orientated-architecture@yahoogroups.com
                  Sent: Monday, October 1, 2012 8:19 PM
                  Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

                   
                  For sure you can use both of them together in one solution context.

                  In this case your are thinking about reusability as I guess.

                  you can have  an ESB gateway in your solution to perform Aspect Oriented capabilities of virtualization, security, visibility, and traffic management required for mature exposition of services .

                  Second you can use the ESB with the business process to "Standardized exposure" Requestors, in this case,  no longer require a connector. 

                  I think it should be done according to the service integration maturity model.
                  what was described here is more about advanced SOA, and you might not need it in the beginning of any SOA.
                  Please consider your requirements first, then you will be guided accordingly.

                  All the best

                  Ashraf Galal

                  On 10/1/2012 10:05 AM, dyar wrote:
                   
                  Dear Ashraf Galal
                  thank so much for your replay , but in my case i want to use both, BPEL for orchestrate web service in the business process layer and ESB
                  for integration in the integration layer of SOA architecture framework.
                  So is that possible to use both ESB and BPEL in same project? and which tool is the most proper for my case?
                  thanks again
                  regards.

                  --- In service-orientated-architecture@yahoogroups.com, Ashraf Galal <ashrafwg@...> wrote:
                  >
                  > When designing an SOA solution, it's not always clear whether you should
                  > use a Web services BPEL process or an ESB mediation flow.
                  >
                  > There are use cases where either Process Server or an ESB could be used.
                  >
                  > For example, suppose three existing services need to be called, using a
                  > two-phase commit./(composite service) /
                  >
                  > You could use a mediation flow in an ESB to call the services.
                  >
                  > Mediation flows are committed as a transaction, or rolled back.
                  >
                  > You could use a WS-BPEL micro-flow to call the three services, also
                  > providing transaction as well.
                  >
                  > In this case, you could use both products as the solution.
                  >
                  > So you need to decide which run-time you use
                  >
                  > Because there is some functional overlap between Process Server and an
                  > ESB. Both can work with adapters.
                  >
                  > Both can transform data.
                  >
                  > Both can support the composite service pattern.
                  >
                  > When faced with deciding the best software to use for a given business
                  > problem, you need to decide which to use.
                  >
                  > The first order of business is to look through the requirements, and
                  > decide if one of the choices is a better fit.
                  >
                  > For example, if a stateful process is required, you can immediately rule
                  > out the ESB.
                  >
                  > If on the other hand the requirement is to process a message
                  > transformation in under 0.2 seconds, clearly the ESB would be the choice.
                  >
                  > Although, not all projects in the real world are so cut and dried. Often
                  > times, you need to examine several criteria in order to determine the
                  > best option.
                  >
                  > Please look for both ESB and BPEL strength
                  > ESB Strength
                  >
                  > One of the main strengths of an ESB is processing messages.
                  >
                  > Message in, message out, perhaps with protocol or format mediation applied.
                  >
                  > *_When the requirements clearly call for message processing_*, an ESB is
                  > going to have several advantages, including the ability to handle
                  > greater complexity in the transformations.
                  >
                  > *_If the requirements call for one of the basic ESB functions_*, such as
                  > message routing, transformation or protocol mediation, an ESB would be
                  > the clear choice.
                  >
                  > Another strength of an ESB is performance.
                  >
                  > An ESB is designed to be able to handle large volumes of messages. If,
                  > for example, the requirements say that there will be 300,000 messages
                  > per day, the ESB would clearly be the better choice.
                  >
                  > If the requirements are data-centric, an ESB is the clear choice.
                  >
                  > BPEL Strength
                  >
                  > The main strength of a BPEL engine is the ability to orchestrate a
                  > business process.
                  >
                  > *_If the requirements call for a process with complex logic_*, BPEL will
                  > be a better choice.
                  >
                  > WS-BPEL has container activities, such as while loops and scopes that
                  > ESBs don’t support.
                  >
                  > The logic in an ESB is normally straightforward, while WS-BPEL can
                  > handle more complex cases.
                  >
                  > Another strength of a WS-BPEL engine, is the ability to have a
                  > long-running business process where state is maintained.
                  >
                  > *You should not use an ESB when state is required*, since it would take
                  > a lot of custom code to maintain the state.
                  >
                  > *_If the requirements call for stateful processing_*, you can rule out
                  > the ESB as your choice.
                  >
                  > If the requirements are process-centric, WS-BPEL is the clear choice.
                  >
                  > This is not all the story but just a guidelines, look for more details
                  > in IBM sites, HP, SAP or Oracle sites.
                  >
                  > All the best
                  >
                  > Ashraf Galal
                  >
                  >
                  >
                  > > > > From: dyar <akodyar@>
                  > > > >To: service-orientated-architecture@yahoogroups.com
                  > > <mailto:service-orientated-architecture%40yahoogroups.com>
                  > > > >Sent: Saturday, September 29, 2012 3:15 AM
                  > > > >Subject: [service-orientated-architecture] SOA, ESB, and BPEL
                  > > > >
                  > > > >
                  > > > >Â
                  > > > >Hello everyone,
                  > > > >I am doing research on banking system integration I will use
                  > > SOA with ESB at the same time I want to use BPEL for business
                  > > process, How can I use both ESB and BPEL in one project and which
                  > > tool proper with this? I will be thankful for your help.
                  > > > >
                  > > > >Note: English is my second language, sorry for any inaccuracy
                  > > sentences
                  > > > >
                  > > > >AKO JAAFAR
                  > > > >
                  > > > >
                  > > > >
                  > > > >
                  > > > >
                  > > >
                  > >
                  > >
                  > >
                  > >
                  >







                • David Chappell
                  Michael, I disagree with your view. I have worked for 2 ESB vendors over the years and I can assure you that they aren t out to screw you; they provide
                  Message 8 of 18 , Oct 4, 2012
                  • 0 Attachment
                    Michael,
                    I disagree with your view.  I have worked for 2 ESB vendors over the years and I can assure you that they aren't out to screw you; they provide software that helps you with your integration, whether it be based on SOA principles or not.  And since I no longer work for an ESB vendor, I also don't have to sugar-coat my opinions to avoid offending anyone. 

                    Anyone who tries to implement their own ESB is a fool, is wasting their CFO's time and money, and should be fired. Why would you waste time building something that a host of vendors have put the effort into building for you?  You don't build the rest of your development tools do you?

                    During my tenure as an ESB vendor, and also in my successful independent consulting practice, I have come across many of these such endeavors based on ill-informed people who think they would do better to build something themselves.  The result has been a disaster every time.  Perhaps its why this gent is in a last minute hurry to find one; because some moron thought it better to build one and failed - another common occurance.

                    That being said - I have also seen integration and SOA projects gone terribly wrong, which are based on ESB.  In either case the problem is always due to the organization's inability to get their act together and decide how to build their interfaces, and how to structure their organization in a way that fosters cross-departmental collaboration.  Those are the biggest challenges when embarking on an effort that attempts to follow SOA principles.  Imagine also being hampered by trying to build something as sophisticated as an ESB at the same time.

                    Regarding EAI tools: there no longer is any distinction.  The lines between ESB and EAI products have been blurred as ESB tools have added process modeling, adapter toolkits, and visual data mapping tools, and EAI vendors have "modernized" their EAI tools to support things like SOAP and ReST.
                    Cheers,
                    Dave

                    On Wed, Oct 3, 2012 at 7:46 PM, Michael Poulin <m3poulin@...> wrote:
                     

                    Ashraf,

                    OASIS deliberately stay s away from any particular technology because it distinguished between Architecture and Implementation of an Architecture. Implementation may use any available technologies and it should not impact the architecture.

                    Reference Architecture may be implemented in two ways -  as a framework applicable 'as is' and a s a set of definitions of architectural elements and relationships between them. OASIS has chosen the latter one.

                    No one objects that "Technology is a must to implement SOA", though if one implements service-oriented solution via manual operations, then technology is not needed. This, however, is the future understanding of SOA implementation.

                    That is, I disagree with "Without it you cannot have SOA even if you called it SO": SOA is about ARCHITECTURE and a technology is about one of its possible implementations.

                    As of ESB and SOA best practice, I also believe that this is just a vendor's buzz. A company can implement the same ESB functionality using existing messaging systems and application servers. This was and still is a major problem for CFOs in many companies - nobody can explain why they need to spend money on ESB is they have all technical capabilities in the company already. Moreover, many modern EAI systems can do the ESB's job. This is proved by the fact that IBM and ORACLE have more than 3 product offerings each that can replace ESB.

                    ESB is not a SOA implementation Best Practice but a convenient system if your company does not anything in the integration area.

                    - Michael

                    Sent: Wednesday, October 3, 2012 2:41 AM

                    Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

                     
                    Sorry I don't have the time to look at your web site or your e-course!

                    If you speak about OASIS RM and OASIS RA which stated the following:

                    "A reference architecture models the abstract architectural elements in the domain of interest independent  of the technologies, protocols, and products that are used to implement a specific solution for the domain. It differs from a reference model in that a reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain; a reference  architecture elaborates further on the model to show a more complete picture that includes showing what  is involved in realizing the modeled entities, while staying independent of any particular solution but  instead applies to a class of solutions."

                    It does not address any technologies, protocol, or products.
                    Please read the purpose of those documents.

                    the RAF also stated:

                    "The Reference Architecture has three main views: the Business via Service view which lays the
                    foundation for conducting business in the context of Service Oriented Architecture; the Realizing
                    Services view which addresses the requirements for constructing a Service Oriented Architecture; and and the Owning Service Oriented Architecture view which focuses on the governance and management of SOA systems."

                    If we understand the difference views presented in this document I don't think that you would have asked your questions.

                    Technology is a must to implement SOA.
                    Without it you cannot have SOA even if you called it SO.
                    It is consider SOA best practice to use ESB gateway to improve the performance of SOA implementation.
                     
                    All the best

                    Ashraf Galal




                    On 10/2/2012 4:01 AM, Michael Poulin wrote:
                     
                    To Ashraf,

                    I provide an e-course on Bad Practice for the use of ESB on my Web Site (www.mpoulin.com/?page_id=13 ; you will need to scroll the list of courses to find this one). I  explain the NON-service-oriented practice for an ESB systems that mistakenly called SOA and "virtualization, security, visibility" are among the most outstanding examples of it.

                    I make such conclusions in line with OASIS SOA RM standard and OASIS SOA Reference Architecture Foundation. BTW, you can read this last specification in the public review available till mid-October on OASIS' Site.

                    I concern about technocratic "Aspect Oriented capabilities". All service capabilities offered to the consumer must be described in the Service Description and Service Contracts. For example, if a service digitally signs its messages (which is implemented via injections), you have to describe in the Service Descriptionall conditions and policies in when this feature is applicable and when not.  In SO ecosystem, public service behaviour may not depend on your immediate wish - to insert signing or not.

                    Also, please, explain what in the world  is an 'exposition' of service? Who own ESB - service? Then I can guess what this mean. If it is not a service, an 'exposition' of service does not make sense in context of ESB because it is the service provider (or steward, or owner) decide what is an exposition of the service with or without ESB. You are pushing technology into SO architecture, which is incorrect, IMO.

                    What is "Standardized exposure" Requestors and where connectors came from?

                    What does mean: " it should be done according to the service integration maturity model"? If a service maturity model has, for example, 5 layers (5 is the top) and an organisation is at the layer 3, does your comment mean that nobody in the organisations may design and build services for the layer 4?

                    I think that the service maturity model is the derivative from the real state of service architecture and development, not the other way around: maturity model indicates but does not lead.

                    Thanks,
                    - Michael



                    From: Ashraf Galal <ashrafwg@...>
                    To: service-orientated-architecture@yahoogroups.com
                    Sent: Monday, October 1, 2012 8:19 PM
                    Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

                     
                    For sure you can use both of them together in one solution context.

                    In this case your are thinking about reusability as I guess.

                    you can have  an ESB gateway in your solution to perform Aspect Oriented capabilities of virtualization, security, visibility, and traffic management required for mature exposition of services .

                    Second you can use the ESB with the business process to "Standardized exposure" Requestors, in this case,  no longer require a connector. 

                    I think it should be done according to the service integration maturity model.
                    what was described here is more about advanced SOA, and you might not need it in the beginning of any SOA.
                    Please consider your requirements first, then you will be guided accordingly.

                    All the best

                    Ashraf Galal

                    On 10/1/2012 10:05 AM, dyar wrote:
                     
                    Dear Ashraf Galal
                    thank so much for your replay , but in my case i want to use both, BPEL for orchestrate web service in the business process layer and ESB
                    for integration in the integration layer of SOA architecture framework.
                    So is that possible to use both ESB and BPEL in same project? and which tool is the most proper for my case?
                    thanks again
                    regards.

                    --- In service-orientated-architecture@yahoogroups.com, Ashraf Galal <ashrafwg@...> wrote:
                    >
                    > When designing an SOA solution, it's not always clear whether you should
                    > use a Web services BPEL process or an ESB mediation flow.
                    >
                    > There are use cases where either Process Server or an ESB could be used.
                    >
                    > For example, suppose three existing services need to be called, using a
                    > two-phase commit./(composite service) /
                    >
                    > You could use a mediation flow in an ESB to call the services.
                    >
                    > Mediation flows are committed as a transaction, or rolled back.
                    >
                    > You could use a WS-BPEL micro-flow to call the three services, also
                    > providing transaction as well.
                    >
                    > In this case, you could use both products as the solution.
                    >
                    > So you need to decide which run-time you use
                    >
                    > Because there is some functional overlap between Process Server and an
                    > ESB. Both can work with adapters.
                    >
                    > Both can transform data.
                    >
                    > Both can support the composite service pattern.
                    >
                    > When faced with deciding the best software to use for a given business
                    > problem, you need to decide which to use.
                    >
                    > The first order of business is to look through the requirements, and
                    > decide if one of the choices is a better fit.
                    >
                    > For example, if a stateful process is required, you can immediately rule
                    > out the ESB.
                    >
                    > If on the other hand the requirement is to process a message
                    > transformation in under 0.2 seconds, clearly the ESB would be the choice.
                    >
                    > Although, not all projects in the real world are so cut and dried. Often
                    > times, you need to examine several criteria in order to determine the
                    > best option.
                    >
                    > Please look for both ESB and BPEL strength
                    > ESB Strength
                    >
                    > One of the main strengths of an ESB is processing messages.
                    >
                    > Message in, message out, perhaps with protocol or format mediation applied.
                    >
                    > *_When the requirements clearly call for message processing_*, an ESB is
                    > going to have several advantages, including the ability to handle
                    > greater complexity in the transformations.
                    >
                    > *_If the requirements call for one of the basic ESB functions_*, such as
                    > message routing, transformation or protocol mediation, an ESB would be
                    > the clear choice.
                    >
                    > Another strength of an ESB is performance.
                    >
                    > An ESB is designed to be able to handle large volumes of messages. If,
                    > for example, the requirements say that there will be 300,000 messages
                    > per day, the ESB would clearly be the better choice.
                    >
                    > If the requirements are data-centric, an ESB is the clear choice.
                    >
                    > BPEL Strength
                    >
                    > The main strength of a BPEL engine is the ability to orchestrate a
                    > business process.
                    >
                    > *_If the requirements call for a process with complex logic_*, BPEL will
                    > be a better choice.
                    >
                    > WS-BPEL has container activities, such as while loops and scopes that
                    > ESBs don’t support.
                    >
                    > The logic in an ESB is normally straightforward, while WS-BPEL can
                    > handle more complex cases.
                    >
                    > Another strength of a WS-BPEL engine, is the ability to have a
                    > long-running business process where state is maintained.
                    >
                    > *You should not use an ESB when state is required*, since it would take
                    > a lot of custom code to maintain the state.
                    >
                    > *_If the requirements call for stateful processing_*, you can rule out
                    > the ESB as your choice.
                    >
                    > If the requirements are process-centric, WS-BPEL is the clear choice.
                    >
                    > This is not all the story but just a guidelines, look for more details
                    > in IBM sites, HP, SAP or Oracle sites.
                    >
                    > All the best
                    >
                    > Ashraf Galal
                    >
                    >
                    >
                    > > > > From: dyar <akodyar@>
                    > > > >To: service-orientated-architecture@yahoogroups.com
                    > > <mailto:service-orientated-architecture%40yahoogroups.com>
                    > > > >Sent: Saturday, September 29, 2012 3:15 AM
                    > > > >Subject: [service-orientated-architecture] SOA, ESB, and BPEL
                    > > > >
                    > > > >
                    > > > >Â
                    > > > >Hello everyone,
                    > > > >I am doing research on banking system integration I will use
                    > > SOA with ESB at the same time I want to use BPEL for business
                    > > process, How can I use both ESB and BPEL in one project and which
                    > > tool proper with this? I will be thankful for your help.
                    > > > >
                    > > > >Note: English is my second language, sorry for any inaccuracy
                    > > sentences
                    > > > >
                    > > > >AKO JAAFAR
                    > > > >
                    > > > >
                    > > > >
                    > > > >
                    > > > >
                    > > >
                    > >
                    > >
                    > >
                    > >
                    >










                    --
                    David A. Chappell
                    Chappell Consulting Corp.
                    Service Orientation and Architecture

                    author, "Enterprise Service Bus" (O'Reilly)  | "Modern SOA Infrastructure" (Prentice-Hall) |
                    "SOA Design Patterns" (Prentice-Hall) | “Java Web Services” (O'Reilly) |
                    "The Java Message Service" (O'Reilly) | "Professional ebXML Foundations", (Wrox Press)


                    617-510-6566 (mobile)
                    http://www.linkedin.com/in/davidchappell
                    http://twitter.com/davechappell
                  • Michael Poulin
                    It is a great observation, David! Where are you now? On your own? - Michael ... 2012 3:15 AM ... [service-orientated-architecture] SOA, ESB, and BPEL ...
                    Message 9 of 18 , Oct 4, 2012
                    • 0 Attachment
                      It is a great observation, David!
                      Where are you now? On your own?

                      - Michael


                      From: David Chappell <dave.chappell.1@...>
                      To: service-orientated-architecture@yahoogroups.com
                      Sent: Wednesday, October 3, 2012 6:51 PM
                      Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

                       
                      Nice writeup.
                      BTW Ako, I'm surprised that anyone would be performing an ESB/BPEL evaluation for a bank these days.  Usually there's an enterprise architecture group that has already standardized on a platform, and that platform is Oracle or IBM, and that's what your stuck with using for better or for worse.

                      I can highly recommend the products from 2 of my former employers, Progress and Oracle.  Both have an ESB that will suit your needs, and both have process modeling companion products.  Both have them integrated such that you can freely use the ESB for doing integration, data transformation, and routing, while you can use the orchestration engine for more complex long-running processes.

                      The other products mentioned in this thread would probably do you just fine.  I have been using Websphere ESB on a recent project and its not bad.  However, I caution you that every ESB is different once you pull it out of the box, and you should spend a bit more time evaluating what you need.  If you don't have time to go through Michael's course, or do a proper ESB evaluation based on your requirements, then I suspect the rest of the project might be prone to that kind of problem as well.

                      Doing a proper integration project and getting it right requires lots of up-front requirements definition, mostly around data mapping, that have nothing to do with selecting an ESB.  I do hope you are spending lots of time on that.
                      Cheers,
                      Dave

                      On Sun, Sep 30, 2012 at 11:27 PM, Ashraf Galal <ashrafwg@...> wrote:
                       
                      When designing an SOA solution, it's not always clear whether you should use a Web services BPEL process or an ESB mediation flow.
                      There are use cases where either Process Server or an ESB could be used.
                      For example, suppose three existing services need to be called, using a two-phase commit. (composite service)
                      You could use a mediation flow in an ESB to call the services.
                      Mediation flows are committed as a transaction, or rolled back.
                      You could use a WS-BPEL micro-flow to call the three services, also providing transaction as well. 
                      In this case, you could use both products as the solution.
                      So you need to decide which run-time you use
                      Because there is some functional overlap between Process Server and an ESB. Both can work with adapters.
                      Both can transform data.
                      Both can support the composite service pattern.
                      When faced with deciding the best software to use for a given business problem, you need to decide which to use.
                      The first order of business is to look through the requirements, and decide if one of the choices is a better fit.
                      For example, if a stateful process is required, you can immediately rule out the ESB.
                      If on the other hand the requirement is to process a message transformation in under 0.2 seconds, clearly the ESB would be the choice.
                      Although, not all projects in the real world are so cut and dried. Often times, you need to examine several criteria in order to determine the best option.
                      Please look for both ESB and BPEL strength
                      ESB Strength
                      One of the main strengths of an ESB is processing messages.
                      Message in, message out, perhaps with protocol or format mediation applied.
                      When the requirements clearly call for message processing, an ESB is going to have several advantages, including the ability to handle greater complexity in the transformations.
                      If the requirements call for one of the basic ESB functions, such as message routing, transformation or protocol mediation, an ESB would be the clear choice.
                      Another strength of an ESB is performance.
                      An ESB is designed to be able to handle large volumes of messages. If, for example, the requirements say that there will be 300,000 messages per day, the ESB would clearly be the better choice.
                      If the requirements are data-centric, an ESB is the clear choice.
                      BPEL Strength
                      The main strength of a BPEL engine is the ability to orchestrate a business process.
                      If the requirements call for a process with complex logic, BPEL will be a better choice.
                      WS-BPEL has container activities, such as while loops and scopes that ESBs don’t support.
                      The logic in an ESB is normally straightforward, while WS-BPEL can handle more complex cases.
                      Another strength of a WS-BPEL engine, is the ability to have a long-running business process where state is maintained.
                      You should not use an ESB when state is required, since it would take a lot of custom code to maintain the state.
                       If the requirements call for stateful processing, you can rule out the ESB as your choice.
                      If the requirements are process-centric, WS-BPEL is the clear choice.
                      This is not all the story but just a guidelines, look for more details in IBM sites, HP, SAP or Oracle sites.
                      All the best
                      Ashraf Galal


                      > > From: dyar <akodyar@...>
                      > >To: service-orientated-architecture@yahoogroups.com
                      > >Sent: Saturday, September 29, 2012 3:15 AM
                      > >Subject: [service-orientated-architecture] SOA, ESB, and BPEL
                      > >
                      > >
                      > > 
                      > >Hello everyone,
                      > >I am doing research on banking system integration I will use SOA with ESB at the same time I want to use BPEL for business process, How can I use both ESB and BPEL in one project and which tool proper with this? I will be thankful for your help.
                      > >
                      > >Note: English is my second language, sorry for any inaccuracy sentences
                      > >
                      > >AKO JAAFAR
                      > >
                      > >
                      > >
                      > >
                      > >
                      >







                      --
                      David A. Chappell
                      Chappell Consulting Corp.
                      Service Orientation and Architecture

                      author, "Enterprise Service Bus" (O'Reilly)  | "Modern SOA Infrastructure" (Prentice-Hall) |
                      "SOA Design Patterns" (Prentice-Hall) | “Java Web Services” (O'Reilly) |
                      "The Java Message Service" (O'Reilly) | "Professional ebXML Foundations", (Wrox Press)


                      617-510-6566 (mobile)
                      http://www.linkedin.com/in/davidchappell
                      http://twitter.com/davechappell


                    • Michael Poulin
                      David, I remember from the time of my living in Boston your first articles about ESB in Sys-Con and follow your work since then. I liked the idea very much and
                      Message 10 of 18 , Oct 5, 2012
                      • 0 Attachment
                        David,

                        I remember from the time of my living in Boston your first articles about ESB in Sys-Con and follow your work since then. I liked the idea very much and respected this nice and simple implementation of the ESB Pattern. However, following history of BSB advertisement and its improper application screwed this Pattern.

                        I do not have an intent to start a debate on ESB but if an organisation has an Application Server (like WebLogic) and MQ Series/WebSphere MQ or Sonic MQ why they need an ESB as well? An implementation of ESB Pattern is well covered by aforementioned systems, IMO, and I do not call for a custom implementation of an ESB system.

                        To me, ESB Pattern and ESB system are about message routing and abstraction of physical network topology. I am absolutely against a use of ESB as a decoupling intermediary between consumers and services because this contradicts the basic concept of service orientation and OASIS SOA RAF confirms this.

                        It is another matter when an ESB system is used for application integration but this has very little in common with service orientation. There are more 'cons' regarding the use of ESB from business transaction perspective but these are not about the technical system but rather about people and how they use the system. At the same time, just an existence of a system that allows so wrong usage reciprocates this wrong usage.

                        I believe that you know better than me that SOA is about how we use existing things and not about new technology.  A couple years ago, I had an intense discussion with Gartener's Yefim Natis and finally he agreed that SOA and integration are quite different things.

                        - Michael





                        From: David Chappell <dave.chappell.1@...>
                        To: service-orientated-architecture@yahoogroups.com
                        Sent: Thursday, October 4, 2012 8:57 AM
                        Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

                         
                        Michael,
                        I disagree with your view.  I have worked for 2 ESB vendors over the years and I can assure you that they aren't out to screw you; they provide software that helps you with your integration, whether it be based on SOA principles or not.  And since I no longer work for an ESB vendor, I also don't have to sugar-coat my opinions to avoid offending anyone. 

                        Anyone who tries to implement their own ESB is a fool, is wasting their CFO's time and money, and should be fired. Why would you waste time building something that a host of vendors have put the effort into building for you?  You don't build the rest of your development tools do you?

                        During my tenure as an ESB vendor, and also in my successful independent consulting practice, I have come across many of these such endeavors based on ill-informed people who think they would do better to build something themselves.  The result has been a disaster every time.  Perhaps its why this gent is in a last minute hurry to find one; because some moron thought it better to build one and failed - another common occurance.

                        That being said - I have also seen integration and SOA projects gone terribly wrong, which are based on ESB.  In either case the problem is always due to the organization's inability to get their act together and decide how to build their interfaces, and how to structure their organization in a way that fosters cross-departmental collaboration.  Those are the biggest challenges when embarking on an effort that attempts to follow SOA principles.  Imagine also being hampered by trying to build something as sophisticated as an ESB at the same time.

                        Regarding EAI tools: there no longer is any distinction.  The lines between ESB and EAI products have been blurred as ESB tools have added process modeling, adapter toolkits, and visual data mapping tools, and EAI vendors have "modernized" their EAI tools to support things like SOAP and ReST.
                        Cheers,
                        Dave

                        On Wed, Oct 3, 2012 at 7:46 PM, Michael Poulin <m3poulin@...> wrote:
                         
                        Ashraf,

                        OASIS deliberately stay s away from any particular technology because it distinguished between Architecture and Implementation of an Architecture. Implementation may use any available technologies and it should not impact the architecture.

                        Reference Architecture may be implemented in two ways -  as a framework applicable 'as is' and a s a set of definitions of architectural elements and relationships between them. OASIS has chosen the latter one.

                        No one objects that "Technology is a must to implement SOA", though if one implements service-oriented solution via manual operations, then technology is not needed. This, however, is the future understanding of SOA implementation.

                        That is, I disagree with "Without it you cannot have SOA even if you called it SO": SOA is about ARCHITECTURE and a technology is about one of its possible implementations.

                        As of ESB and SOA best practice, I also believe that this is just a vendor's buzz. A company can implement the same ESB functionality using existing messaging systems and application servers. This was and still is a major problem for CFOs in many companies - nobody can explain why they need to spend money on ESB is they have all technical capabilities in the company already. Moreover, many modern EAI systems can do the ESB's job. This is proved by the fact that IBM and ORACLE have more than 3 product offerings each that can replace ESB.

                        ESB is not a SOA implementation Best Practice but a convenient system if your company does not anything in the integration area.

                        - Michael

                        Sent: Wednesday, October 3, 2012 2:41 AM

                        Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

                         
                        Sorry I don't have the time to look at your web site or your e-course!

                        If you speak about OASIS RM and OASIS RA which stated the following:

                        "A reference architecture models the abstract architectural elements in the domain of interest independent  of the technologies, protocols, and products that are used to implement a specific solution for the domain. It differs from a reference model in that a reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain; a reference  architecture elaborates further on the model to show a more complete picture that includes showing what  is involved in realizing the modeled entities, while staying independent of any particular solution but  instead applies to a class of solutions."

                        It does not address any technologies, protocol, or products.
                        Please read the purpose of those documents.

                        the RAF also stated:

                        "The Reference Architecture has three main views: the Business via Service view which lays the
                        foundation for conducting business in the context of Service Oriented Architecture; the Realizing
                        Services view which addresses the requirements for constructing a Service Oriented Architecture; and and the Owning Service Oriented Architecture view which focuses on the governance and management of SOA systems."

                        If we understand the difference views presented in this document I don't think that you would have asked your questions.

                        Technology is a must to implement SOA.
                        Without it you cannot have SOA even if you called it SO.
                        It is consider SOA best practice to use ESB gateway to improve the performance of SOA implementation.
                         
                        All the best

                        Ashraf Galal




                        On 10/2/2012 4:01 AM, Michael Poulin wrote:
                         
                        To Ashraf,

                        I provide an e-course on Bad Practice for the use of ESB on my Web Site (www.mpoulin.com/?page_id=13 ; you will need to scroll the list of courses to find this one). I  explain the NON-service-oriented practice for an ESB systems that mistakenly called SOA and "virtualization, security, visibility" are among the most outstanding examples of it.

                        I make such conclusions in line with OASIS SOA RM standard and OASIS SOA Reference Architecture Foundation. BTW, you can read this last specification in the public review available till mid-October on OASIS' Site.

                        I concern about technocratic "Aspect Oriented capabilities". All service capabilities offered to the consumer must be described in the Service Description and Service Contracts. For example, if a service digitally signs its messages (which is implemented via injections), you have to describe in the Service Descriptionall conditions and policies in when this feature is applicable and when not.  In SO ecosystem, public service behaviour may not depend on your immediate wish - to insert signing or not.

                        Also, please, explain what in the world  is an 'exposition' of service? Who own ESB - service? Then I can guess what this mean. If it is not a service, an 'exposition' of service does not make sense in context of ESB because it is the service provider (or steward, or owner) decide what is an exposition of the service with or without ESB. You are pushing technology into SO architecture, which is incorrect, IMO.

                        What is "Standardized exposure" Requestors and where connectors came from?

                        What does mean: " it should be done according to the service integration maturity model"? If a service maturity model has, for example, 5 layers (5 is the top) and an organisation is at the layer 3, does your comment mean that nobody in the organisations may design and build services for the layer 4?

                        I think that the service maturity model is the derivative from the real state of service architecture and development, not the other way around: maturity model indicates but does not lead.

                        Thanks,
                        - Michael



                        From: Ashraf Galal <ashrafwg@...>
                        To: service-orientated-architecture@yahoogroups.com
                        Sent: Monday, October 1, 2012 8:19 PM
                        Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

                         
                        For sure you can use both of them together in one solution context.

                        In this case your are thinking about reusability as I guess.

                        you can have  an ESB gateway in your solution to perform Aspect Oriented capabilities of virtualization, security, visibility, and traffic management required for mature exposition of services .

                        Second you can use the ESB with the business process to "Standardized exposure" Requestors, in this case,  no longer require a connector. 

                        I think it should be done according to the service integration maturity model.
                        what was described here is more about advanced SOA, and you might not need it in the beginning of any SOA.
                        Please consider your requirements first, then you will be guided accordingly.

                        All the best

                        Ashraf Galal

                        On 10/1/2012 10:05 AM, dyar wrote:
                         
                        Dear Ashraf Galal
                        thank so much for your replay , but in my case i want to use both, BPEL for orchestrate web service in the business process layer and ESB
                        for integration in the integration layer of SOA architecture framework.
                        So is that possible to use both ESB and BPEL in same project? and which tool is the most proper for my case?
                        thanks again
                        regards.

                        --- In service-orientated-architecture@yahoogroups.com, Ashraf Galal <ashrafwg@...> wrote:
                        >
                        > When designing an SOA solution, it's not always clear whether you should
                        > use a Web services BPEL process or an ESB mediation flow.
                        >
                        > There are use cases where either Process Server or an ESB could be used.
                        >
                        > For example, suppose three existing services need to be called, using a
                        > two-phase commit./(composite service) /
                        >
                        > You could use a mediation flow in an ESB to call the services.
                        >
                        > Mediation flows are committed as a transaction, or rolled back.
                        >
                        > You could use a WS-BPEL micro-flow to call the three services, also
                        > providing transaction as well.
                        >
                        > In this case, you could use both products as the solution.
                        >
                        > So you need to decide which run-time you use
                        >
                        > Because there is some functional overlap between Process Server and an
                        > ESB. Both can work with adapters.
                        >
                        > Both can transform data.
                        >
                        > Both can support the composite service pattern.
                        >
                        > When faced with deciding the best software to use for a given business
                        > problem, you need to decide which to use.
                        >
                        > The first order of business is to look through the requirements, and
                        > decide if one of the choices is a better fit.
                        >
                        > For example, if a stateful process is required, you can immediately rule
                        > out the ESB.
                        >
                        > If on the other hand the requirement is to process a message
                        > transformation in under 0.2 seconds, clearly the ESB would be the choice.
                        >
                        > Although, not all projects in the real world are so cut and dried. Often
                        > times, you need to examine several criteria in order to determine the
                        > best option.
                        >
                        > Please look for both ESB and BPEL strength
                        > ESB Strength
                        >
                        > One of the main strengths of an ESB is processing messages.
                        >
                        > Message in, message out, perhaps with protocol or format mediation applied.
                        >
                        > *_When the requirements clearly call for message processing_*, an ESB is
                        > going to have several advantages, including the ability to handle
                        > greater complexity in the transformations.
                        >
                        > *_If the requirements call for one of the basic ESB functions_*, such as
                        > message routing, transformation or protocol mediation, an ESB would be
                        > the clear choice.
                        >
                        > Another strength of an ESB is performance.
                        >
                        > An ESB is designed to be able to handle large volumes of messages. If,
                        > for example, the requirements say that there will be 300,000 messages
                        > per day, the ESB would clearly be the better choice.
                        >
                        > If the requirements are data-centric, an ESB is the clear choice.
                        >
                        > BPEL Strength
                        >
                        > The main strength of a BPEL engine is the ability to orchestrate a
                        > business process.
                        >
                        > *_If the requirements call for a process with complex logic_*, BPEL will
                        > be a better choice.
                        >
                        > WS-BPEL has container activities, such as while loops and scopes that
                        > ESBs don’t support.
                        >
                        > The logic in an ESB is normally straightforward, while WS-BPEL can
                        > handle more complex cases.
                        >
                        > Another strength of a WS-BPEL engine, is the ability to have a
                        > long-running business process where state is maintained.
                        >
                        > *You should not use an ESB when state is required*, since it would take
                        > a lot of custom code to maintain the state.
                        >
                        > *_If the requirements call for stateful processing_*, you can rule out
                        > the ESB as your choice.
                        >
                        > If the requirements are process-centric, WS-BPEL is the clear choice.
                        >
                        > This is not all the story but just a guidelines, look for more details
                        > in IBM sites, HP, SAP or Oracle sites.
                        >
                        > All the best
                        >
                        > Ashraf Galal
                        >
                        >
                        >
                        > > > > From: dyar <akodyar@>
                        > > > >To: service-orientated-architecture@yahoogroups.com
                        > > <mailto:service-orientated-architecture%40yahoogroups.com>
                        > > > >Sent: Saturday, September 29, 2012 3:15 AM
                        > > > >Subject: [service-orientated-architecture] SOA, ESB, and BPEL
                        > > > >
                        > > > >
                        > > > >Â
                        > > > >Hello everyone,
                        > > > >I am doing research on banking system integration I will use
                        > > SOA with ESB at the same time I want to use BPEL for business
                        > > process, How can I use both ESB and BPEL in one project and which
                        > > tool proper with this? I will be thankful for your help.
                        > > > >
                        > > > >Note: English is my second language, sorry for any inaccuracy
                        > > sentences
                        > > > >
                        > > > >AKO JAAFAR
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > > >
                        > > >
                        > >
                        > >
                        > >
                        > >
                        >










                        --
                        David A. Chappell
                        Chappell Consulting Corp.
                        Service Orientation and Architecture

                        author, "Enterprise Service Bus" (O'Reilly)  | "Modern SOA Infrastructure" (Prentice-Hall) |
                        "SOA Design Patterns" (Prentice-Hall) | “Java Web Services” (O'Reilly) |
                        "The Java Message Service" (O'Reilly) | "Professional ebXML Foundations", (Wrox Press)


                        617-510-6566 (mobile)
                        http://www.linkedin.com/in/davidchappell
                        http://twitter.com/davechappell


                      • Steve Jones
                        Dave, I completely agree with you on two fronts here, that ESB vendor product teams aren t out to screw you and that you d be stupid to build your own. However
                        Message 11 of 18 , Oct 5, 2012
                        • 0 Attachment
                          Dave,

                          I completely agree with you on two fronts here, that ESB vendor product teams aren't out to screw you and that you'd be stupid to build your own.  However I'd still say 'caveat emptor' as Software SALES people are often focused more on the sale than the right technology.  I've certainly seen cases where despite what the product team would say the sales team sold something that wasn't appropriate.

                          Certainly don't build, but don't assume everyone selling is engaged with what the ESB vendor's product team would want.

                          On the latter point that there is no difference I'd take a slight disagreement on that one.  Its more that the amount of evolution in the last 5+ years has been incredible minimal so SOA vendors have pretty much stagnated and the 'lipstick on the pig' approach of the EAI tools has been better industrialised.  I'd still argue that a bus constructed from the ground up as a bus rather than an old school hub and spoke EAI tool is better no matter how many ESB or 'SOA' labels the vendors marketing department has put on it.

                          Steve


                          On 4 October 2012 08:57, David Chappell <dave.chappell.1@...> wrote:
                           

                          Michael,
                          I disagree with your view.  I have worked for 2 ESB vendors over the years and I can assure you that they aren't out to screw you; they provide software that helps you with your integration, whether it be based on SOA principles or not.  And since I no longer work for an ESB vendor, I also don't have to sugar-coat my opinions to avoid offending anyone. 

                          Anyone who tries to implement their own ESB is a fool, is wasting their CFO's time and money, and should be fired. Why would you waste time building something that a host of vendors have put the effort into building for you?  You don't build the rest of your development tools do you?

                          During my tenure as an ESB vendor, and also in my successful independent consulting practice, I have come across many of these such endeavors based on ill-informed people who think they would do better to build something themselves.  The result has been a disaster every time.  Perhaps its why this gent is in a last minute hurry to find one; because some moron thought it better to build one and failed - another common occurance.

                          That being said - I have also seen integration and SOA projects gone terribly wrong, which are based on ESB.  In either case the problem is always due to the organization's inability to get their act together and decide how to build their interfaces, and how to structure their organization in a way that fosters cross-departmental collaboration.  Those are the biggest challenges when embarking on an effort that attempts to follow SOA principles.  Imagine also being hampered by trying to build something as sophisticated as an ESB at the same time.

                          Regarding EAI tools: there no longer is any distinction.  The lines between ESB and EAI products have been blurred as ESB tools have added process modeling, adapter toolkits, and visual data mapping tools, and EAI vendors have "modernized" their EAI tools to support things like SOAP and ReST.
                          Cheers,
                          Dave



                          On Wed, Oct 3, 2012 at 7:46 PM, Michael Poulin <m3poulin@...> wrote:
                           

                          Ashraf,

                          OASIS deliberately stay s away from any particular technology because it distinguished between Architecture and Implementation of an Architecture. Implementation may use any available technologies and it should not impact the architecture.

                          Reference Architecture may be implemented in two ways -  as a framework applicable 'as is' and a s a set of definitions of architectural elements and relationships between them. OASIS has chosen the latter one.

                          No one objects that "Technology is a must to implement SOA", though if one implements service-oriented solution via manual operations, then technology is not needed. This, however, is the future understanding of SOA implementation.

                          That is, I disagree with "Without it you cannot have SOA even if you called it SO": SOA is about ARCHITECTURE and a technology is about one of its possible implementations.

                          As of ESB and SOA best practice, I also believe that this is just a vendor's buzz. A company can implement the same ESB functionality using existing messaging systems and application servers. This was and still is a major problem for CFOs in many companies - nobody can explain why they need to spend money on ESB is they have all technical capabilities in the company already. Moreover, many modern EAI systems can do the ESB's job. This is proved by the fact that IBM and ORACLE have more than 3 product offerings each that can replace ESB.

                          ESB is not a SOA implementation Best Practice but a convenient system if your company does not anything in the integration area.

                          - Michael

                          Sent: Wednesday, October 3, 2012 2:41 AM

                          Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

                           
                          Sorry I don't have the time to look at your web site or your e-course!

                          If you speak about OASIS RM and OASIS RA which stated the following:

                          "A reference architecture models the abstract architectural elements in the domain of interest independent  of the technologies, protocols, and products that are used to implement a specific solution for the domain. It differs from a reference model in that a reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain; a reference  architecture elaborates further on the model to show a more complete picture that includes showing what  is involved in realizing the modeled entities, while staying independent of any particular solution but  instead applies to a class of solutions."

                          It does not address any technologies, protocol, or products.
                          Please read the purpose of those documents.

                          the RAF also stated:

                          "The Reference Architecture has three main views: the Business via Service view which lays the
                          foundation for conducting business in the context of Service Oriented Architecture; the Realizing
                          Services view which addresses the requirements for constructing a Service Oriented Architecture; and and the Owning Service Oriented Architecture view which focuses on the governance and management of SOA systems."

                          If we understand the difference views presented in this document I don't think that you would have asked your questions.

                          Technology is a must to implement SOA.
                          Without it you cannot have SOA even if you called it SO.
                          It is consider SOA best practice to use ESB gateway to improve the performance of SOA implementation.
                           
                          All the best

                          Ashraf Galal




                          On 10/2/2012 4:01 AM, Michael Poulin wrote:
                           
                          To Ashraf,

                          I provide an e-course on Bad Practice for the use of ESB on my Web Site (www.mpoulin.com/?page_id=13 ; you will need to scroll the list of courses to find this one). I  explain the NON-service-oriented practice for an ESB systems that mistakenly called SOA and "virtualization, security, visibility" are among the most outstanding examples of it.

                          I make such conclusions in line with OASIS SOA RM standard and OASIS SOA Reference Architecture Foundation. BTW, you can read this last specification in the public review available till mid-October on OASIS' Site.

                          I concern about technocratic "Aspect Oriented capabilities". All service capabilities offered to the consumer must be described in the Service Description and Service Contracts. For example, if a service digitally signs its messages (which is implemented via injections), you have to describe in the Service Descriptionall conditions and policies in when this feature is applicable and when not.  In SO ecosystem, public service behaviour may not depend on your immediate wish - to insert signing or not.

                          Also, please, explain what in the world  is an 'exposition' of service? Who own ESB - service? Then I can guess what this mean. If it is not a service, an 'exposition' of service does not make sense in context of ESB because it is the service provider (or steward, or owner) decide what is an exposition of the service with or without ESB. You are pushing technology into SO architecture, which is incorrect, IMO.

                          What is "Standardized exposure" Requestors and where connectors came from?

                          What does mean: " it should be done according to the service integration maturity model"? If a service maturity model has, for example, 5 layers (5 is the top) and an organisation is at the layer 3, does your comment mean that nobody in the organisations may design and build services for the layer 4?

                          I think that the service maturity model is the derivative from the real state of service architecture and development, not the other way around: maturity model indicates but does not lead.

                          Thanks,
                          - Michael



                          From: Ashraf Galal <ashrafwg@...>
                          To: service-orientated-architecture@yahoogroups.com
                          Sent: Monday, October 1, 2012 8:19 PM
                          Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

                           
                          For sure you can use both of them together in one solution context.

                          In this case your are thinking about reusability as I guess.

                          you can have  an ESB gateway in your solution to perform Aspect Oriented capabilities of virtualization, security, visibility, and traffic management required for mature exposition of services .

                          Second you can use the ESB with the business process to "Standardized exposure" Requestors, in this case,  no longer require a connector. 

                          I think it should be done according to the service integration maturity model.
                          what was described here is more about advanced SOA, and you might not need it in the beginning of any SOA.
                          Please consider your requirements first, then you will be guided accordingly.

                          All the best

                          Ashraf Galal

                          On 10/1/2012 10:05 AM, dyar wrote:
                           
                          Dear Ashraf Galal
                          thank so much for your replay , but in my case i want to use both, BPEL for orchestrate web service in the business process layer and ESB
                          for integration in the integration layer of SOA architecture framework.
                          So is that possible to use both ESB and BPEL in same project? and which tool is the most proper for my case?
                          thanks again
                          regards.

                          --- In service-orientated-architecture@yahoogroups.com, Ashraf Galal <ashrafwg@...> wrote:
                          >
                          > When designing an SOA solution, it's not always clear whether you should
                          > use a Web services BPEL process or an ESB mediation flow.
                          >
                          > There are use cases where either Process Server or an ESB could be used.
                          >
                          > For example, suppose three existing services need to be called, using a
                          > two-phase commit./(composite service) /
                          >
                          > You could use a mediation flow in an ESB to call the services.
                          >
                          > Mediation flows are committed as a transaction, or rolled back.
                          >
                          > You could use a WS-BPEL micro-flow to call the three services, also
                          > providing transaction as well.
                          >
                          > In this case, you could use both products as the solution.
                          >
                          > So you need to decide which run-time you use
                          >
                          > Because there is some functional overlap between Process Server and an
                          > ESB. Both can work with adapters.
                          >
                          > Both can transform data.
                          >
                          > Both can support the composite service pattern.
                          >
                          > When faced with deciding the best software to use for a given business
                          > problem, you need to decide which to use.
                          >
                          > The first order of business is to look through the requirements, and
                          > decide if one of the choices is a better fit.
                          >
                          > For example, if a stateful process is required, you can immediately rule
                          > out the ESB.
                          >
                          > If on the other hand the requirement is to process a message
                          > transformation in under 0.2 seconds, clearly the ESB would be the choice.
                          >
                          > Although, not all projects in the real world are so cut and dried. Often
                          > times, you need to examine several criteria in order to determine the
                          > best option.
                          >
                          > Please look for both ESB and BPEL strength
                          > ESB Strength
                          >
                          > One of the main strengths of an ESB is processing messages.
                          >
                          > Message in, message out, perhaps with protocol or format mediation applied.
                          >
                          > *_When the requirements clearly call for message processing_*, an ESB is
                          > going to have several advantages, including the ability to handle
                          > greater complexity in the transformations.
                          >
                          > *_If the requirements call for one of the basic ESB functions_*, such as
                          > message routing, transformation or protocol mediation, an ESB would be
                          > the clear choice.
                          >
                          > Another strength of an ESB is performance.
                          >
                          > An ESB is designed to be able to handle large volumes of messages. If,
                          > for example, the requirements say that there will be 300,000 messages
                          > per day, the ESB would clearly be the better choice.
                          >
                          > If the requirements are data-centric, an ESB is the clear choice.
                          >
                          > BPEL Strength
                          >
                          > The main strength of a BPEL engine is the ability to orchestrate a
                          > business process.
                          >
                          > *_If the requirements call for a process with complex logic_*, BPEL will
                          > be a better choice.
                          >
                          > WS-BPEL has container activities, such as while loops and scopes that
                          > ESBs don’t support.
                          >
                          > The logic in an ESB is normally straightforward, while WS-BPEL can
                          > handle more complex cases.
                          >
                          > Another strength of a WS-BPEL engine, is the ability to have a
                          > long-running business process where state is maintained.
                          >
                          > *You should not use an ESB when state is required*, since it would take
                          > a lot of custom code to maintain the state.
                          >
                          > *_If the requirements call for stateful processing_*, you can rule out
                          > the ESB as your choice.
                          >
                          > If the requirements are process-centric, WS-BPEL is the clear choice.
                          >
                          > This is not all the story but just a guidelines, look for more details
                          > in IBM sites, HP, SAP or Oracle sites.
                          >
                          > All the best
                          >
                          > Ashraf Galal
                          >
                          >
                          >
                          > > > > From: dyar <akodyar@>
                          > > > >To: service-orientated-architecture@yahoogroups.com
                          > > <mailto:service-orientated-architecture%40yahoogroups.com>
                          > > > >Sent: Saturday, September 29, 2012 3:15 AM
                          > > > >Subject: [service-orientated-architecture] SOA, ESB, and BPEL
                          > > > >
                          > > > >
                          > > > >Â
                          > > > >Hello everyone,
                          > > > >I am doing research on banking system integration I will use
                          > > SOA with ESB at the same time I want to use BPEL for business
                          > > process, How can I use both ESB and BPEL in one project and which
                          > > tool proper with this? I will be thankful for your help.
                          > > > >
                          > > > >Note: English is my second language, sorry for any inaccuracy
                          > > sentences
                          > > > >
                          > > > >AKO JAAFAR
                          > > > >
                          > > > >
                          > > > >
                          > > > >
                          > > > >
                          > > >
                          > >
                          > >
                          > >
                          > >
                          >










                          --
                          David A. Chappell
                          Chappell Consulting Corp.
                          Service Orientation and Architecture

                          author, "Enterprise Service Bus" (O'Reilly)  | "Modern SOA Infrastructure" (Prentice-Hall) |
                          "SOA Design Patterns" (Prentice-Hall) | “Java Web Services” (O'Reilly) |
                          "The Java Message Service" (O'Reilly) | "Professional ebXML Foundations", (Wrox Press)


                          617-510-6566 (mobile)
                          http://www.linkedin.com/in/davidchappell
                          http://twitter.com/davechappell


                        • Dave Chappell
                          +1 Dave Sent from my iPhone ... +1 Dave Sent from my iPhone On Oct 5, 2012, at 12:07 PM, Steve Jones wrote: Dave, I completely agree
                          Message 12 of 18 , Oct 5, 2012
                          • 0 Attachment
                            +1
                            Dave

                            Sent from my iPhone

                            On Oct 5, 2012, at 12:07 PM, Steve Jones <jones.steveg@...> wrote:

                             

                            Dave,


                            I completely agree with you on two fronts here, that ESB vendor product teams aren't out to screw you and that you'd be stupid to build your own.  However I'd still say 'caveat emptor' as Software SALES people are often focused more on the sale than the right technology.  I've certainly seen cases where despite what the product team would say the sales team sold something that wasn't appropriate.

                            Certainly don't build, but don't assume everyone selling is engaged with what the ESB vendor's product team would want.

                            On the latter point that there is no difference I'd take a slight disagreement on that one.  Its more that the amount of evolution in the last 5+ years has been incredible minimal so SOA vendors have pretty much stagnated and the 'lipstick on the pig' approach of the EAI tools has been better industrialised.  I'd still argue that a bus constructed from the ground up as a bus rather than an old school hub and spoke EAI tool is better no matter how many ESB or 'SOA' labels the vendors marketing department has put on it.

                            Steve


                            On 4 October 2012 08:57, David Chappell <dave.chappell.1@...> wrote:
                             

                            Michael,
                            I disagree with your view.  I have worked for 2 ESB vendors over the years and I can assure you that they aren't out to screw you; they provide software that helps you with your integration, whether it be based on SOA principles or not.  And since I no longer work for an ESB vendor, I also don't have to sugar-coat my opinions to avoid offending anyone. 

                            Anyone who tries to implement their own ESB is a fool, is wasting their CFO's time and money, and should be fired. Why would you waste time building something that a host of vendors have put the effort into building for you?  You don't build the rest of your development tools do you?

                            During my tenure as an ESB vendor, and also in my successful independent consulting practice, I have come across many of these such endeavors based on ill-informed people who think they would do better to build something themselves.  The result has been a disaster every time.  Perhaps its why this gent is in a last minute hurry to find one; because some moron thought it better to build one and failed - another common occurance.

                            That being said - I have also seen integration and SOA projects gone terribly wrong, which are based on ESB.  In either case the problem is always due to the organization's inability to get their act together and decide how to build their interfaces, and how to structure their organization in a way that fosters cross-departmental collaboration.  Those are the biggest challenges when embarking on an effort that attempts to follow SOA principles.  Imagine also being hampered by trying to build something as sophisticated as an ESB at the same time.

                            Regarding EAI tools: there no longer is any distinction.  The lines between ESB and EAI products have been blurred as ESB tools have added process modeling, adapter toolkits, and visual data mapping tools, and EAI vendors have "modernized" their EAI tools to support things like SOAP and ReST.
                            Cheers,
                            Dave



                            On Wed, Oct 3, 2012 at 7:46 PM, Michael Poulin <m3poulin@...> wrote:
                             

                            Ashraf,

                            OASIS deliberately stay s away from any particular technology because it distinguished between Architecture and Implementation of an Architecture. Implementation may use any available technologies and it should not impact the architecture.

                            Reference Architecture may be implemented in two ways -  as a framework applicable 'as is' and a s a set of definitions of architectural elements and relationships between them. OASIS has chosen the latter one.

                            No one objects that "Technology is a must to implement SOA", though if one implements service-oriented solution via manual operations, then technology is not needed. This, however, is the future understanding of SOA implementation.

                            That is, I disagree with "Without it you cannot have SOA even if you called it SO": SOA is about ARCHITECTURE and a technology is about one of its possible implementations.

                            As of ESB and SOA best practice, I also believe that this is just a vendor's buzz. A company can implement the same ESB functionality using existing messaging systems and application servers. This was and still is a major problem for CFOs in many companies - nobody can explain why they need to spend money on ESB is they have all technical capabilities in the company already. Moreover, many modern EAI systems can do the ESB's job. This is proved by the fact that IBM and ORACLE have more than 3 product offerings each that can replace ESB.

                            ESB is not a SOA implementation Best Practice but a convenient system if your company does not anything in the integration area.

                            - Michael

                            Sent: Wednesday, October 3, 2012 2:41 AM

                            Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

                             
                            Sorry I don't have the time to look at your web site or your e-course!

                            If you speak about OASIS RM and OASIS RA which stated the following:

                            "A reference architecture models the abstract architectural elements in the domain of interest independent  of the technologies, protocols, and products that are used to implement a specific solution for the domain. It differs from a reference model in that a reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain; a reference  architecture elaborates further on the model to show a more complete picture that includes showing what  is involved in realizing the modeled entities, while staying independent of any particular solution but  instead applies to a class of solutions."

                            It does not address any technologies, protocol, or products.
                            Please read the purpose of those documents.

                            the RAF also stated:

                            "The Reference Architecture has three main views: the Business via Service view which lays the
                            foundation for conducting business in the context of Service Oriented Architecture; the Realizing
                            Services view which addresses the requirements for constructing a Service Oriented Architecture; and and the Owning Service Oriented Architecture view which focuses on the governance and management of SOA systems."

                            If we understand the difference views presented in this document I don't think that you would have asked your questions.

                            Technology is a must to implement SOA.
                            Without it you cannot have SOA even if you called it SO.
                            It is consider SOA best practice to use ESB gateway to improve the performance of SOA implementation.
                             
                            All the best

                            Ashraf Galal




                            On 10/2/2012 4:01 AM, Michael Poulin wrote:
                             
                            To Ashraf,

                            I provide an e-course on Bad Practice for the use of ESB on my Web Site (www.mpoulin.com/?page_id=13 ; you will need to scroll the list of courses to find this one). I  explain the NON-service-oriented practice for an ESB systems that mistakenly called SOA and "virtualization, security, visibility" are among the most outstanding examples of it.

                            I make such conclusions in line with OASIS SOA RM standard and OASIS SOA Reference Architecture Foundation. BTW, you can read this last specification in the public review available till mid-October on OASIS' Site.

                            I concern about technocratic "Aspect Oriented capabilities". All service capabilities offered to the consumer must be described in the Service Description and Service Contracts. For example, if a service digitally signs its messages (which is implemented via injections), you have to describe in the Service Descriptionall conditions and policies in when this feature is applicable and when not.  In SO ecosystem, public service behaviour may not depend on your immediate wish - to insert signing or not.

                            Also, please, explain what in the world  is an 'exposition' of service? Who own ESB - service? Then I can guess what this mean. If it is not a service, an 'exposition' of service does not make sense in context of ESB because it is the service provider (or steward, or owner) decide what is an exposition of the service with or without ESB. You are pushing technology into SO architecture, which is incorrect, IMO.

                            What is "Standardized exposure" Requestors and where connectors came from?

                            What does mean: " it should be done according to the service integration maturity model"? If a service maturity model has, for example, 5 layers (5 is the top) and an organisation is at the layer 3, does your comment mean that nobody in the organisations may design and build services for the layer 4?

                            I think that the service maturity model is the derivative from the real state of service architecture and development, not the other way around: maturity model indicates but does not lead.

                            Thanks,
                            - Michael



                            From: Ashraf Galal <ashrafwg@...>
                            To: service-orientated-architecture@yahoogroups.com
                            Sent: Monday, October 1, 2012 8:19 PM
                            Subject: Re: [service-orientated-architecture] Re: SOA, ESB, and BPEL

                             
                            For sure you can use both of them together in one solution context.

                            In this case your are thinking about reusability as I guess.

                            you can have  an ESB gateway in your solution to perform Aspect Oriented capabilities of virtualization, security, visibility, and traffic management required for mature exposition of services .

                            Second you can use the ESB with the business process to "Standardized exposure" Requestors, in this case,  no longer require a connector. 

                            I think it should be done according to the service integration maturity model.
                            what was described here is more about advanced SOA, and you might not need it in the beginning of any SOA.
                            Please consider your requirements first, then you will be guided accordingly.

                            All the best

                            Ashraf Galal

                            On 10/1/2012 10:05 AM, dyar wrote:
                             
                            Dear Ashraf Galal
                            thank so much for your replay , but in my case i want to use both, BPEL for orchestrate web service in the business process layer and ESB
                            for integration in the integration layer of SOA architecture framework.
                            So is that possible to use both ESB and BPEL in same project? and which tool is the most proper for my case?
                            thanks again
                            regards.

                            --- In service-orientated-architecture@yahoogroups.com, Ashraf Galal <ashrafwg@...> wrote:
                            >
                            > When designing an SOA solution, it's not always clear whether you should
                            > use a Web services BPEL process or an ESB mediation flow.
                            >
                            > There are use cases where either Process Server or an ESB could be used.
                            >
                            > For example, suppose three existing services need to be called, using a
                            > two-phase commit./(composite service) /
                            >
                            > You could use a mediation flow in an ESB to call the services.
                            >
                            > Mediation flows are committed as a transaction, or rolled back.
                            >
                            > You could use a WS-BPEL micro-flow to call the three services, also
                            > providing transaction as well.
                            >
                            > In this case, you could use both products as the solution.
                            >
                            > So you need to decide which run-time you use
                            >
                            > Because there is some functional overlap between Process Server and an
                            > ESB. Both can work with adapters.
                            >
                            > Both can transform data.
                            >
                            > Both can support the composite service pattern.
                            >
                            > When faced with deciding the best software to use for a given business
                            > problem, you need to decide which to use.
                            >
                            > The first order of business is to look through the requirements, and
                            > decide if one of the choices is a better fit.
                            >
                            > For example, if a stateful process is required, you can immediately rule
                            > out the ESB.
                            >
                            > If on the other hand the requirement is to process a message
                            > transformation in under 0.2 seconds, clearly the ESB would be the choice.
                            >
                            > Although, not all projects in the real world are so cut and dried. Often
                            > times, you need to examine several criteria in order to determine the
                            > best option.
                            >
                            > Please look for both ESB and BPEL strength
                            > ESB Strength
                            >
                            > One of the main strengths of an ESB is processing messages.
                            >
                            > Message in, message out, perhaps with protocol or format mediation applied.
                            >
                            > *_When the requirements clearly call for message processing_*, an ESB is
                            > going to have several advantages, including the ability to handle
                            > greater complexity in the transformations.
                            >
                            > *_If the requirements call for one of the basic ESB functions_*, such as
                            > message routing, transformation or protocol mediation, an ESB would be
                            > the clear choice.
                            >
                            > Another strength of an ESB is performance.
                            >
                            > An ESB is designed to be able to handle large volumes of messages. If,
                            > for example, the requirements say that there will be 300,000 messages
                            > per day, the ESB would clearly be the better choice.
                            >
                            > If the requirements are data-centric, an ESB is the clear choice.
                            >
                            > BPEL Strength
                            >
                            > The main strength of a BPEL engine is the ability to orchestrate a
                            > business process.
                            >
                            > *_If the requirements call for a process with complex logic_*, BPEL will
                            > be a better choice.
                            >
                            > WS-BPEL has container activities, such as while loops and scopes that
                            > ESBs don’t support.
                            >
                            > The logic in an ESB is normally straightforward, while WS-BPEL can
                            > handle more complex cases.
                            >
                            > Another strength of a WS-BPEL engine, is the ability to have a
                            > long-running business process where state is maintained.
                            >
                            > *You should not use an ESB when state is required*, since it would take
                            > a lot of custom code to maintain the state.
                            >
                            > *_If the requirements call for stateful processing_*, you can rule out
                            > the ESB as your choice.
                            >
                            > If the requirements are process-centric, WS-BPEL is the clear choice.
                            >
                            > This is not all the story but just a guidelines, look for more details
                            > in IBM sites, HP, SAP or Oracle sites.
                            >
                            > All the best
                            >
                            > Ashraf Galal
                            >
                            >
                            >
                            > > > > From: dyar <akodyar@>
                            > > > >To: service-orientated-architecture@yahoogroups.com
                            > > <mailto:service-orientated-architecture%40yahoogroups.com>
                            > > > >Sent: Saturday, September 29, 2012 3:15 AM
                            > > > >Subject: [service-orientated-architecture] SOA, ESB, and BPEL
                            > > > >
                            > > > >
                            > > > >Â
                            > > > >Hello everyone,
                            > > > >I am doing research on banking system integration I will use
                            > > SOA with ESB at the same time I want to use BPEL for business
                            > > process, How can I use both ESB and BPEL in one project and which
                            > > tool proper with this? I will be thankful for your help.
                            > > > >
                            > > > >Note: English is my second language, sorry for any inaccuracy
                            > > sentences
                            > > > >
                            > > > >AKO JAAFAR
                            > > > >
                            > > > >
                            > > > >
                            > > > >
                            > > > >
                            > > >
                            > >
                            > >
                            > >
                            > >
                            >










                            --
                            David A. Chappell
                            Chappell Consulting Corp.
                            Service Orientation and Architecture

                            author, "Enterprise Service Bus" (O'Reilly)  | "Modern SOA Infrastructure" (Prentice-Hall) |
                            "SOA Design Patterns" (Prentice-Hall) | “Java Web Services” (O'Reilly) |
                            "The Java Message Service" (O'Reilly) | "Professional ebXML Foundations", (Wrox Press)


                            617-510-6566 (mobile)
                            http://www.linkedin.com/in/davidchappell
                            http://twitter.com/davechappell


                          Your message has been successfully submitted and would be delivered to recipients shortly.