Today, organizations of all sizes are adopting Service Oriented Architecture (SOA) for delivery of critical enterprise services. In this post we will discuss what SOA is and who within the organization needs to be involved.
Service Oriented Architecture is an architectural style that exposes enterprise assets as services that can be configured and reused in business processes.SOA takes a process-centric view of the enterprise, viewing the enterprise as a collection of business processes. Three critical aspects of SOA are services, business processes and governance.
Read the rest of this entry »
I have been working in Service Oriented Architecture for almost a decade. During that time, as a trainer, architect or consultant – I have probably worked with over 100 businesses and government agencies to address their SOA needs. In every case, as we looked at adopting SOA, the perceived benefits were always somewhat theoretical, not that they weren’t real, rather they would not be realized until sometime in the future. For example:
As our SOA implementation matures and we develop a number of reusable enterprise services — new business processes can be created and existing business processes can be modified quickly, with reduced costs and minimal disruption to the enterprise.
Recently I had the opportunity to work with a bank that was looking at SOA in a very different way. Like other organizations looking to adopt SOA they saw the future, long-term benefits. The difference is that this bank also had a very real, tangible short-term goal for their SOA implementation — a goal that gave them no alternative but to succeed, and they were willing to bet their business on it!
In this blog, I’ll briefly describe what SOA Governance is and list the features of a SOA governance toolset. Then, I’ll provide a tutorial on several of the design-time, governance capabilities of WSO2 Governance Registry, a freely available, open source governance toolset.
SOA governance builds upon IT governance and aims to provide a framework and model to manage SOA applications in relation to managing service lifecycles.
There are three stages of SOA governance:
We have just released our first web service class as part of our Java EE 6 courses:
Java EE 6 contains two ways to write web services, JAX-WS for “classic” SOAP web services and JAX-RS for REST web services. This class covers how to implement both styles. The course also covers securing both types of services and compares the two styles so you can decide which might be appropriate for different situations.
I think this course will be especially useful for people that support JAX-RPC web services from J2EE 1.4 but need to look to what are the more recent Java standards for web services. Java EE 6 put JAX-RPC on the “proposed optional” list of technologies which means in the future Java EE servers may not be required to support JAX-RPC. Although I expect WebSphere will still support it now is a good time to start looking for how to migrate JAX-RPC web services to more recent standards like JAX-WS and JAX-RS.
This course is part of our WebSphere Application Server 8.0 Programming course map. We have other courses that cover just JAX-RS or just JAX-WS as well as a course that covers REST services with JAX-RS and the AJAX clients that are most common for REST services.
If you have any questions about these courses feel free to contact us.
Web services development has gone from an area that is “new” for most people to something that many people have experience with. This does not mean that things are not changing though. Many people know how to do “basic” web services, perhaps even applying security but in the current servers there are so many more things you can do.
Some of these newest features that not everyone is familiar with are:
We have released a new 3 day class, WA1616 Advanced Web Services, to cover these advanced web service development areas. This course also includes just a brief coverage of JAX-WS web service development in case developers are not aware of this relatively new Java framework for web service development.
This course would be appropriate for any developer that has some web service programming or XML experience but wants to dive deeper into these more advanced topics. For those that might also want more coverage of the “basics” we could come up with a custom class that includes other topics before the advanced topics in this class.
Contact us to find out more about this exciting new course.
IBM has merged WebSphere Lombardi Edition (WLE) and Lombardi TeamWorks with WebSphere Process Server. The new combined product is now called IBM Process Manager 7.5. Understanding the various pieces within it can be very confusing. I spent a whole week playing with the server and development products. Below is a summary of what I found. This by no means will answer all questions. But, it’s a start.
All my experiments have been with the Advanced editions. In places, I try to make note of other editions.
IBM Process Manager Advanced edition gives you two types of profiles that you can create.
The key thing to note here is that a Process Center profile contains a Process Server. Generally speaking, for test and production environments, you will create a Process Server profile. Process Center profile should be used in development only.
The installer for Process Manager gives you an option to create a Process Server or Process Center profile. These are standalone profiles, meaning, the nodes do not belong to any pre-existing cell and the servers are not clustered. Generally speaking, you should use this option to quickly setup a server runtime suitable for development and testing. In a production environment, it is recommended that you manually create a profile using the Profile Management Tool (PMT).
In passing, I should mention that Derby (Cloudscape) is no longer supported as a database. You must use DB2 or Oracle. IBM ships DB2 along with the Process Manager media.
To develop BPEL processes and SCA modules, you will need to use IBM Integration Designer (IID) 7.5. This is essentially an upgrade of WebSphere Integration Developer (WID).
To develop BPMN processes, you will need IBM Process Designer (IPD). This tool will eventually replace WebSphere Business Modeler (WBM). Just like in WBM, you can model a process using BPMN notation. You can assign KPI metrics and run simulations. A key difference is that, in IBM Process Manager 7.5, a BPMN process is not just a modeling artifact. You can actually execute it in a server runtime. Consequently, IBM Process Designer lets you test and debug BPMN processes. BPMN exists in a parallel universe from BPEL. The BPMN runtime supports its own idea of adapters, human workflow and business objects. The technology does not use SCA. Adapters do not use JCA.
While IID and IPD have very different intents, they can exchange artifacts through the Process Center repository. For example, BPEL and BPMN processes can invoke each other.
IID install media contains a cut down version of the IBM Process Manager Advanced server runtime. This runtime can create a Process Server profile only. There is no way to create a Process Center profile. This seems rather odd, since, Process Center is something that is used mainly in the development world. If you must use Process Center from IID, take these steps:
Now, the same server can be used by IID and IPD. You can use it as a repository as well as the runtime to execute BPEL and BPMN processes.
For more information, please inquire about our courses:
A mediation flow can run multiple branches in parallel but in a single thread. Basically, it uses the request with deferred response pattern. We will use an example to understand how things exactly work. But, before we get to that, let’s look at what we need to do to enable parallel processing. You will need to do two things:
1. For the Service Invoke primitives in the aggregation block, set the Invocation Style property to Async.
2. For the Fan Out primitive, choose Check for asynchronous responses after all messages have been fired. The Fan Out has to be in iteration mode for you to be able to choose that option.
Now, let’s examine an example.
Here, for all Service Invoke primitives, Invocation Style has been set to Async. For the Fan Out, Check for asynchronous responses after all messages have been fired has been selected.
The flow will perform as follows. First ServiceInvoke1 will be called immediately followed by ServiceInvoke3 (actually, the exact order of their invocation can not be determined and does not really matter). System will not wait for response from ServiceInvoke1 before ServiceInvoke3 is executed.
Since there are primitives left to be executed in both branches, the flow will then go to wait for responses to come back from the two already executed operations. This wait in the middle of the paths can not be avoided since the subsequent primitives may depend upon the output of the executed operations. After ServiceInvoke1 and ServiceInvoke3 return output back, system will then execute XSL4 and ServiceInvoke4. Without waiting for response from ServiceInvoke4, system will execute XSL2 and ServiceInvoke2. System will then wait for the responses to come back from these two Service Invoke primitives.
In the example above, request is sent but the system does not wait for a response. You need to be careful about the transaction boundary. Let us say that a request is sent by posting a message in a JMS queue. By default, the message will be actually posted if the transaction of the mediation flow commits. If the flow waits for a response, that will never come since the transaction is still active and the request message never went out in the first place. Long story short, you will have to post the request message in a separate transaction from the main transaction of the message flow. To do that, select the service reference of the mediation flow in the assembly diagram. Then set the Asynchronous invocation qualifier to Call.
WID v7 actually give you an error message if you setup parallel processing but do not configure the transaction boundary correctly.
This morning, I started working on the WebSphere ESB v7.0 programming course – WA1916 WebSphere Enterprise Service Bus (ESB) v7.0 Programming Using WebSphere Integration Developer. I had to migrate a few projects from WID 6.2 to get started. I thought I will share a few interesting observations.
WID has built in workspace migration wizard. When you bring in an old project – either through the import operation or CVS checkout – it will open the wizard automatically. In my case, I chose File > Import and then Other > Project Interchange.
I recommend migrating projects in two separate batches. First migrate the J2EE projects – that contain web services and web clients. Then migrate the business integration (SCA) modules. That will just simplify things.
In WID 6.2, the J2EE projects were on a half way journey towards Java EE 5. They were J2EE 1.4 projects with some aspects of Java EE 5 thrown in – such as JAX-WS and JPA. That was done through WebSphere feature packs. Now, in WID 7, we have true Java EE 5 projects. So, what that means is, migration will involve two steps:
So, let’s get started. Import the old J2EE projects (Enterprise application, web and EJB projects) into the workspace. The workspace migration wizard will start automatically after the files have been copied into the workspace. You can pretty much click Next in every screen. In the server runtime page, you will need to select a V7 server.
In my case, I selected WebSphere ESB Server v7.0. You can also select process server, if that is your runtime.
After the migration wizard finishes, if you have a JAX-WS web service in a web or EJB module, you will see an error message.
WebSphere Application Server v7.0 is not going to scan this module for JAX-WS annotations. You can enable scanning by setting the UseWSFEP61ScanPolicy property to true in the MANIFEST.MF file.
I must say, I was stumped by this. Fortunately, I could Google "UseWSFEP61ScanPolicy" which lead me to this InfoCenter page. Log story short – I had to migrate the projects from J2EE 1.4 to Java EE 5. Honestly, I did not originally consider that step, until I saw the InfoCenter page. So, in a way I am glad I saw that error message. In the next section, we will deal with Java EE migration.
Right click the enterprise application project and select Java EE > Specification Migration Wizard. Once again, you can pretty much click Next in every page and complete the wizard.
But alas, the error message remained. No amount of cleaning, rebuilding and re-validating got rid of it. Fortunately, I found an easy solution. Just export the projects as project interchange and then import them back in. That will get rid of the error.
Import the SCA modules into the workspace. The workspace migration wizard will open. Change the server runtime to V7.0. And you are done!