With the rise of cloud and mobile apps, application integration today is changing. Enterprise architects face a challenging new space, marked by a mixture of old and new integration and development approaches. In order to tame the complexity, many enterprise architects are embracing lighter-weight technologies -- such as REST-based APIs -- or taking new approaches to familiar tools such as the ESB. To learn more, SearchSOA.com recently spoke with Maja Tibbling about mobile apps, REST, semantics and a few other issues related to the future of application integration.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Tibbling is principal enterprise architect at freight logistics company Con-way Inc. Below is part two of the two-part Q&A. In part one, Tibbling talks about achieving real-time application integration. Here, Tibbling discusses what's in store for mobile application integration, REST and SOA as a whole.
Mobile applications are a new hot trend. Freighters out there on the road have been attached wirelessly for some time. What do you see going on in the mobile application space?
I'd say the lightweight protocols that are coming along will certainly enable more mobile apps to connect more readily. Another evolution I'm seeing is what [information] the mobile apps are sending. It's vital information other than just the data involved in whatever they happen to be doing. They may be recording information about a pickup—but meanwhile we're also getting their location information, GIS and GPS data which tells us what they are doing now, what the time spent at the location was. That allows us to optimize our operations repeatedly because we're getting a much more rich, big data type of set of information to analyze and mine.
We have our sales force using iPads and iPhones, accessing [external] sales apps as well as our internal apps here for customers' information, information about their shipping history, all of that sort of thing. All of those applications they use, they can access them directly from the field now. They rarely ever have to come into the office. This is what the mobile area has enabled. And services have made this possible.
Early SOA was very much associated with SOAP, RPCs and XML. Today we are seeing a shift to lighter weight approaches, such as REST.
Absolutely. REST is a very easy-to-use protocol from a Web app. I don't see it as much because of security requirements from mobile apps. SOAP seems to be often used from many Web apps, at least in enterprises like this. I'm sure there are other gaming apps and things that are using REST. But we have a higher security requirement often from ours. That's one of the differentiating things between those, is that even with the encryption of HTTP-S, you may end up wanting to use a protocol that can carry with it a little bit more security and authorization.
Better ways need to be there to resolve the semantics on more complex transactions. That's the biggest hurdle.
In a way, SOA has become more prevalent for application integration. Do you think it can continue to become easier to use?
We open our laptops or turn on our smart phones and we're connected to our wireless. All of these things become more and more intrinsic in the tools as they become institutionalized and universal. They're automatic. A lot of the things that are generating—and already in Java there are so many tools that do the object to XML automation—have made it so it's not a flog to map the Java object to the XML object. More and more of these tools will come in all areas that will allow us to just connect.
Better ways need to be there to resolve the semantics on more complex transactions. That's the biggest hurdle. We're finding things, even internally, as we grow this practice. Making that contract truly understandable so that it is known what data is being expected when we have a field in the XML. Semantics are important. That's the only roadblock. The actual use of services is going to become completely hidden and automatic.
If you think about EDI, it is completely open in some ways. You really have to understand it to know what to put where - which means that as people have implemented it over the years, every implementation of a particular message has to be studied to make sure you got it right, because the semantics are not fully understood.
There are other XML organizations that have created very comprehensive XML documents to try and cover large segments of many industries that are so complex that they're also hard to understand. Internally, what we've done is we've implemented a canonical that defines memos for the business. But we're a complex business so it also takes experts to become fully immersed in it and to fully understand the semantics.
Web semantic things are coming along and are trying to find a way of correlating definitions and usages with certain means of properties across lots of industries. I don't know if that's ever going to go anywhere because it is extremely complicated. The best you can do is try to internally define a canonical that works for your company. Then have people who can really resolve that semantic to other semantics like EDI or whatever protocol.
There's been a lot of efforts as part of that whole initiative. There's been work to do mappings to try and make things truly understandable so that they could be automated. You get a bunch of magic experts together and it's like getting a bunch of architects together to decide on a model.
Canonical is still the best way to go, especially even if you just choose one that works for you internally. The reason is that, with some of our back end systems, they have their own semantic, every one of them. And yet they need to talk to each other. If you don't translate it into a common language in the middle, the best you can do is point-to-point. If you're doing point-to-point, then what you're not doing is ensuring that that richness of information is getting to other endpoints.
Follow us on Twitter at @SearchSOA.