Transaction in EJB with ADF 11 - Service Architecture Leveraging Tuxedo (SALT)

When i using to query update data in database, in database changed but on jspx not change? help me. 

I'm not sure if your question is related to SALT or even Tuxedo, but in the event that it is, what comes to mind is that transactions between Tuxedo and a Java application server are loosely coupled at best. If your question is around SALT and using SALT to connect to a Java Web Service, then in that case with SALT 10gR3 there is no distributed transaction support between Tuxedo and the Java Web Service. So if the Tuxedo application and the Java application access the same data in the same database, they will see different values as they will be part of different transactions. Even with the upcoming support for WS-AtomicTransaction, distributed transactions will still be loosely coupled, i.e., each branch will appear to the resource manager as a different transaction, thus there is likely to be visibility issues.
If you are using Tuxedo and WTC with its distributed transaction support, you will still have the loosely coupled transaction issue.
In general it's best not to have multiple branches of a distributed transaction trying to access the same data.
Todd Little
Oracle Tuxedo Chief Architect


ESB Design

Hi All,
I am looking for some documentation/books that can help me design the integration solution using Oracle Fusion Middleware. Can anyone please send me some links?
I have the following question on ESB design, please help me with this.
I am integrating Siebel and Maximo applications, both expose web services,
Each web service has mutiple interfaces, my question is do I create one ESB for each interface or each web service. Any help ion this is greatly appreciated. 
ESB overview
An ESB is an architectural pattern, not a software product. Different software products can form an ESB. In some cases, companies use multiple products in different areas, leveraging specific functionality to meet their unique requirements. These different products can be federated together as the realization of the ESB pattern.
At a high level, an ESB has four major functions:•     Message routing: An incoming message is sent to a destination determined either through hard-wired logic, or dynamically-based on content. Routing is a key function to enable service virtualization. Having a level of indirection between the caller and the service allows the location of the service to be moved without the caller having to know about the change.
•     Message transformation: An incoming message is transformed from one format to another. For example, a comma-delimited message might be reformatted into SOAP so that the data can be passed to a Web service.
•     Protocol mediation: An incoming message is sent using a different protocol from the original. For example, the incoming message could use HTTP, while the outgoing message might use WebSphere MQ.
•     Event handling: An incoming message for an event is distributed to a number of endpoints, usually through a publication and subscription model.
Often these major high-level functions are combined in a given transaction. For example, an incoming message might be a Web service call using SOAP/HTTP, while the destination is a legacy system requiring a fixed-length message format using WebSphere MQ. The message must be transformed, the protocol mediated, and the message must be routed to the correct location.
Programming for an ESB usually involves a visual environment, representing the logic as a flow of connected activities called a message flow or mediation flow. These flows are transactional, using mechanisms such as two-phase commit, so that the entire flow can be rolled back in the case of a failure, or committed in the case of success. These flows are stateless; in general, a message comes in, the flow performs various operations on the message, then an outgoing message is sent.
Given the stateless transactional nature of an ESB, high performance is a given. It's not uncommon for an ESB to handle millions of messages each day in a large organization.
IBM has several software offerings in the ESB space. WebSphere ESB is built on the WebSphere Application Server Network Deployment platform. It's built to support standards such as Web services, JMS, and XML. WebSphere Message Broker (hereafter called Message Broker) is a non-J2EE product, which supports standards found in WebSphere ESB such as Web services, as well as many non-standards based protocols and data formats. WebSphere DataPower is a hardware appliance that can perform ESB functions at wire speed. Together, these three offerings can be used as the basis of an ESB.
BPEL overview
The OASIS standards organization has defined the Business Process Execution Language (BPEL) as a standards-based way of orchestrating a business process composed of services. WS-BPEL 2.0 was ratified as a standard in 2007. As an execution language, WS-BPEL defines how to represent the activities in a business process, along with flow control logic, data, message correlation, exception handling, and more.
IBM’s WebSphere Process Server (hereafter called Process Server) includes the business process choreographer, a flow engine based on WS-BPEL. The previous version was called WebSphere Business Integration Server Foundation, which also included WS-BPEL support.
Process Server has several major features including:•     Business processes: Processes can be stateful and long-running, or transactional micro-flows. Long-running processes can’t be rolled back like micro-flows, however they can have compensation handlers to undo previously performed activities. Processes can be used to implement composite services.
•     Human tasks: A key part of a business process is the ability to bring people into the process. The human task manager enables steps with people to be invoked as a service. Workflow patterns are supported through either external (participating) tasks, or inline tasks using a BPEL extension.
•     Business Rules: The integrated rules engine enables business rules to be created and evaluated, rather than hard-coding the decisions into the business process. Authorized users can update the rules using a Web browser. Administrators can activate the updates, and export them so the development environment can be kept in sync with the run-time.
•     Integrated ESB: Process Server includes the complete WebSphere ESB product. In this article, we'll only look at the BPEL engine component of Process Server.
•     SCA: Service invocations in Process Server are done using the Service Component Architecture (SCA) specification. SCA interface maps can be used to invoke services with different interfaces than the calling component. Interface maps also support advanced functionality, such as relationships. If System A uses "123" as a customer identifier, but System B uses "ABC", you can use a relationship to mediate "123" to "ABC" or vice versa, when going between the systems.
The major difference between BPEL and ESB is the speed. ESB is fast than BPEL. But you could tweak BPEL also to get higher throughput. ESB does not have the overhead that BPEL is carrying. But it is not so rich on functionality, like error handling and creating a business flow as BPEL
Have you looked at Oracle Discoverer to do your ETL, or maybe even something like Advanced Replication? Think about it, SOA is not the right hammer for every solution.... ESB and BPEL both are message based solutions, hence implicitly good at delivering (small) messages in a heterogenous applications environment, but not the best performant manner to do ETL on large data volumes. In addition, ESB and BPEL are designed for integrating enterprise applications at the middle-tier level. Why should one opt doing a DB-to-DB integration via the middle-tier? "Good old" batch-wise ETL might actually perform better with high volumes. And its a proven technology.
BTW, our choice of using ESB is based on the fact that exactly this kind of transfer of data is working excellent in InterConnect and since SOA and ESB is supposed to be the product to replace InterConnect it seemed like the way to go.
Functional considerations
The detailed requirements for a particular project are a major factor in determining which environment best suits a given project. Some of the important questions you need to answer are:
•     What transport protocols are required? Both Process Server and Message Broker support WebSphere MQ, but only Message Broker supports IP Multicast, for example. If JMS is used, it is also important to understand if the specific JMS provider is supported.
•     What standards are required? The requirements might call for WS-Security, for example, or support for a complex industry standard schema. You need to know whether these standards are supported on the server. Message Broker may have stronger support for untyped message processing, for example, while Process Server can use J2EE security, since it runs in the J2EE container. The different environments might both support a standard, but at different levels. Be sure to check all of the details before deciding.
•     What are the quality of service (QoS) requirements? Does the system have to be highly available? If Message Broker is installed in a high-availability environment, but Process Server is not, that might sway your decision. You need to look at your particular environment to understand the QoS available. You need to consider performance requirements, as well as requirements like guaranteed message delivery.
•     What routing and messaging styles are required? Various messaging styles can be used in a system, such as synchronous or asynchronous, request/response, one-way, and publication/subscription. Which ones are required? It could be one messaging style, or a combination of them. Which ones are supported in a given environment? Process Server can perform message publication through JMS topics, whereas Message Broker has more advanced functionality, such as content-based subscriptions. These requirements may help narrow your run-time selection.
Non-functional considerations
Along with the functional requirements, every system has a set of non-functional requirements that you need to consider when selecting the right run-time.
•     What is the total cost of ownership? You need to take into account the initial cost of the software, along with the associated long-term costs. For example, if a customer will have lower costs by implementing the solution on a J2EE platform, that could sway the decision towards Process Server.
•     What are the administration costs?. Every system requires an administrator. If a company already has administrators who could be used for a new project (as opposed to having to add a new resource), it can impact the total cost of ownership. For example, the MQ administrators might have an affinity for Message Broker, where as a J2EE-based run-time could have a steeper learning curve for them. You should also considered how easy the environment will be to monitor, as well as the security aspects that administrators deal with.
•     What skills are needed? Along with administrators, developers, testers, and other roles will be needed. If existing skill sets can be leveraged, you may realize time and cost savings associated. Learning new skills for a project may require training or a mentoring services engagement.
•     What does the existing environment look like? Is the middleware environment already in production? Are users familiar with the tool set? If new tools are required, what are the affinities with the current tooling environment? Are your current version levels for the prerequisite software in sync, or will you have to upgrade existing assets? Are any migrations required before you can use the system?
•     Does one of options offer unique functionality? A unique function in one of the environments could drive your decision. For example, you can perform mapping in an ESB or through an interface map in Process Server. But only interface maps in Process Server offer relationship mapping. If you require this function, only Process Server can provide it.
When both Process Server and the ESB seem to be good candidates, the non-functional requirements can often narrow the selection.
Patterns for e-business are a group of proven, reusable assets you can use to increase the speed of developing and deploying e-business applications. IBM publishes a series of Redbooks that describe the use of patterns with various technologies, such as Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB
You can examine your requirements, and determine whether patterns can be used to implement them. If an existing pattern or a combination of patterns has already been proven for a given run-time, you'll know that the run-time is capable of handling your requirements. Risk will be lower, since it has been done before, and development time can be shortened by applying the pattern. If the pattern exists on only one run-time, that can help you in making your decision.
Some typical patterns are:•     Message aggregation and disaggregation (N-to-1 and 1-to-N)
•     1-of-N responses (send multiple requests, pick one response)
•     Service virtualization (location and identity)
•     Content based routing
•     Adapter interaction
•     Message enrichment
•     Dynamic registry lookup
•     Event propagation
•     Gateway (controlled and secure interaction between internal and external domain boundaries)
For example, the referenced Redbook describes the use of DataPower using the gateway pattern. The XS40 XML Security Gateway meets the functional and non-functional requirements to support this pattern. This could help drive your decision if you were looking at which solution to use in order to implement the gateway pattern.
Gray areas
Even after using the criteria in the preceding sections to pare down to the final decision, there will still be cases in which you could choose either an ESB or Process Server as the run-time for a given project. In these cases, there are a few other things you can consider.
Design philosophy
Some companies have an overall design philosophy that guides all of their projects. For example, you may decide that all transformations are to take place in the ESB, while all business logic is to reside in the Process Server.
If a customer places an online order, the business decision to decide if they qualify for free shipping would belong in the business logic layer, running in Process Server. The routing of a message to the appropriate shipping service would be done at the ESB layer. This allows the company to alter the business logic, without having to make changes to the integration logic (and vice versa).
This overall design philosophy should weigh in on the decision. In other words, what is the strategic direction? If all other things are equal, you can use this as your criteria.
Each WS-BPEL process or mediation flow you deploy will consume CPU capacity on the server where it is deployed. The middleware it runs on has a cost, of course, along with hardware costs, support costs, administration, and so on. If it is not clear which environment to use, the cost may factor into the decision of where to deploy.
You need to take the overall long-term maintenance of the system into account when deciding which platform is the right one for a given business problem. If using a WS-BPEL correlation set would be easier than writing and maintaining code to provide a similar capability in an ESB, not only would you be able to build your solution faster, but it would be easier to maintain. Any time a built-in primitive function is available, that will be a better design alternative than creating custom code. The easier to maintain solution is highly preferred.
Another aspect of maintenance is how easy it will be to upgrade your solution in the future, as middleware products evolve. In general, major new releases have the ability to use artifacts from previous releases. WebSphere Integration Developer, the tooling for WebSphere Process Server V6, can import integration projects from WebSphere Business Integration Server Foundation V5.1 to use the previous project as a starting point. Logic in the WS-BPEL process carries forward into the new environment. However, you may need to do some manual work to update Java™ code in the process. In most cases, using built-in functions from the software products makes future upgrade paths easier.
Whenever constructing any assets for an SOA, you should ask how to drive reuse of that asset. When something is created, it can solve a business problem. But if it can be reused, you can realize tremendous savings in development time and cost.
Using the earlier example of the online order, you could use either an ESB or a WS-BPEL micro-flow process to perform the entire job. If the business logic was broken out to WS-BPEL, with the routing logic in the ESB, there is a greater chance of reusability. With both functions in a single environment, the service could be used only once, for the specific purpose it was designed for. By separating out the functions, there is a greater chance that either one of them could be reused. For example, the in-store shipping system could leverage the routing service. You should consider the potential reusability of the solution you are creating when making your decision.
Skill strength
Your I/T staff may have stronger skills in one product over the other. For the long-term support of your project, the stronger skill set might be the tie-breaker in your decision. For example, if you have three strong ESB developers, but only one for Process Server, it might make sense for you to build the project using your ESB.
Successful projects are ones where the risks have been mitigated so that there is very little chance of the project failing. If you've implemented five modules in Process Server, but you're just starting out with Message Broker, you could view using Process Server as having a lower risk, since you have more experience with it.
Likewise, you might find several references and case studies for systems similar to what you need to implement. If several other customers have done it successfully with Message Broker, you'd have some assurances that you're not stretching the product boundaries. If others have been successful on similar projects, your risk is lower.
After assessing all factors that contribute to risk in your project, you may be able to use the lowered risk as your final decision-making criteria.

Simple web services and XA

WSI-15 indicates non-transactional WS, But WSI-16 indicates WS "use short-running,
XA transactions"
A<WSI-15>Let me clear up any possible confusion. There is no inherent support for
transactions within the web service framework and in particular there is no way for
a web service client to demarcate a transaction. There are some emerging standards
(BTP,SOAP-CTX) that hope to address these issues but they really are in their infancy.
On the implementation side of the web service (with your stateless session EJB for
instance) there is however nothing to stop you using transaction. The actual business
process that you are invoking can and should have complete XA transaction support
which is what slide 16 eludes to.
"Elie Dagher" <> wrote:
WSI-15 indicates non-transactional WS, But WSI-16 indicates WS "use short-running,
XA transactions"

collaborator -  asynchronous communication

We are serving as a 3rd party hub - many partners will
communicate via us.
Therefore, our model is slightly different than a parter-to-partner model.
1. How does collaborator support asynchronous messages?
If the partner initiating the connection, closes down the conversation,
the c-space that they used is recycled.
2. In the collaborator model:
Does anyone have experience with a non-BEA client connencting
to the c-space?
Am looking at a JMS client - is there one already out there?
The sending & receiving queues for that client -
would exist on our central server.
Any problems/recommendations with developing this?
thanx - np
answers in line...
r wrote:
We are serving as a 3rd party hub - many partners will
communicate via us.
Therefore, our model is slightly different than a parter-to-partner model.
1. How does collaborator support asynchronous messages?
If the partner initiating the connection, closes down the conversation,
the c-space that they used is recycled.Messaging is inherently asynchronous. THe API allows the application to block
and wait only for the ack, therefore is only on the transport level and not
the messaging level.
2. In the collaborator model:
Does anyone have experience with a non-BEA client connencting
to the c-space?
Am looking at a JMS client - is there one already out there?No, developing a JMS client is not supported, since collaborate messages
cannot be sent with a conversation context. There is no way for an
application to create the context for the messages.
The sending & receiving queues for that client -
would exist on our central server.
Any problems/recommendations with developing this?
thanx - np

What are the differences between Oracle Service Bus 10g and WLI 10g?

To me both Oracle Service Bus 10g R3 and Weblogic Integration 10g seem to offer the same functionalities for implementing an enterprise middleware.
I would be grateful if someone could:
1. provide me with the two products' differences.
2. describe what their roadmap is?
3. what are their positioning in the Oracle product catalog? Are they both members of Oracle SOA Suite? Fussion Middleware?
Thanks a lot,
Best regards,
there is no short answer but will try to compile as much as possible
WLI and OSB are intended for completely different use cases.
WLI is intended for purpose of statefull as well as stateless workflows with emphasis on business process rather than on transport mediation where OSB adds maximum value.
As any process engine WLI supports use cases requiring human-interaction in automated flows worklist , Business calendar, B2B Connectivity (ebxml , Rosettanet )
Thank you Manoj for your answer!
Just some clarifications:
1.Could you say that WLI is equivalent (in terms of capabilities and intended purposes) of: OSB and a BPM engine together?
2. In order to understand the stateful workflows, what kind of state do you refer to? Could you give me an example of a workflow where state is required and OSB cannot handle it, making WLI the only choice?
3. Can't we keep "state" in OSB, writing to a database or publish to a queue?
Thanks again,
1. No, especially when you refer to BPM Suite (, which offers much more.
2. In principle, you define mediation in OSB - the route from point A to point B for your messages. You can't postpone your messages and wait for additional (asynchronous) input data to adjust your route for example. The simplest example you can't implement in OSB is a merge of two incoming messages. You handle the first and the second independently without possibility of handling them at the same time. The most common example of a stateful workflow is a shopping cart. You can't implement that kind of things in OSB. I don't know if you can implement that in WLI, but I guess that it is not the right technology for that kind of stuff either.
3. Of course, YOU can keep state in DB or JMS destination, but it is YOU who cares about the state, not OSB itself. 
Well OSB is an ESB while WLI is for EAI. They serve completely different purposes.
An enterprise service bus is a standards-based and event-driven messaging-engine. It serves as a single point of entry for service consumers (hiding the actual physical location of the services). It helps to achieve some of the principles of SAO like flexibility (e.g. your services are no longer tied to a specific transport) and loose-coupling. It's all configuration-based, you don't write code.
EAI focuses on integrating with a wide variety of existing applications. So it provides a framework/stack of technologies for this, an execution environment, an IDE to implement the integrations, etc. There are many adapters to integrate with ERPs for example. Like it's been said it provides a framework for creating processes/workflows with persistence (as opposed to a proxy pipeline), support for human interaction, etc. But the main focus remains application integration (unlike OBPM which is focused on standards-based business process modeling, design, execution and monitoring). So with WLI you could build standards-based services to expose your legacy systems and make them available in an SOA, publish them in OSB and use them in your OBPM or BPEL orchestrations.
That's my two cents, hope it helps. 
Thanks everyone for the replies. Now the picture is much clearer.
Just to confirm my understanding:
let's say that i have OSB (Oracle Service Bus) as ESB and 4 systems integrated with it.
All have interfaces with the ESB and communication between them happens through the OSB.
So, could i have a flow defined in OSB which:
1. receives request from system 1let's say msg1
2. the first step of the flow is to call System 2 with input=msg1 and output msg2
3. the flow takes the previous output (msg2) and calls System 3 which returns msg3
4. If all calls where executed without errors then the flow calls System 4
5. if there was any errors in the calls to System 2 or to System 3, then the flow let's say that rollbacks any changes made and returns an error message to the first calling System 1.
Is that possible to implement with the OSB?
If the stateless nature of OSB is a problem to implement, then can i store the messages and generally "state information" for each call to be able to implement the above described flow?
Thanks everyone. 
In order to achieve your use case using OSB , specifically the rollback part, two things must be in place :
The message received from System1 must be done by a transactional aware proxy Service (such as a JMS based Proxy service)
System 2, 3 and 4 , are XA aware.
This will ensure that the systems involved will rollback in case of an error.
Now, once the systems rollback , the initial message will be put back where it was originated. You would then define an error handler to deal with the error further.
I'm not sure that the case you described is feasible in OSB. I can't imagine how you could rollback something in System 2 in case of error raised in System 3. Sounds to me like all those "2-phase commit scenario" nightmares. :-)
However, maybe you can redesign your case this way:
1. OSB receives request from System 1 (msg1)
2. Enqueue msg1 in JMS queue (queue1)
3. JMS proxy (proxy1) is dequeuing msg1 from queue1 and sending it to System 2
4. If System 2 raises errors for messages, you can repeat later (as many times as you want)
5. If System 2 returns data (msg2) without failure, you enqueue msg2 to another JMS queue (queue2)
6. JMS proxy (proxy2) is dequeuing msg2 from queue2 and sending it to System 3
7. If System 3 raises errors for messages, you can repeat later (as many times as you want)
8. If System 3 returns data (msg3) without failure, you send them to System 4
9. If maximum repeat count (set by you) is reached either for proxy1 or proxy2, you raise error message and send it back to System 1
Hope that helps. 
I think it's possible to do this with OSB but just because it's possible it doesn't mean it's the best choice. It depends on your requirements.
Like HTH said, if all resources are XA aware (like RMI) you could have the proxy in OSB initiate a transaction and propagate it to the other systems so they will all rollback if there's an error in any of them.
But remember that since OSB is stateless there is no persistence of the state of the flow. What is the nature of your flow? Is it short-lived or long-lived? Should there be persistence of the state during each step so you can continue later if there's a system crash? Would you like to be able to track your flows and their execution? If that's the case then maybe WLI is a better fit. Just model the flow with WLI, expose it as another service on the bus and let it handle the orchestration and transaction management.
You could also use hisaak's approach with JMS to have persistence during each step if your flow can be asynchronous. Again, there are multiple options, but which one is better depends on your scenario. 
Thanks everyone for taking the time to reply,
Eduardo: the answer to your questions are that all the flows will be short-lived but if we can make long-lived flows then we might consider developing them. We would need to persist the state of the flow somehow.
I understand that some of our requirements would be better accomodated by WLI or bpel but we don't have an option but only to use OSB.
So, do you think we could overcome the stateless nature of OSB by:
1. writing to appropriate tables and reading from there and calling plsql procedures from the flows
2. using JMS queues.
In detalis:
1. Regarding the writing/reading from Databases (in our case it would be oracle 10g R2 - probably RAC), is there something like a Database control in WLI, which we could use in OSB? What i have seen are using xquery execute-sql function or a JCA DB adapter but both of them seem to me not very easy to use. Is there another option?
2. Regarding the JMS, in case that i want:
a service that writes to a JMS queue what are the servicetype and transport that i should use?
a service that reads from a JMS queues what are the service type and transport that we should used?
Any information that you may share with me in the design and implementation of the above would be great.
Thanks a lot. 
1. Regarding the writing/reading from Databases (in our case it would be oracle 10g R2 - probably RAC), is there something like a Database control in WLI, which we could use in OSB? What i have seen are using xquery execute-sql function or a JCA DB adapter but both of them seem to me not very easy to use. Is there another option?No we cannot use WLI controls with OSB. What difficulties are you facing using JCA Adapter? Learning curve is steep, but the DB adapter is versatile enough for the tasks.
2. Regarding the JMS, in case that i want:
a service that writes to a JMS queue what are the servicetype and transport that i should use?
a service that reads from a JMS queues what are the service type and transport that we should used?Use JMS(transport) BS for writing to JMS Q
Use JMS(transport) proxy for reading message from JMS Q.
Edited by: mneelapu on Nov 16, 2009 3:04 PM

Oracle SOA JMS use cases

Hi,Can anyone please share some use cases of JMS. I mean when we should JMS. In which scenarios of integration we should use JMS. Why to use JMS.Thanks
Hi there user, basically you have two broad use cases:1. Use JMS as transport protocol for SOAP based web services. Major advantage of this approach is that it can guarantee message delivery. Alternative for this is WS-ReliableMessaging2. Use JMS as message oriented middleware (MOM) where composites get triggered after a message consumption or they produce messages that needs to be consumed from other applications. The latter can be subdivided into multiple use cases, but it primarily depends on the system you want to integrate with. If these systems accept or produce messages in a JMS destination, then you need to use JMS adapter to consume/produce messages. Transactionality is another very interesting approach which you may want to consider. Using the JMS adapter brings your more freedom as you do not have to code compensations and rollbacks. They are provided out-of-the-box from the JMS provider. Though there a few emerging standards that guarantee message delivery, support transactions, etc for the pure web technologies, e.g. pure HTTP, MOM is more robust in this direction. Of course it comes at a price. HTH,A.
Hi, When Can You Use the JMS API?An enterprise application provider is likely to choose a messaging API over a tightly coupled API, such as a remote procedure call (RPC), under the following circumstances.The provider wants the components not to depend on information about other components’ interfaces, so components can be easily replaced.The provider wants the application to run whether or not all components are up and running simultaneously.The application business model allows a component to send information to another and to continue to operate without receiving an immediate response.For example, components of an enterprise application for an automobile manufacturer can use the JMS API in situations like these:The inventory component can send a message to the factory component when the inventory level for a product goes below a certain level so the factory can make more cars.The factory component can send a message to the parts components so the factory can assemble the parts it needs.The parts components in turn can send messages to their own inventory and order components to update their inventories and to order new parts from suppliers.Both the factory and the parts components can send messages to the accounting component to update budget numbers.The business can publish updated catalog items to its sales force. Cheers,Vlad
Hi AnatoliAtanasov and Vlad, Thank you so much for your kind responses, these are really helpful.