Posts Tagged ‘Best practices’

Best practices 4 – Security and Identity Management

This is the fourth blog in a series of BPM and SOA best-practices. The previous blog in this series was on Oracle ESB and Mediator. This blog will discuss security and identity management in an SOA-environment.

Best practices 3 – Oracle ESB and Mediator

This is the third post in our SOA and BPM best practices series. This blog provides best practices for Oracle ESB (Oracle Fusion Middleware 10g) and its successor (when it concerns routing and transformation): the mediator component in SCA (Oracle Fusion Middleware 11g). The previous blog in this series is about Web Services best practices.

Best practices 2 – Web Services

This is the second post in our SOA and BPM best practices series. This blog is about Web Services and provides a mix of general tips and more specific tips for Web Services that are implemented using Java and JEE. You can find the first blog in this series here.

Approach. Decide upfront, based on the requirements and constraints, what approach for Web Service development best suits your situation: top-down or contract first, bottom-up, or meet-in-the middle.

• Top-down or contract first. The starting point here is the contract of the Web Service: its WSDL. You either design it or it is provided as a ‘given fact’. From the WSDL you generate the implementation. If the contract frequently changes, regeneration of the code can cause difficulties since the implementation is overridden. If you use this method, make sure you don’t change the generated artifacts.
• Bottom-up or implementation first. The starting point is the implementation; all Web Service artifacts“such as its WSDL’s “ are generated. This is a fast approach when you want to expose existing components as Web Service. However, you need to be careful because you have limited control over the generated Web Service artifacts and it is therefore easy to break an interface if the Web Service is regenerated.
• Meet-in-the-middle approach. Here you define both contract and implementation yourself and later on create the glue between them. In case of Java you can use JAX-WS and JAXB APIs and code to create this glue. This is a very flexible approach: you can change both the WSDL and the implementation. It requires more work in the beginning, but is easier to change later on.

Compliance. A Web Service that isn’t standards-compliant is less (re)usable. Make sure your Web Service is compliant to the WS-* standards by using the WS-I profiles (Web Services Interoperability Organization).

Exposing operations. Don’t expose all methods as Web Service operations by default when using a bottom-up or meet-in-the-middle approach. Only expose those methods that are actually needed by service consumers. This promotes encapsulation and prevents access to ‘internal’ methods.

Products. Nowadays most products and technologies support Web Services. Keep their pros and cons in mind when deciding what technology to use. Java for example provides better support and a better runtime for Web Service development and XML-processing than relational databases.

Large XML documents. Avoid creating Web Services that receive, process, and/or send very large XML documents. XML processing is resource-intensive and relatively slow and therefore not well equipped for handling bulk data. Use other technologies such as database technologies or ETL tools for that purpose.

Quality of Service (QoS). It’s easy to develop basic Web Services-but it’s hard to make them robust, secure, and scalable (enough). Address these QoS (or non-functional) issues in the beginning of the project instead of discovering that requirements are not met at the end of your project.

Annotations. Be careful when using vendor-specific annotations (as opposed to the general annotations defined in the JAX-RPC, JAX-WS, and JAXB standards). Although vendor-specific annotations such as those in WebLogic can be very powerful they break portability of Web Services and tie them to a specific runtime.

Migration to WebLogic. See this blog for migrating JAX-WS Web Services from JDeveloper 10g/OC4J to JDeveloper 11g/Weblogic. Note from the blog that a bottom-up approach was used. After migration the WSDL was changed (among others the namespaces were changed) causing the invocation to fail. This is a typical example illustrating the pros of using a top-down or meet in the middle approach.

Next post in this series will be about best-practices for Oracle ESB and Mediator (FMW 11g).

Best practices for BPM, SOA and EDA

While visiting ODTUG Kaleidoscope 2009 in Monterey and talking to fellow BPM, SOA and EDA adepts I got this idea about creating a best practices and lessons learned blog series. This first blog is dedicated to best practices in the BPM and SOA-space based on cases from a presentation by Lonneke Dikmans. Subsequent blogs will dive into best practices and lessons learned for a specific product, methodology or technology.

Case I: Introducing BPM. Mistake: Organizational impact underestimated. Explanation: Successful delivery of BPM project, business heavily involved. Never used because they realized after delivery that changes in both the organization and the software were needed. Best practice 1. BPM and SOA are about business, IT and humans. Observe how people work, don’t just ask them.

Case II: Notifications. Mistake: Dependencies between processes modeled directly in the processes itself. Explanation: Process flow sometimes is influenced by other processes. This was modeled into every process: this makes processes tightly coupled to each other and hard to change. It resulted in deadlocks. Best practice 2. Use events to notify running processes. Best practice 3. Monitor & avoid exceptions.

Case III: New technology. Mistake: Use BPEL as a general purpose language. Explanation: BPEL is a domain specific language; it was designed to orchestrate (web) services. Someone coming from a homogeneous -for example PL/SQL environment- in their back office, could decide to rewrite everything in BPEL, even the service implementations. The progress of such a project is very slow, and doing things that used to be easy becomes very hard. Best practice 4. BPEL is a Domain Specific Language (DSL); use BPEL for orchestration only. Best practice 5. Use an Enterprise Service Bus (ESB) to expose services to consumers including BPEL. Best practice 6. Use Java for service implementation. Best practice 7. Use PL/SQL for persistent data manipulation and data integrity rules. Best practice 8. Use rules when you need customization, inference or when business rules are volatile.

Case IV: Quality of Service. Success: involve administrators early. Explanation: Someone designed their first SOA project with quality of service in mind. In production all the non-functional demands were met. Best practice 9: Design architecture for Quality of Service from the start … but only what you really need! Not everyone needs clustering, fail-over, high-availability, and so on.

Case V: Domains. Success: combine a top down with a bottom up approach. Explanation: By defining 6 business domains and one supporting domain, the service taxonomy and event definitions were easier to keep track of. Also defining an owner for some of the services and design guidelines for services that cross domains become possible. Best practice 10. Use domains and layers to facilitate making a taxonomy of services and defining design guidelines.

Conclusion. Think big, start small. Meet in the middle requires aligning Business, IT and People. Architects can be intermediaries. Sharing knowledge and experience is necessary.

The next blog in this series will dive into Web Services best practices.

DOAG 2009: Day 1

Today was the first day of the German Oracle User Group. It is a very large conference. This year, they decided to make the conference international: People from different countries were invited to speak in english on the conference. I started the day by attending two sessions by Clemens Utschig.
The first one was titled “SOA and the Enterprise, thoughts beyond technology”. This was an interesting presentation for several reasons. First of all, it is very good to see that Oracle starts to pay attention to the architecture that is involved in practicing SOA and BPM. Secondly, because of the content. A quick summary of what stood out most for me:

The definition from the OASIS reference model has a couple of interesting notions. In the presentation he picked out three interesting quotes from the reference model:

• What is SOA: “Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. “
• What is a service: “A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description”
• Capability: “The purpose of using a capability is to realize one or more real world effects”

Secondly he stated that in the US, the business needs to be aligned with IT. But in Europe IT needs to be aligned with the business. In other words: in Europe we think organizational change first, before we do technical stuff. In the US that is the other way around. This is very interesting if you think about the home base of the big tool vendors….
Last but not least, he stated that introducing SOA and BPM will not only change how the process and IT flows, but also the culture in an organization. This is very much in line with what Approach is doing in the SOA/BPM area: we focus on Business- IT – People alignment and started a user experience group recently.

Clemens’ second presentation showed SOA Suite 11g. Interesting observations:

• The rule engine Oracle acquired is going to be used for Oracle Apps only
• B2B adapter is part of base SOA Suite
• Customization will be applicable to BPEL

There were a lot of tracks that I did not visit: Christian Shay did a session about Oracle and .NET, there are database sessions, Siebel, BI etc, etc. Enough for everybody’s taste!

Oracle SOA Suite best practices guide

Justin Kestelyn blogged a little while ago about the release of the Oracle® SOA Suite Best Practices Guide 10g Release 3 (10.1.3.3.0). I did not find the time to read the entire guide yet (it has 272 pages in total), but you can easily use the guide as a reference to lookup information about transactions in ESB, file size limits, XML debatching with the File adapter, to name a few of the topics I did read.
The guide consists of two parts:

• Part 1. SOA Suite components. This part is not really about best practices, but explains the ins and outs of different SOA suite components. The term SOA Suite is not completely clear to me: in this case it is not what you download when you click on the link download SOA Suite. Maybe it refers to the concept SOA Suite. It covers Oracle BPEL process Manager, Oracle ESB, Oracle BPM Human Workflow (what a weird name is that???), Oracle Technology Adapters, Oracle Data Integrator and Oracle B2B, but not Oracle rules, Webservices Manager or Oracle BPA Suite.
• Part 2. SOA Suite performance best practices. This is the part that really talks about best practices. It contains configurations and examples from real use cases. Both the problematic configuration and the solution are described. This is really helpful when you are designing your system, or when you are troubleshooting performance. It covers JMS to database adapters, Oracle BPEL process manager, and Oracle Human Workflow.

This guide is not a best practices guide for designing or managing your SOA, but it is definitely the source of information when you are working with Oracle SOA Suite 10g. If the answer is not in there, there usually is a link to documentation that already exists. So apart from the title, I am very happy with this document. It might be a good idea to print it, 272 pages is a lot to read from a screen…