Web Services and Files Exchange

SOAP based Web Services are now very common in the enterprise architecture, and quite often, applications that consume or publish services would need to send binary content such as images, PDF or Word documents (or anything you have in mind...). The SOAP and XML provide different way to achieve this. So what are the challenges around binary data exchange using SOAP based Web Services:

• The main goal of Web Services is interoperability; so when you are offering a service, you need to be careful about the technical choice you are making. SOAP has been one great success in term of interoperability. I am aware that REST is also a very good fit for that but since I talk about SOAP and later WS-* standards, I do not want to talk about REST more in this post, the only thing that you can put in your mind is before choosing to implement SOAP based Web Services, ask the following question to yourself: "do I really need SOAP services or REST would be enough?"... That said let's continue on SOAP and binary content exchange. When talking about binary content, the interoperability comes with some trade off around for example performance/message sized or impact on developer. This will be discussed later, but always keep in mind that interoperability is the key point of Web Services. If this is not the case on your project, that means you probably do not need to use SOAP that has an important overhead in general.
• Performance and Scalability is also quite important when you are building a service based application. Especially that often you cannot predict exactly how much a service will be used. We have to keep in mind that often services are build to be reusable, it is one of the basic best practices of development, so if the service is really "reused" it is important to keep it running with acceptable performances. This is why when talking about binary content, with SOAP it is important to talk about the impact of it on the size of the message and the processing cost.
• When using SOAP Composability is also quite important. In the context of binary content exchange with XML/SOAP it is important to support composability of the WS-* standard, and this in a performant manner. An example would be that a services that is sing WS-Security to sign part of the messages should be able to sign the PDF document using the same standard.
• Impact on development: it is interesting also when choosing the way binary content should be exchanged with SOAP, to see how much impact it has on the development itself. Does a developer must import specific API to be sure that the binary content is properly sent/consumed by the server or client. Note: I will talk about Java here, and particularly about JAX-WS/JAX-RPC since it is the stacks that I know the much, but the remarks would be the same on all technologies.

Let's now dive into the different options that are offered to a developer/architect to exchange document using SOAP:

• XML Base64 encoding
• SOAP With Attachment (SwA) using MIME (Multipurpose Internet Mail Extensions)
• SOAP With Attachment using DIME (Direct Internet Message Encapsulation)
• Message Transmission Optimization Mechanism (MTOM)

First of all, I will not talk in detail about the 3rd point around SOAP with Attachment with DIME, for a simple reason: this approach has been pushed by Microsoft around 2003/2004 and it is now deprecated in favor of MTOM.

Base64 Encoding

Base64 is part of the core XML capabilities, and when using it to exchange binary content in a SOAP message it has some very good advantages:

• Since it is part of XML itself, it has a great interoperability, I can say that all stacks will be able to consume or send messaged that contains Base64 data.
• For the same reason it does not have any impact on development, most of the Java stacks will automatically use base64 encoding when byte[] paramters will be present.
• Always because of the fact that is it 100% XML based, the composability with other XML/WS-* standard is very good.
• So far eveything looks great for this approach, but the trade off is the following: Base64 encoding is not efficient, since "lot of" CPU will be used to encode and decode the binary content. In addition the size of the encoded data would be around 30% bigger than the binary content itself. (It can still be used for small dataset)

SOAP with Attachment (SwA)

The SOAP with Attachment specification is the first effort of the Web Services industry to solve the problem of binary content with SOAP. The idea is to In addition to the W3C Note, the WS-Interoperability organization, has extend this recommendation to create a basic attachment profile to enforce the interoperability of it, using the SOAP with Attachment Reference (swaRef).

• The good part of SwA and is the fact that it has been noted by the W3C but also adopted by the WS-I organization. But in fact the interoperability is not that great, mainly because none of the Microsoft Web Services solution support SwA. It is true that most of the Java stacks, starting with the standard JAX-RPC/JAX-WS is supporting SwA and swaRef but it is not enough to call it a good interoperability.
• The reason why Microsoft refused to implement it, and why it is only a W3C note (and not a recommendation) it is because SOAP with Attachment has poor composability. The reason why it is hard to use WS-* standard with SwA, it is because it breaks some part of the model by ignoring the SOAP/XML processing and just put the document in the MIME header, and a simple reference to it into the SOAP message.
• SOAP with Attachment is efficient, because of the previous point. The SOAP stack does not really deal with the content and just stream it into the MIME header.
• When it is used with JAX-RPC and JAX-WS, has an impact on the developer, that must use specific Java API to build it service and put specific data types in the WSDL. The impact on development is not large, but still developper has to think about providing the good method signature or WSDL entry to enforce the use of SwA/swaRef in its service. Where I do believe most developers would expect this to be transparent.

Message Transmission Optimization Mechanism (MTOM)

The last mechanism is also based on MIME on the wire to exchange the binary content, but the way the message (SOAP+MIME) is build is totally different from the previous SwA approach. MTOM has been based on the "experience" of the others mechanisms, to be able to support composability without impacting the performance and the development.

• Interoperability is virtually great. It is great because it has been pushed by major vendors such as IBM, Microsoft, BEA, Oracle and it is a W3C recommendation, so interoperability should be good. I put a "virtually", because to be interoperable the various Web Services stack must implement it, and it is not the case yet. Today, most of the latest stacks are supporting MTOM so it should not be an issue if you are starting a project.
• Composability is perfect, since MTOM does use the SOAP envelop but it provides an automatic and transparent optimization to put the binary content on the MIME header. During the serialization of the message, the SOAP engine is working with the content with a temporary base64 representation of the content allowing all the WS-* operation needed, for example an XML signature, but without the overhead of dealing with base64 over the wire.
• MTOM appears like the most efficient way of dealing with large document and SOAP.
• Because MTOM is using the same approach than the pure XML base64 process, it does not have any impact on development. In fact this the the Web Service stack that choose to use base64 (embedding the document) or MTOM over the wire. And this could be done in conjunction with a WS-Policy. As you can see in the WS-MTOMPolicy this is not under the control of the developer but more under the control of the administrator and then the applications to choose or not to use MTOM.

But... Which one I should use?

Based on the different points described earlier is looks like MTOM is the way to go; even if this is true it cannot be summarized to this. First of all MTOM is not supported by all the stacks, so if you cannot control the consumers of your services and cannot impose a modern stack, MTOM may not be the best approach. For me, the second on the list is the Base64 approach, because of high interoperability but it is important to remember that has an impact on performance/processing. I personnally would not push SwA because of its non support in the Microsoft world... As you know the world is not yet 100% Java based ;). Let's take a look on which stacks are supporting MTOM today:

• JAX-WS reference implementation (and Metro)
• IBM Websphere 6.x with SOA Feature Pack
• BEA Weblogic 10
• OracleAS 10gR3 (10.1.3.1) JAX-RPC and FWM 11 preview (JAX-RPC and JAX-WS)
• Axis2
• XFire
• JBossWS

You can find more information on these comparison matrices : Apache WS Stack Comparison and Xfire Comparison Matrix. (these two are probably very interesting to keep... unfortunately they do not contains any MSFT data. I had one in the past, but cannot find it... if you have such matrix feel free to post it in comment.)

Working on a large XML or SOA project: think about "separation of concerns"

With XML and SOA becoming mainstream in the enterprise XML operation such as Schema validations, XSL transformations are now very common. These specific operations are CPU intensive and could become a performance bottleneck when directly applied on the middleware. It could be even worst now when using SOAP based Web Services and their related WS-* standards. For example with WS-Security, XML encryption and signature is now more and more used in SOA based applications.

This is why many enterprise architects are bow looking for solutions to improve performances of XML centric applications.

One of the think we learn when developing application, and that Aspect Oriented Programming has highlighted is the concept of “separation of concerns”. It is key to keep that in mind also in global architecture in our case by separating the XML processing from the business logic. Hopefully it is most of the time done directly by the various Web Services framework you are using, you do not code the SOAP request/response, it is hidden by the Web Services framework.

However, in the current application server, the full XML treatment is made directly in the container, for example the XML Encryption is made in the same container that the place where the pure business logic is executed. So let’s find a solution to extract the most intensive XML processing into another part of the system.

Vendors have now in their catalog appliances that could do the job. The same way that today we are using SSL accelerators to deal with SSL encryption/decryption, we can put XML appliance to deal with the intensive CPU processing operation: XML validations, transformation, Ws-Security enforcing point,...

Architecture Overview
The overall architecture could be represented using the following schema :

The role of the XML/SOA Appliance varies a lot depending of your project:

• Simple XML firewall to check the validity of the XML/SOAP messages
• Web Services access control: lookup enterprise directory to check authentication and authorization. This could be based on the WS-Security standards and its various tokens (username, SAML, ...)
• Content generation and transformation: the appliance can be used to serve various devices for example WAP cell phone or simple HTML Web Client. the XSL transformation is done in a very efficient way in the appliance directly.
• Services Virtualization : it is possible to route the different messages to various end point depending of simple rules. (business or IT system rules)

As you can see from an architecture point of view, XML appliances are very interesting to distribute the heavy processing of XML to some specific hardware. I have noticed that sometimes developers/architects hesitate to put another piece of hardware/software in their design, but I do think that in this specific case it is probably a good move.

Separating the concern is quite easy and very clean when dealing with XML processing, but also it will allow the overall architecture to be managed in a better way. This kind of appliance will allow administrators to centralize the management of policies, and transformations. But also a side effect of this is the simple fact that when dealing with Web Services, you can easily add WS-* support to many stacks that do not support "them".

XML/SOA Appliances Offering
I have said earlier that vendors are offering such products, here some of the product that I have met or pushed:

• IBM DataPower
• Bee Ware i-Sentry
• Vordel
• Layer 7 XML Appliances

What's next?
Some of you would probably raise the fact that the application server, especially when dealing with Web Services, must parse the XML/SOAP request even if this has been done by the appliance. Yes it is true, but I am sure that in a next future the vendors of such solution would optimize it by providing for example support for binary XML, or any other solution that will improve even more the performance of the overall IT in complex enterprise architecture. But for this application server must support binary XML first to avoid proprietary approaches.

Another point of view that I have not talk about is the possible support of such appliance around Web 2.0/Ajax optimization. I have not yet dive into this, but I am sure we can do very interesting things too.

Finally if you have experiences with any XML/SOA appliance feel free to post a comment about it, it will help the readers to see the interest (or not) around this topic.

Paris "SOA Forum" feedback; and little comments about SOA projects

This week I have attended a SOA conference in Paris the SOA Forum. (I was not there in 2006). This event is not a technical event targeted towards developers but mainly oriented for IT managers and decision makers. This day was well attended, around 200 people. The content and more important the questions and round tables provide a good snapshot of how SOA is adopted.

If last year, based on comments that I can get, the message was "What & Why SOA?" this year I have the feeling that most of the audience was really familiarized with the SOA concepts -as I said earlier it is not a technical conference- and now they are more asking "How and When SOA?". Lot of discussions were about how to I start the projects, since in many case the SOA will impact the whole IT, and even more the full enterprise.

Thoughts about SOA project & approach

It is hard to say if the best way to start with SOA is starting from the Top (C level) or from the IT department on a departmental project. To be honest I think it will depend of each organizations; and depends of "why" SOA is a good fit for the enterprise.

I am tempted to say that if the choice is made for a "Time-To-Market" reason I believe that the project will start from a specific business need and be implemented in a "bottom-up" fashion., meaning the IT will quickly put together some services to give some agility to the business. This is something that I have seen many times in the telco industry.

At the other end, when the key factor is about rationalization of the business processes over the whole enterprise, the project is often manage at the IT management level if not even higher. This because this kind of approach will have impact on many departments/people.

Basically like in any project it is important to have:

• good communication between actors that could be developers or departments
• share the same goals
• have an understanding of the technologies that will be used and their constraints.

If for the point 1 & 2 this is management that deals with this. For the 3rd one, we are closer to the technology where we can probably share the most -saying that because I believe that most of you, reader, are technical people. At the end of the day we do not build system with slideshows, but with products/solutions. So it is part of our job to take time to understand the pros/cons, limitations of the different products that will be involved in the project.

One example, is this week I have visited a customer and this customer wants to put in place an ESB to provide services to the different departments of the enterprise. Discussing at the global level of the architecture we all agreed on the different needs such as: connectivity to heterogeneous systems, transformation, routing, ...

Then the customer talk about "Web Services" again and again, this is where I have to say, I always try to slow down the discussion to set the expectation at the correct level, for example talking about impact on reliability, security of the HTTP/SOAP based Web Services. Don't get me wrong I am not saying that it is not possible to achieve correct QoS (Quality of Services) with Web Services but it could have an impact on the product choice, for example supporting WS-RM, WS-Security or even using proprietary approach for stateful Web Services, ... And the same comments, questions could occur with other part of the stack.

In conclusion, independently of the type of approach you are taking to put in place a Service Oriented Architecture, you will need sometimes to really understand well the product/solution you will be using to implement it. And for each of the options you will be choosing take some time to estimate the pros/cons and limitations of it. The same way you are taking time to list the different services, their granularity, their QoS, you need to take some time to analyze the different solution. For example when you choose to use an ESB, BPEL engine with their connectivity capabilities, what are the best way to connect to a system (SOAP, JMS, JDBC, JCA, Java, ..), how to code the logic (Java, BPEL, business rules, ...) and for each of this question think about the impact of it on your system. For example, how portable will be my code/business process, and is it important for me?

Oracle BPEL: Debugging "internal" SOAP Messages

When you develop applications that use SOAP based Web Services you very often use an HTTP proxy to capture the request and response that are exchanged between the clients and servers. For this you can use the Oracle HTTP Analyzer that is part of the toolset of Oracle JDeveloper, Axis TCP Monitor, or a packaged version of it that you have with Oracle BPEL Process Manager. BPELs are making extensive usage of SOAP messages, and it could be interesting to debug the different call to the partnerlinks. Oracle BPEL PM, to avoid HTTP calls and make optimized SOAP message when the partnerlink that you are invoking is deployed as a BPEL. So in the default configuration you do not see the different calls. In this article I explain how you can configure the server to be able to do it. For this I will be using:

• Oracle BPEL Process Manager developer install running in an OC4J 10g Stand Alone (10.1.2.0.2)
• obtunnel, that is a package version of Axis TCP Monitor located in <BPEL_HOME>\bin\obtunnel.bat
• LoanFlow demo that you can install in 2 steps:
• In a shell, go to <BPEL_HOME>\samples\demos\LoanDemo
• Run the following command to deploy the LoadFlow BPEL and associated Web Services: > ..\..\..\bin\obant

Starting the Oralce BPEL Tunneling tool:

• Just run the command <BPEL_HOME>\bin\obtunnel.bat You will see the following application:

By default the TCPMonitor launched from BPEL listens on the port 1234 and proxies for the default Oracle BPEL port 9700. So in this context you will capture all the requests is you access the server on the port 1234. It is not sufficiant here since the different partnerlinks endpoint are not dynamique and are set to the port 9700. So in this case you wont's see the request coming from the BPEL to a local partner link (and I am not talking about the SOAP Optimization yet). One way that I use to work around this issue in development --may be we have more simple solutions, but this is the one that I use-- is to change the port of the OC4J and make the proxy listening on the port 9700. In this case you will be able to capture the requests made from BPEL to its partnerlinks.

Changing the Port of OC4J and the TCP Monitor

I. Change the HTTP port of OC4J used by BPEL

1. Open <BPEL_HOME>\system\appserver\oc4j\j2ee\home\config\http-web-site.xml
2. Edit the port attribute of the root element web-site to enter a different value eg: <web-site port="9701"...
3. Stop your BPEL Process Manager

II. Start a new TCPMonitor on port 9700

1. In the TCPMonitor sceen click on the Admin Tab
2. Enter 9700 for the "Listen Port #" field (since we want to be sure the partnerlinks are called correctly)
3. Enter 9701 (or the value you entered for the HTTP port) for "Target Port #".
4. Click Add
5. Click on the new tab "Port 9700". If you have an error message like "java.net.BindException: Address Already in use: JVM_Bind" this is simply because your BPEL process manager is not stopped. In this case stop the BPEL server, and start the TCPMonitor by clicking the Start button.

III. Restart you BPEL Server Nothing special here you just need to start your server, and check that the BPEL PM is now listening on the HTTP port that you have entered, in my case 9701:

• http://localhost:9701/BPELConsole

You can now go on the test page of the LoanFlow process (either on the port 9700 or 9701) and invoke the process. I am using 9701 since I want to capture the calls make by the Business Process to its partnerlinks. You can see some HTTP activities in your TCPMonitor, but if you look in details you only see request to the different WSDLs used by the LoanFlow... I was like you expecting to be able to see the different SOAP requests and response, but BPEL does some optimization around local SOAP calls. So to be able to capture these requests you just need to turn of this optimization.

Turning Off the SOAP Shortcut

1. In the BPEL console, click on the "Manage BPEL Domain" link (top right)
2. You arrive in the configuration tab, look for the optSoapShortcut property and set it to false.
3. Click Apply

You can now go on the test page of the LoanFlow process (either on the port 9700 or 9701) and invoke the process. I am using 9701 since I want to capture the calls make by the Business Process to its partnerlinks. Now you can see all the SOAP requests and responses between the LoanFlow BPEL and its partnerlinks.

Click to Enlarge

Update on 08/02/2007 For people that are currently using Oracle BPEL 10.1.3.1 the optSoapShortcut is not visible anymore in the console, but it is still possible to configure this by adding it manually in the domain configuration file available at: $BPEL_HOME/domains//config/domain.xml

SearchWebServices: Oracle's Steve Harris on Java and standing out in SOA, part 1

Interested to know more about the Oracle Application Server 10g and the SOA/Java strategy? Take some time to read the SearchWebServices.com interview with Steve Harris, VP of the Java Platform Group at Oracle.     Oracle's Steve Harris on Java and standing out in SOA, part 1 Addition on 30/12: follow TheServerServide discussion

Can I do SOA with Web Services today?

I am just coming back for Toronto where I have been presenting Oracle Developer Day: SOA for J2EE Developers. As part of this exercise I have introduced Web Services and related technologies/standards.

A person in the audience asked me:

But can I do SOA Today?
Are Web Services are mature enough?

I think that is a very interesting and valid question. The answer is certainly: 

Yes you can, and I would add, yes you should!!

Web Services are  definitively big actors in Service Oriented Architecture since by definition they are loosely coupled, implementation agnostic and facilitate reusability. In the same time the concern of this person are justified since some important pieces of infrastructure are yet available in vendors solutions. Or if they exist they are proprietary and won't allow interoperability of the service with other stack... Losing interoperability is a big deal when you talk about Web Services since most of the time, if the designers want to use Web Services it is to be able to reuse it in various applications, independently of the platform where this application is running.

Why I have answered Yes?

Why I am so positive when I answered this person? Just simply because Web Services are today mature enough. But like any development of applications/systems the development should start with a clear definition of the requirements. When the development team will start to write down the requirement it will be clear of not what are the important pieces in term of services. Beside the business requirements, lots of requirements are technical/IT related such as security, performance, manageability, reliability, and transaction management, performance... So when you design your system do not forgot to clarify what are the different infrastructure services you need....

It is then easy to match your infrastructure requirement list to the different quality of services supported by the platform you will implementing on, and as important, the platform(s) you will have to integrate with.  For example today it is possible to easily create SOA/Web Services application that are secured because WS-Security is a standard supported by most of the vendors. At the opposite it may be very challenging to create SOA/WS based application that involve a very complex transaction model with various applications and system since no standard have been implemented in a real interoperable manner. But no worry the WS brains are here and work on it, take some time to read more about WS-Transactions and other related standardization effort.

Based on the previous example with security and transaction, it is also important to keep in mind that the Web Services is a mature technology but it is still evolving -based on real life requirements-. So in the same time your application/system will evolve -it is one of your goal when you do SOA, it is to build a more agile system that can react to business, or technological changes quicker-, do not forget that your vendor are continuously working to not only define the standard but also implement them in their product. So you may put as a requirement from the beginning a specific infrastructure services that are not available in today's product but the important question to ask you before dropping SOA/Web Service is when I really need this feature? When this feature will be available in my platform?

This is why also it is important to understand the strategy of your vendor in term of flexibility and adaptability of their solution to the different standards, and how it can help you to take care of legacy services that need to integrate with your new applications. One nice example is the usage of Oracle Web Services Manager. Even if WS-Security is one of the first standard around "Enterprise Web Services" it has not been in the different stack for long so lot of existing WS do not support WS-Sec. Oracle Web Services Manager allow you using agents and/or gateway to add security in a standard way to existing services, and enrich you SOA with a better quality of services.  So do not say no to SOA/SOA because a standard does not exist or exist but not implemented, it will come -take a look to all the WS-* effort-, and this standards will be able to extend the system that you are building as you need.... SOA is all about agility, to be sure that it will be agile enough to provide you more services as you go!

Web Services and SOA Web Site

I was yesterday talking to a customer about Web Services and Services Oriented Architecture, and he was looking for more information. So I shared with him one of my bookmark.

http://www.service-architecture.com/ is a Web site dedicated to WS and SOA with lof of articles that defines for example most of the WS-* acronyms.

• Web Services Articles
• XML Articles
• Application Server Article

BPEL: Edwin answer to Dutch'Rant post

If you are interested by BPEL you can take a look to the blog entry 'BPEL: Yes or No?' and the answer/comments from Edwin (VP of Development of Oracle BPEL Process Manager).

JavaWorld Article: Event-driven services in SOA

Interesting article about Event Driven Architecture (EDA) and Service Oriented Architecture based on Mule an open source ESB.

New Oracle White Paper: Accelerate Development and Deployment of Service-Oriented Applications

Oracle has published a new white paper about Service Oriented Architecture, and how Oracle Application Server 10g accelerates SOA development and deployment. Read the paper on the Oracle Web Site.