PNSS, Day 2
Day Two at PNSS was good. It went by in what seemed like 20 minutes. I went to a session on Ajax architecture, given by an energetic and animated guy.
The next session I went to was about SOA. True to form, the speaker gave a realistic view of it, instead of the usual claptrap about SOA being the future of all computing, the end of all applications, and the beginning of a new era.
The basic story with SOA is that it, like other "plumbing"-related efforts before it (RPC, COM, COM+, DCOM, .NET Remoting, RMI, etc.) is about connecting applications with services. The difference is that this time around, SOA's definition is a lot more high-level (vague) and "business-y" (consumable by managerial types on the technical periphery), so it has buy-in from higher-ups in corporations, rather than being just something needed by developers of distributed systems. The speaker at the conference said he thought that the term "SOA" probably first appeared in an in-flight magazine. It was read by a CEO on his way to a business meeting, who then said "Yeah. SOA. I got to have me some of that", which is what got the ball rolling WRT SOA.
Unlike its predecessors, SOA isn't a specification that dictates the mechanics of communication between services and consumers. The thinking is that most communication should be done via XML, in a SOAP or REST web service-type setting, although that's not a formal requirement. However, communicating across machine boundaries in a transparent text-based format is vastly preferable to the previous attempts, which were usually binary protocols that broke easily and were hard to build, test, and debug.
The problem with SOA is that you can ask 10 different people what it is, and you'll get 10 different answers.
There's no specification I know of, and the description is so high-level that it leaves a lot of room for interpretation and agenda-pushing. Some people think it automatically means "web services" (it doesn't), others think it means "XML" (nope), others think it means "SOAP" (wrong again), while others, amazingly, think it means software will no longer require testing. Still others have said it means user interfaces will be built in the future using point-and-click with no code, all because of SOA. WTF?
Actually, the basic idea is this: Various business-specific functions are defined as "services" running in various locations. The "services" are software systems that sit idle until a "consumer" makes a request to them. So, instead of defining an application that provides its own security, authorization, business rules, etc., an application is defined so it communicates with one or more coarse-grained encapsulated business services through discoverable, negotiable interfaces. (Wow... I just described SOA in the plainest terms I could think of, and it sounded like a product brochure!) Anyway, it's a worthy goal. A full SOA implementation in a company would mean that no "applications" exist in the traditional sense; Instead, there would be an enterprise service bus (ESB) that everything hooks to, and provides access to everything else (think of it as a big pipe). A "Customer" service would provide access to customer data, a "Security" service would provide authenication, a "Rules Engine" would provide business rules, and so on. "Applications" would consume these services from the ESB instead of having "baked-in" dependencies on them. Services could be swapped out in favor of other services, or upgraded, without causing their consumers to break (as long as the services' interfaces don't change, of course, unless I'm missing something big).
Granularity of these services is a big issue, and probably the most important aspect to make sure you get right. Providing a consumable "Customer" service is one thing, but providing a consumable "Database" service is an idiotic idea. Given the hype surrounding SOA, I'm sure someone's going to insist on a consumable "Database" service eventually. Unsuprisingly, it will result in the slowest software ever created, and suprisingly, the person who insists on it won't be the one who gets fired. It'll be interesting to see how SOA turns out.
The final two sessions were about Hibernate. I've been a big fan of Hibernate for 3 years. It's simple to use,
efficient, lightweight, places no artificial constraints on the objects being persisted, and is, frankly, the best way I've found for mapping between objects in a java program, and data in a relational database.
One more day to go. This is a cool conference. I talked to the organizer of it today in the hall, and told him I liked how there was so much more "meat" to it than something like the neckties-and-cheerleadin' JavaOne-type conferences. He said "Yeah, we basically look at those conferences to see what they do, and then we do the opposite." Well, it's working.
The next session I went to was about SOA. True to form, the speaker gave a realistic view of it, instead of the usual claptrap about SOA being the future of all computing, the end of all applications, and the beginning of a new era.
The basic story with SOA is that it, like other "plumbing"-related efforts before it (RPC, COM, COM+, DCOM, .NET Remoting, RMI, etc.) is about connecting applications with services. The difference is that this time around, SOA's definition is a lot more high-level (vague) and "business-y" (consumable by managerial types on the technical periphery), so it has buy-in from higher-ups in corporations, rather than being just something needed by developers of distributed systems. The speaker at the conference said he thought that the term "SOA" probably first appeared in an in-flight magazine. It was read by a CEO on his way to a business meeting, who then said "Yeah. SOA. I got to have me some of that", which is what got the ball rolling WRT SOA.
Unlike its predecessors, SOA isn't a specification that dictates the mechanics of communication between services and consumers. The thinking is that most communication should be done via XML, in a SOAP or REST web service-type setting, although that's not a formal requirement. However, communicating across machine boundaries in a transparent text-based format is vastly preferable to the previous attempts, which were usually binary protocols that broke easily and were hard to build, test, and debug.
The problem with SOA is that you can ask 10 different people what it is, and you'll get 10 different answers.
There's no specification I know of, and the description is so high-level that it leaves a lot of room for interpretation and agenda-pushing. Some people think it automatically means "web services" (it doesn't), others think it means "XML" (nope), others think it means "SOAP" (wrong again), while others, amazingly, think it means software will no longer require testing. Still others have said it means user interfaces will be built in the future using point-and-click with no code, all because of SOA. WTF?
Actually, the basic idea is this: Various business-specific functions are defined as "services" running in various locations. The "services" are software systems that sit idle until a "consumer" makes a request to them. So, instead of defining an application that provides its own security, authorization, business rules, etc., an application is defined so it communicates with one or more coarse-grained encapsulated business services through discoverable, negotiable interfaces. (Wow... I just described SOA in the plainest terms I could think of, and it sounded like a product brochure!) Anyway, it's a worthy goal. A full SOA implementation in a company would mean that no "applications" exist in the traditional sense; Instead, there would be an enterprise service bus (ESB) that everything hooks to, and provides access to everything else (think of it as a big pipe). A "Customer" service would provide access to customer data, a "Security" service would provide authenication, a "Rules Engine" would provide business rules, and so on. "Applications" would consume these services from the ESB instead of having "baked-in" dependencies on them. Services could be swapped out in favor of other services, or upgraded, without causing their consumers to break (as long as the services' interfaces don't change, of course, unless I'm missing something big).
Granularity of these services is a big issue, and probably the most important aspect to make sure you get right. Providing a consumable "Customer" service is one thing, but providing a consumable "Database" service is an idiotic idea. Given the hype surrounding SOA, I'm sure someone's going to insist on a consumable "Database" service eventually. Unsuprisingly, it will result in the slowest software ever created, and suprisingly, the person who insists on it won't be the one who gets fired. It'll be interesting to see how SOA turns out.
The final two sessions were about Hibernate. I've been a big fan of Hibernate for 3 years. It's simple to use,
efficient, lightweight, places no artificial constraints on the objects being persisted, and is, frankly, the best way I've found for mapping between objects in a java program, and data in a relational database.
One more day to go. This is a cool conference. I talked to the organizer of it today in the hall, and told him I liked how there was so much more "meat" to it than something like the neckties-and-cheerleadin' JavaOne-type conferences. He said "Yeah, we basically look at those conferences to see what they do, and then we do the opposite." Well, it's working.
posted by Kelly @ 12:59 AM
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home