| QUESTION & ANSWER |
Hapner on Ajax, integration and SOA security |
 |
By Michael Meehan, News Writer
25 Aug 2005 | SearchWebServices.com |
|
|
Mark Hapner is a distinguished engineer at Sun Microsystems Inc. He is lead architect of the J2EE (Java 2 Enterprise Edition) platform, co-lead of the Enterprise JavaBeans specification and lead for Java Message Service (JMS). Hapner, who is currently Sun's Web services strategist, also helped create the Java Business Integration (JBI) specification and is Sun's board member on the WS-I. In part three of this three part interview, Hapner examines the role of Ajax in Web services development, three common approaches to application integration and key security issues SOA developers should be concerned about.
part 1 | part 2Can Web services deliver as promised without more attention given to the presentation layer? What role will technologies like Ajax play in rendering these services for consumption?
Mark Hapner: If you're doing application level integration, eventually this information has to get to people and there needs to be a broad set of capabilities to support the human interaction requirements. Ajax exploits the capabilities of our existing infrastructure in a useful way to make things more interactive and helps add value to all this work we're doing.
But there's still quite a bit of work to be done. Adobe is doing some interesting things with using documents as live elements to interact with services and Ajax is a nice step forward. Just from a Sun perspective the Creator 2.0 that's been done with JSF and JSF components is useful and well in tune with the Ajax direction, which, effectively, is just to provide better interaction with the users of these services that we're constructing.
What integration approaches are organizations using today for B2B commerce?
Hapner: We're just in the process of sorting it out when it comes to moving from where we are. From an application integration perspective we've got three major tracks we're on. We have EAI [Enterprise Application Integration] and there are a lot of middleware products IT organizations buy to help them integrate across applications. That's evolving and adapting to this more service-oriented approach.
We have a class of B-to-B integration that's been cooking along for sometime through the EDI [Electronic Data Interchange] infrastructure. That's been pretty effective. It has issues of cost and complexity certainly, but there is a lot of business that goes through EDI infrastructure and financial networks. There's a lot of experience there in terms of how to deal with flows of information that could be brought back. There's experience there that's useful.
Also there's another form of integration which is through the Web sites, the Web companies that have sprung up, such as eBay and Amazon, which are doing tremendous amounts of through the Internet, application to application integration, simply using HTTP. They didn't wait for the SOAP envelope to be fully architected before they decided to integrate application to application. If you look at companies like SalesForce.com, a massive amount of their business is application to application and not through their Web browser interface. There's a lot of experience there and we'll be sorting through all of that.
What's really important is that at the application level you focus on the information flows. If there's a rule of thumb to be used in looking at what SOA is, it's focus on the information flows at the application level. I've tried to abstract away the protocol issues from the applications. To a large degree today, that means focusing on the XML messages that you're exchanging as the core elements of your application architecture.
They need to understand that their task is to implement services that produce and consume that information just like Web sites effectively produce and consume HTTP and HTML, though nowadays that may be a bit more JavaScript.
Is part of understanding that flow understanding where in the architecture that takes you to?
Hapner: You'll be developing a service in the context of other services and you'll need to deal with the information flows to accomplish the business tasks you're trying to accomplish. Let's say I'm trying to get a news store up on Amazon. In many respects what I'm doing is I'm integrating my existing environment with Amazon's store infrastructure environment and there's a huge amount of knowledge I have to have about Amazon's store environment to effectively use it, to effectively feed it and maintain my store. That's kind of an example of the integration tasks that are going to be facing developers as they go forward.
What are some of the central security issues people building SOAs are dealing with?
Hapner: I've got a few in mind, but that might let the cats out of the bag, but one of the issues that is potentially a big stumbling block for IT's use of SOA is controlling the information that's going through the flows that they're starting to construct. If you start modularizing your IT applications and having them focus on offering a particular service that you then utilize more broadly, whether it's a service offered by your HR department or your manufacturing department or whatever, the whole point of offering it as a service is that it can be more easily consumed and utilized.
The problem is that all of those services have information that needs to be protected in some way and so you've got a tension between opening them up through a SOA architecture and still maintaining the control you need over the information. That's a big challenge. SAML [Security Assertions Markup Language] as a technology is one of the elements that can help meet that challenge. It's a lot more than simply using HTTPs to keep the sockets private because once the information moves from one service to another how do you continue to protect it? How do you know that other service is going to protect it like you would have protected it?
Simply follow that flow is important because you could go to jail if you don't properly protect that flow, whether you're in the health care business [because of HIPAA] or financial information because of Sarbanes-Oxley. You're going to need some comprehensive information controls that flows along with that data, that sticks to that data, not just when the data's in a SOAP message, that somehow sticks to that data all the way end to end. It's not seen as an issue yet and I think it's waiting to come and bite. It may, if it's not properly solved, stunt the growth of SOA to some degree and obviously Sun is working to help solve that problem with a lot of the work it's doing on identity and access management. You need to attach access control to the information itself. You need to have control over the identities so you know who's who and you have to deal with outsiders coming into your environment and particularly information flowing from outside in. If you think about it, if you start integrating with your customers, your supplier, your partners and so forth, you're actually establishing a direct information flow between your system and their system. And, gee, there's a lot that can happen.
You need to be able to asset control in a more fine-grained way that we thought about it before. Using HTTPs to protect your sockets, well yes you should, but that doesn't solve the problem.
|
|
|
|
